q1b Posted October 11, 2016 · Report post Доброго времени суток всем! Ситуация такая: есть два сервера, находящихся географически в разных точках и имеющих связь через Интернет. Им необходима передача данных c фрагментацией на уровне IP. На всей цепочке маршрутизаторов все кроме одного маршрутизатора разрешают фрагментацию. Вопрос: обязан ли этот маршрутизатор по стандарту разрешать фрагментацию пакетов или это делается исключительно по желанию администраторов? Share this post Link to post Share on other sites More sharing options...
Vermison Posted October 11, 2016 · Report post Ваш вопрос какой-то странный. Сколько нужно передать? Сколько сейчас MTU максимальный на этом маршрутизаторе? Как вы определили, что он не разрешает фрагментацию? Почему нельзя фрагментировать непосредственно на сервере до этого МТУ. Сколько МТУ даёт вам провайдер? Share this post Link to post Share on other sites More sharing options...
zi_rus Posted October 11, 2016 · Report post обязан ли этот маршрутизатор по стандарту разрешать фрагментацию пакетов или это делается исключительно по желанию администраторов? маршрутизатору вообще покласть на фрагментацию, он работает на уровне ip, а вот в фаерволах это не любят, весь интернет завален примерами настройки iptables или pf где отдельным образом указывается запрет на фрагментированные пакеты Share this post Link to post Share on other sites More sharing options...
Умник Posted October 11, 2016 · Report post маршрутизатору вообще покласть на фрагментацию Вы не правы. In IPv4, routers perform fragmentation, whereas in IPv6, routers do not fragment, but drop the packets that are larger than their MTU. Share this post Link to post Share on other sites More sharing options...
Vermison Posted October 11, 2016 · Report post Вы не правы. Да только вот это будет если на интерфейсе МТУ меньше, чем размер пакета. А как ОП определил, какой МТУ отправляется. Скорее всего у него стоят сервера с МТУ паратыщьбайт, а мту у провайдера 1500. Вот и дропается. Пускай пишет, какие параметры канала, как определил, и что надо передать. Скорее всего ССЗБ пытается впихнуть невпихаемое. Share this post Link to post Share on other sites More sharing options...
zi_rus Posted October 11, 2016 · Report post маршрутизатору вообще покласть на фрагментацию Вы не правы. In IPv4, routers perform fragmentation, whereas in IPv6, routers do not fragment, but drop the packets that are larger than their MTU. это про то если роутеру надо самому производить фрагментацию, я говорил же о транзите Share this post Link to post Share on other sites More sharing options...
Vermison Posted October 11, 2016 (edited) · Report post это про то если роутеру надо самому производить фрагментацию, я говорил же о транзите Опять же правило справедливо для транзита только в том случае, если МТУ на destination интерфейсе меньше размера пакета. Если на Source -- пакеты будут отброшены, потому что слишком большие для интерфейса. Может у ОПа MTU-Blackhole из-за того, что он или провайдер зафильтровал. Да слишком много вариантов. По стандарту должен и скорее всего делает, но вот ОП скорее всего неправильно трактует результаты диагностики, или что-то не то делает. Ну не верю я что человек, задающий такие вопросы может определить, что "все кроме одного маршрутизатора разрешают фрагментацию" Edited October 11, 2016 by Vermison Share this post Link to post Share on other sites More sharing options...
moonfire Posted October 11, 2016 · Report post обязан ли этот маршрутизатор по стандарту разрешать фрагментацию пакетов или это делается исключительно по желанию администраторов?[/size] Не обязан. Есть целый RFC по фильтрации фрагментированных пакетов. Security Considerations for IP Fragment Filtering . На juniper'ах частенько советуют впринципе блочить любые фрагментированные пакеты. К MTU вопрос не имеет отношения, проверяется именно признаки фрагментации в пакете. Share this post Link to post Share on other sites More sharing options...
q1b Posted October 11, 2016 · Report post Сейчас все пояню пределельно подробно. Имеются 2 хоста, скажем, А и B. Мне необходимо отправлять пакеты с нагрузкой больше чем 1500 байт c учетом IP-заголовка. Т. е. мне необходимо фрагментировать пакеты на уровне IP, а не TCP (это к словам о "маршрутизатору вообще покласть на фрагментацию, он работает на уровне ip", спасибо за информацию). Далее, оба провайдера на обоих концах разрешают отправку пакетов с МTU больше 1500, проверял пингом командой "ping -s 1600 GW_A" и "ping -s 1600 GW_B". Tcpdump показывает, что пакеты удачно фрагментируются собираются у шлюзов, снова фрагментируется, отправляются и собирается на моем сервере. Но когда я отправляю аналогичный пинг с хоста A на хост B, конечный хост B получает лишь первую часть пакета. Нагляднее: Отправляет хост А 04:53:20.723446 IP host_A > host_B: ICMP echo request, id 5730, seq 3, length 1480 04:53:20.723467 IP host_A > host_B: ip-proto-1 04:53:21.731443 IP host_A > host_B: ICMP echo request, id 5730, seq 4, length 1480 04:53:21.731464 IP host_A > host_B: ip-proto-1 Получает хост B 11:53:20.753000 IP host_A > host_B: ICMP echo request, id 5730, seq 3, length 1480 11:53:21.761175 IP host_A > host_B: ICMP echo request, id 5730, seq 4, length 1480 Однако в обратном направлении от хоста B к хосту A фрагментированные пакеты доходят все без потерь. Дальше я сделал tracepath от хоста А к хосту B и получил приблизительно следующую информацию: 1. host_A 2. GW_A 3. X1 3. X2 4. X3 5. X4 6. X5 7. GW_B 8. host_B После пинга с MTU > 1500 с обоих концов было выяснено, что маршрутизатор X3 не отвечает на подобный пинг. Из чего я и сделал вывод, что маршрутизатор X3 не передает фрагментированные пакеты. Теперь повторяю вопрос: "обязан ли этот маршрутизатор по стандарту разрешать фрагментацию пакетов или это делается исключительно по желанию администраторов?" Если мои анализы где-то неверны, прошу поправить. Share this post Link to post Share on other sites More sharing options...
orlik Posted October 11, 2016 · Report post Если речь именно про пропуск уже отфрагментированого пакета , то в принципе не вижу причин почему маршрутизатор не должен его пропустить. Если же маршрутизатор получает пакет и передать его далее не может т.к. размер пакета слишком велик , то правильно бдует дропнуть этот пакет и послать icmp mtu exceeded. вообще сама по себе процедура фрагментирования пакета достаточно напряжная для маршрутизатора. P.S. естественно все касаемо только транзитных пакетов Теперь повторяю вопрос: "обязан ли этот маршрутизатор по стандарту разрешать фрагментацию пакетов или это делается исключительно по желанию администраторов?" Ну если все как вы описали , то вообще говоря , да , X3 должен передать этот пакет далее. Но для этого нет стандарта обязывающего это делать. Возможно там сидит совсем упоротый администратор и он решил что любой фрагментированный пакет это зло :) И вообще покажите трассу , интересно кто этот X3 Share this post Link to post Share on other sites More sharing options...
q1b Posted October 11, 2016 · Report post И да, выразился некорректно, речь идет о передаче уже фрагментированных пакетов. Share this post Link to post Share on other sites More sharing options...
orlik Posted October 11, 2016 · Report post А вы уверены что X3 это не фаервол ? А то они по умолчанию будут дропать фрагментированые пакетики Share this post Link to post Share on other sites More sharing options...
orlik Posted October 11, 2016 · Report post Ну и камень в ваш огород , избавьтесь от фрагментации , и вам станет легче жить :) Share this post Link to post Share on other sites More sharing options...
moonfire Posted October 11, 2016 · Report post X3 должен передать этот пакет далее. Ничего такого он не должен. Иначе любой ACL уже был бы вне закона. Share this post Link to post Share on other sites More sharing options...
orlik Posted October 11, 2016 · Report post Ничего такого он не должен. Иначе любой ACL уже был бы вне закона. Ну , тут все зависит от отношений с этим провайдером. Если он транзит то как бы творить может что угодно :) , но не красиво это дропать клиентский трафик Share this post Link to post Share on other sites More sharing options...
moonfire Posted October 11, 2016 · Report post Насколько я понимаю, топикстартер хочет надавить на провайдера некиими стандартами передачи пакетов. Так вот, стандартов, обязывающих или даже рекомендующих маршрутизаторам передавать подобные пакеты нет. Share this post Link to post Share on other sites More sharing options...
orlik Posted October 11, 2016 · Report post Насколько я понимаю, топикстартер хочет надавить на провайдера некиими стандартами передачи пакетов. Так вот, стандартов, обязывающих или даже рекомендующих маршрутизаторам передавать подобные пакеты нет. Как нет и стандартов призывающих дропать эти пакеты . Пусть даже это фрагмент , если ты пропускаешь транзитный трафик , то должен пропускать и фрагменты Share this post Link to post Share on other sites More sharing options...
moonfire Posted October 11, 2016 · Report post Как я уже говорил, такой стандарт как раз таки есть Security Considerations for IP Fragment Filtering Share this post Link to post Share on other sites More sharing options...
Vermison Posted October 11, 2016 (edited) · Report post Ну собственно, как я и написал, пытаетесь впихнуть невпихуемое. сложившаяся мировая практика установила IP MTU 1500. Только если это прямо не прописано в договоре, что маловероятно, так как невозможно отвечать за чужие АС. Из ваших выводов получается не то, что на том маршрутизаторе фрагментируется, а то, что дропается фрагментированная вами с помощью IP часть. Вообще это конечно очень странно. Фрагментируйте сами на более высоком уровне. Насколько я понимаю, топикстартер хочет надавить на провайдера некиими стандартами передачи пакетов. Так вот, стандартов, обязывающих или даже рекомендующих маршрутизаторам передавать подобные пакеты нет. Тут вы не правы, согласно RFC минимальный МТУ 576 байт (включая все фрагменты). Выше доставка не гарантируется. Но сейчас Edited October 11, 2016 by Vermison Share this post Link to post Share on other sites More sharing options...
orlik Posted October 11, 2016 · Report post Как я уже говорил, такой стандарт как раз таки есть Security Considerations for IP Fragment Filtering Ну как бы "This memo does not specify an Internet standard of any kind". Это не более чем описание борьбы с некоторыми видами аттак , но никак не призыв дропать все фрагменты Share this post Link to post Share on other sites More sharing options...
moonfire Posted October 11, 2016 · Report post Из ваших выводов получается не то, что на том маршрутизаторе фрагментируется, а то, что дропается фрагментированная вами с помощью IP часть. Вообще это конечно очень странно. Так и есть. Это не странно, а обычная практика, сам сталкивался. Фрагментируйте сами на более высоком уровне. Мопед не мой, я просто оставил комент. Это не более чем описание борьбы с некоторыми видами аттак , но никак не призыв дропать все фрагменты Ни кто и не говорит обо всех фрагментах. Даже если посмотреть описание ТС, можно увидеть, что некая их часть всё же проходит. Во вторых, для некоторых это именно призыв дропать, не разбираясь в сути, т.к. это RFC. А противоположного действия не описано. Share this post Link to post Share on other sites More sharing options...
Vermison Posted October 11, 2016 (edited) · Report post Мопед не мой, я просто оставил комент. К вам относилась только часть про RFC., Остальное к ОПу. Поместил ниже, чтобы не смущало. Edited October 11, 2016 by Vermison Share this post Link to post Share on other sites More sharing options...
rdc Posted October 11, 2016 · Report post Мне необходимо отправлять пакеты с нагрузкой больше чем 1500 байт c учетом IP-заголовка.Заверните их в туннель, уменьшите mtu туннельного интерфейса.Пакеты будут фрагментироваться на входе в туннель, а пакеты самого туннеля для всех транзитных роутеров пройдут уже нефрагментированными. Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted October 11, 2016 · Report post После пинга с MTU > 1500 с обоих концов было выяснено, что маршрутизатор X3 не отвечает на подобный пинг. Из чего я и сделал вывод, что маршрутизатор X3 не передает фрагментированные пакеты. Железо/ОС бывают со странностями и могут не отвечать когда не хотят или им что то не нравится. Ну собственно, как я и написал, пытаетесь впихнуть невпихуемое. сложившаяся мировая практика установила IP MTU 1500. Только если это прямо не прописано в договоре, что маловероятно, так как невозможно отвечать за чужие АС. Алё, на барже! Когнитивного диссонанса не возникает что UDP дейтаграмма почти 64кб а максимальный мту современных сетевух едва дошёл до 16к? Объясняю на пальцах для тех кто не знает что такое фрагментация в IP. 1500 - это размер полезных данных в эзернет фрейме, туда входят заголовки ИП пакетов. Когда некто пытается отправить по TCP скажем 50кб то ОС смотрит на значение MSS (которое образуется на основе договорённости при установлении соединения и всяко меньше 1500, ибо оно показывает сколько данных влезает в тцп пакет, а ос туда доклеивает тцп и ип заголовок) и разбивает 50кб на блоки по MSS байт, блоки эти не превышают 1500 и ОС отправляет их как есть. Когда некто пытается послать скажем UDP или ICMP или UDPLite или GRE или ещё их там дохрена придумали то ОС дописывает UDP заголовок в начало, дальше получившиеся 50кб+юдп заголовок попадают в IP кусок стёка ОС, ОС видит это, смотрит через какой интерфейс оно должно уйти (таблица маршрутизации + арп кеш), смотрит какой MTU на интерфейсе и далее она нарезает эти 50кб+юдп заголовок на кусочки размером с MTU, в заголовке IP пакета она ставит бит что оно фрагментированно и пишет в поле оффсет откуда этот кусок. Принимающая сторона на уровне IP стёка если видит что стоит бит фрагментации отправляет пакет не дальше по стёку вверх а в специальную ветку где происходит дефрагментация - reassemble пакетов, там они "склеиваются" по порядку благодаря оффсету, как только сумма пакетов достигает значения размера указанного в заголовках пакетов и в цепочке нет дыр - пакет считается собранным и отправляется по стёку на верх. А теперь почему это так не любят. Как я уже описал выше процесс сборки пакета - там видно что можно скажем для оффсета 3000 прислать два пакета с совершенно разным содержимым, но это конечно не очевидно что плохо, а вот пример злоупотребления: шлём в первом пакете размером 1500 и оффсетом 0 например GET / HTTP/1.1 host: mail.ru ... всякие системы дпи говорят всё в порядке. Далее шлём пакет который будет иметь оффсет попадающий на mail.ru но содержащий "sex.com ", потом досылаем данные чтобы пакет окончательно собрался и мы типа обошли дпи, для него мы на mail.ru. Ещё разные системы по разному дефрагментируют пересекающиеся фрагменты, некоторые их отбрасывают, некоторые накладывают поверх как описано в примере выше. маршрутизатору вообще покласть на фрагментацию, он работает на уровне ip, а вот в фаерволах это не любят, весь интернет завален примерами настройки iptables или pf где отдельным образом указывается запрет на фрагментированные пакеты Уху, но есть одно исключение: роутер будет либо дропать либо фрагментировать пакеты если мту на исходящем интерфейсе меньше размера пакета. Те при мту 1500 и 1400 на двух интерфейсах у тебя на 1400 будет полно фрагментов. У линуха вроде ещё и мту можно было указывать в таблице маршрутизации. Share this post Link to post Share on other sites More sharing options...
moonfire Posted October 12, 2016 · Report post Вопрос топикстартера не имеет отношения к MTU. Для любого интерфеса можно сгенерить такой пакет, который будет сфрагментирован. Хорошее решение предложил rdc Заверните их в туннель, уменьшите mtu туннельного интерфейса. Пакеты будут фрагментироваться на входе в туннель, а пакеты самого туннеля для всех транзитных роутеров пройдут уже нефрагментированными. Share this post Link to post Share on other sites More sharing options...
