snapoid Posted September 25 (edited) Коллеги, нужно освежить знания.... Есть цепочка - виртуалка MTU1500->хост MTU1500->фабрика коммутаторов (MTU9014)->интернет (виртуалка светит белым IP наружу, про MTU у провайдера ничего сказать не могу)->сервер (ICMP отключен, пинга нет, но на порт отвечает).... Я правильно понимаю - что пакет от виртуалки (1500) при прохождении всего канала связи может пересобираться (в 9014) и далее опять фрагментироваться до нужного MTU при прохождении ? С виртуалки до сервера пинг не проходит, но инет есть - т.е. на другие хосты доступ... С виртуалки до сервера нужен канал с TLS-шифрованием - коннект на порт есть, но отбивает в процессе. Может ли это быть из-за MTU ? Edited September 25 by snapoid Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted September 25 Фрагментация/дефрагментация происходит на IP уровне, коммутаторы это обычно ethernet уровень и даже в случае IP (L3) они таким не занимаются. "отбивает в процессе" - кто "обивает"? как "отбивает"? И вообще, ICMP отключат контуженые безопасники. Адекватные специалисты понимают что оно нужно, а пинговать в локалке можно через ARP. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
sdy_moscow Posted September 25 @snapoid и нет уж сил, пытаться вас понять... З.Ы. Тут регулятор очередной документ прислал. Поручение! Но в тексте нет ни одного глагола. О КАК! Надо что-то с русским языком и литературой "технарям самоучкам" делать.... ЧИТАЙТЕ БОЛЬШЕ! Хотя-бы фантастику. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
straus Posted September 26 Кроме MTU повторить ещё про параметры MSS и RWIN. Ибо не MTU единым... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
snapoid Posted September 26 Цитата Фрагментация/дефрагментация происходит на IP уровне, коммутаторы это обычно ethernet уровень и даже в случае IP (L3) они таким не занимаются. "отбивает в процессе" - кто "обивает"? как "отбивает"? И вообще, ICMP отключат контуженые безопасники. Адекватные специалисты понимают что оно нужно, а пинговать в локалке можно через ARP. Ну так оно и понятно.... "Отбивает" - сервер, идет соединение на 443 порт, а дальше и сервер не пингуется совсем - т.е. ICMP закрыт полностью... Как я понимаю - пробовать подбирать MTU на интерфейсе моей виртуалки с малого (576)..... В остальном - с виртуалки в инет доступ есть. Стоит белым IP наружу, без проксей и NAT-ов. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Pinkbyte Posted September 26 В современном мире когда вижу TLS Negotiation Failure обычно на ум приходит сначала РКН. А уж потом свои кривые руки. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted September 27 17 hours ago, snapoid said: "Отбивает" - сервер, идет соединение на 443 порт, а дальше Вы когда не понимаете что происходит - используйте инструменты, tcpdump/wireshark - они вам покажут более понятные картинки раз вы читаете по английски плохо 🙂 TLS negotiation fail обычно означает что подключится на уровне TCP получилось, но дальше согласовать крипту в рамках TLS не получилось. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
snapoid Posted September 29 (edited) Цитата Вы когда не понимаете что происходит - используйте инструменты, tcpdump/wireshark - они вам покажут более понятные картинки раз вы читаете по английски плохо 🙂 TLS negotiation fail обычно означает что подключится на уровне TCP получилось, но дальше согласовать крипту в рамках TLS не получилось. Ну с tcpdump/wireshark дружбу водим, по необходимости..... Все оказалось проще - отсутствие нормальной информации о связанности. "Сервер" это оказался https-прокси, а запрос на канал с TLS идет уже по другому IP, и соответственно в default-route этот запрос шел в другое место.... Завернули запрос в сторону прокси - все поднялось. P.S. - скорее всего с tcpdump-ом вопрос решился бы быстрее - там то сразу бы увидели, куда запросы летят. Edited September 29 by snapoid Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
