Linux ping запретить фрагментацию пакетов

Ping – setting don’t fragment bit in Linux/FreeBSD/Solaris/Cisco/Juniper

Ping.
Many times while debugging network problems of various kinds you need to send some packets of desirable size and don’t fragment bit being set. I list below how to do it for the different equipment/OSes. Let’s start with the most popular operating system among network folks – Linux:

Linux

By default ping in any Linux-based system (It also means any distribution – Slackware, Ubuntu, CentOS etc) is sent with Don’t fragment (df) bit set . You don’t need to add any command line switches for that. Here is what you get by default ping in Linux:
Defaults:
Don’t fragment bitВ (in echo request)В — set
Ip packet size – 84 bytes
Sending intervalВ — 1 second

Some examples.
-В sending station:

-В В receiving station:
[root@darkstar

]#tcpdump -s 1500 -n -vv icmp

To change sent packet size: -sВ , bytes (8 bytes of ICMP header will be added automatically).

Sending host:
[root@darkstar

]#ping 10.99.99.158 -s 1300

Receiving host:
freeBSD#tcpdump -n -v -s 1500 icmp

To change sending interval (mostly used together with large packet size) :
-iВ

Sending host:
[root@darkstar

]#ping -s 1300 -i 0.2 10.99.99.158

Receiving host:
freeBSD#tcpdump -n -v -s 1500 icmp

To force Linux to send pings with DF bit cleared (i.e. not set):
ping –M don’t

]#ping -s 1300 -M dontВ 10.99.99.158

freeBSD#tcpdump -n -v -s 1500 icmp

SideNote: FreeBSD ping has a nice add-on (see below) – sweeping size of the packets, while Linux doesn’t have such extra feature, Below is script to emulate it on Linux:

Here:
size – size of data in ICMP packet (bytes);
-I 0.5 – interval of 5 seconds (optional);
-c 3 — number of pings in each size session (NOT optional – or you will enter an endless loop which even Ctrl-C won’t be able to stop )

See it in action:
[root@darkstar

]#awk ‘ BEGINВ to change
Don’t fragment bit — not setВ ;В use df-bit to set

Running with defaults:

Receiving host:
[root@darkstar

]# tcpdump -n -vВ -s 1500 icmp

Set df bit and size of the packet (Note – when you set size of the ping you set IP packet size and not ICMP data size as in Nix systems).
Repeat count is set to 3 .
Tokyo#ping 191.91.21.41 size 1300 df-bit rep 3

Receiving host:
[root@darkstar

]# tcpdump -n -vВ -s 1500 icmp

Sweeping ping size.
This feature is available from extended ping menu:

Juniper routers (JunOS):
Defaults:
Ip packet size : 84 bytes
Don’t fragment bit – not set; use do-not-fragment to set
IntervalВ — 1 sec;В use interval to change
Sending pings with df bit set and size 1470 bytes
root@Juniper> ping 192.168.37.29 do-not-fragment size 1470

If packet size is too large and df is set you get this:

root@Juniper> ping 192.168.37.29 do-not-fragment size 13000

Источник

Что такое MTU

На этом блоге неоднократно рассматривалось устройство сетей Ethernet, однако одно понятие до сих пор оставалось нетронутым — MTU. Что же такое MTU и как оно может влиять на вашу работу в интернете?

Аббревиатура MTU означает Maximum Transmission Unit — это можно перевести как максимальный размер пакета, передаваемого по сетям. Если точнее, то не самого пакета, а тех полезных данных, что в нем содержатся. Если вы читали про сетевые протоколы, то знаете, что передаваемые по сетям пакет содержит серию заголовков, позволяющих доставить его и также некоторые данные, переносимые в пакете. Так вот, каждым маршрутизатором накладывается ограничение на размер полезных данных в пакете, и это и есть MTU.

Откуда берутся такие ограничения? Дело в том, что стандартов Ethernet заложено, что размер Ethernet-пакета не может превышать 1518 байт. При этом 4 последние байта составляет проверочная сумма, позволяющая проверить корректность пакета, а первые 14 байт — MAC-заголовок, содержащий MAC-адрес устройства, которому направлен пакет. Тем самым, для Ethernet MTU составляет 1500, и это и есть то базовое ограничение, от которого все «пляшут». Но ведь Ethernet — это нижний уровень, даже в локальной сети обращение идет по IP-адресам, и это означает, что внутри «полезных данных» для Ethernet будут содержаться еще заголовки, тем самым, полезный размер, скажем, TCP-пакета, будет уже меньше.

Фрагментация пакетов

Безусловно, эта информация не означает, что нельзя передать по сети больший размер данных, это было бы просто смешно. Когда размер полезных данных больше, протокол генерирует множество последовательных пакетов, которые дополняют нужные данные. Это позволяет работать в условиях нестабильного интернета, небольшие пакеты успевают проходить.

Однако куда интересней может быть ситуация, когда какое-либо устройство вашей сети настроено передавать пакеты размером не больше некоторого заданного, а ему приходит пакет с большим размером полезных данных. Что с ним можно сделать. Существует два варианта:

• Отброс пакета: пакет может быть просто проигнорирован. В таком случае находящаяся за устройством цель и не узнает, что ей что-то посылали.
• Фрагментация пакета: внутри пакет бьется на два более маленьких и передается дальше. Это приводит к более высокой нагрузке на сеть, поэтому часто эта опция отключена. Кроме того, следует помнить, что не все протоколы поддерживают получение и сборку фрагментированных пакетов.

Для определения максимального размера пакета, который можно послать к устройству, можно использовать так называемый ping-test. Посылайте ping с дополнительными опциями — запретить фрагментацию и указать размер пакета. Для Windows такая команда дается как ping host -f -l size, для Linux ping host -M do -s size.

MTU и VPN

Чаще всего проблемы с MTU могут возникать, когда вы подключаетесь куда-нибудь по VPN. Сами вы их, скорей всего решить не сможете, но у вас есть вариант попросить что-то изменить провайдера или цель подключения, например, на вашей работе. Так что же может происходить. Допустим, у провайдера задан какой-то MTU, например 1460. Они могли так занизить когда-то в прошлом, по просьбе некоторых клиентов или когда у них использовался какой-то специфический механизм авторизации. А на работе у вас, допустим, стоит MTU 1420. Но вы подключаетесь по VPN, и поэтому чтобы все могло работать, все заголоски VPN должны поместиться в 40 байт.

Могут поместиться, а могут и нет. Если вы используете PPTP, то, кажется, должны поместиться. А если, например, L2TP/IPSEC, то он задействует протокол ESP для шифрования, и у него довольно большие заголовки. В таком случае у вас подключиться не получится. Проявляться это будет так — вы можете вводить пароль, у вас будет начинать устанавливаться соединение, и дальше процесс подключения будет засыпать. А на сервере в логах будут периодические запросы к вашему компьютеру. Он даже ответы будет слать, но до сервера они не дойдут.

Что делать в таких случаях? Варианта два. 1) Просить поднять MTU у провайдера. 2) Просить опустить MTU на работе. Ну и, конечно, есть еще множество вариантов типа «забить», «поменять провайдера» и «поменять работу»,

Надеюсь, эта статья была полезной. Если есть вопросы, пишите!

Источник

проблема с фрагментацией, или MTU, ping -f и ФПСУ клиент

sergey.s.betke

Well-Known Member

Флагом –f мы запрещаем фрагментацию пакетов. Размер пакета (1470) меньше MTU (1472), поэтому ICMP ответа “требуется фрагментация” не последует. Но с заголовком размер пакета составит 1498 . Меньше 1500. Но ведь размер – больше MTU, поэтому и уйти такой пакет через сетевой интерфейс не сможет. И какой бы размер MTU мы не установили в реестре, проблема размером в 28 байт сохранится.

Не было бы никаких проблем, если бы ФПСУ IP клиент создавал новый виртуальный сетевой интерфейс, как и многие другие VPN решения, а не NDIS фильтр. Тогда не возникло бы и проблем с установкой MTU для этого нового виртуального интерфейса – берём MTU сетевого интерфейса, через который поднят VPN, вычитаем 28 – и получаем MTU виртуального Amicon VPN интерфейса. Судя по MSDN, фильтры не должны изменять размеры пакетов. А NDIS фильтр ФПСУ IP клиент – меняет. Отсюда и проблема.

Читайте также:  При каждой загрузке запускается проверка диска windows 10

Другими словами – с MTU проблема у ФПСУ IP-клиента. В любом варианте установки. При этом, если отправитель не выставит флаг “фрагментация запрещена” – проблем не будет (пакет будет фрагментирован, что подтверждается успешным выполнением ping –t 213.148.164.75 –l 2000). А если отправитель выставит этот флаг, и размер пакета будет меньше MTU сетевого интерфейса, но больше, чем (MTU-28 байт) – не будет и ICMP ответа о необходимости фрагментации, и пакет отправлен не будет.

Вопрос к разработчикам — что делать с этой проблемой? Из-за отсутствия ICMP ответа о необходимости фрагментации автоопределение MTU на хостах клиент-банка работать не будет, резать на них MTU сразу и на все направления — не очень бы хотелось.
Есть ли шанс дождаться редакции клиента, которая будет создавать именно новый виртуальный сетевой интерфейс для VPN соединения, естественно — правильно при этом расчитывая MTU (лучше всего — поддерживая при этом механизмы автоопределения размеров MTU для конкретного маршрута, и по алгоритму определения «чёрных дыр», и по корректным ответам ICMP).
Подобное решение снимет всякие проблемы с MTU, любая современная клиентская ОС «из коробки» будет прекрасно работать через ФПСУ VPN, не важно, какой канал при этом будет использован: сейчас клиентские ОС поддерживают алгоритмы автоопределения MTU ( EnableDeadGWDetect , EnablePMTUBHDetect , EnablePMTUDiscovery в реестре MS Windows).
Сейчас же, из-за того, что NDIS фильтр меняет размер пакета механизмы автоопределения MTU на клиентах не работают.

Прошу откликнуться разработчиков. Есть ли шанс дождаться решения в какой-либо версии?

Dmitriy

Администратор

Не забывайте, что ICMP и TCP протоколы — разные вещи. В клиенте реализован механизм регулировки MSS TCP . Проверка пингами в данном случае некорректна.

sergey.s.betke

Well-Known Member

Адрес, указанный в ping — адрес сервера банка за ФПСУ банка при поднятом VPN.

Вы говорите о том, что проверка пингом некорректна. В чём в данном случае разница, если мы говорим про MTU? icmp пакет — тот же пакет, с конкретным размером, успешно фильтром обрабатывается и отправляется в туннель.

что же касается интерфейса и фильтра. Ничто ведь не мешается фильтр свой вешать на свой же интерфейс.

Ещё один аргумент. Функция ФПСУ клиента очень похожа на пример из MSDN —
http://msdn.microsoft.com/en-us/library/windows/hardware/ff571070(v=VS.85).aspx . Вы можете получить пакет с размером больше MTU интерфейса, на котором и висит Ваш фильтр. В результате — тишина.

Все эти усложнения, по сути, прекрасно были бы замещены решением с отдельным интерфейсом, там все проблемы согласования MTU решала бы ОС, и Вы могли бы сосредоточиться на своей основной задаче.

Dmitriy

Администратор

Что-то Вы запутались совсем. 213.148.164.75 — это Интернетовский адрес. Не понимаю, как он может быть за банковским ФПСУ. 😕

sergey.s.betke

Well-Known Member

Дмитрий, я не запутался. Именно этот адрес прописан в хостах в ключе, полученном от банка. Именно на этот адрес уходят пакеты от клиента банка (если верить network monitor’у). И что с того, что у Новгородского отделения сервера имеют «белые» ip?
И совсем не понимаю Ваших сомнений по поводу того, как один белый ip может быть за другим? Дмитрий, в чём Ваши сомнения?
Кроме того, и в СПб за ФПСУ так же сервер банка имеет белый ip (правда резервным указан серый, что на мой взгляд чистой воды дурь).

Что касается сертификации — действительно, этот момент меня просто и не интересовал.

P.S> Позвольте вопрос на несколько иную тему, Дмитрий. Я так понял, что ФПСУ банка не реализует NAT для клиентов. Вывод такой сделал по той простой причине, что без NAT на интерфейсе с фильтром Амикона с других машин сеть обмена с ФПСУ не было. Вопрос вот в чём: имеют ли возможность специалисты банка включить на ФПСУ NAT для клиента, хотя бы по заявке?
Поясню, откуда вопрос возник про NAT. Как раз с тем отделением, в котором ip сервера белый — проблем никаких. А от ФПСУ в СПб ключи получили, в которых в адресе хоста указаны два ip — один белый, другой — серый (192.168.0.чего-то, точнее не помню). У меня в сети так же есть данная подсеть. И на ФПСУ банка приходит пакет от клиента ФПСУ, на интерфейсе которого ip из 192.168. Один или несколько «внутренних» интерфейсов ФПСУ в «серой» сети банка (192.168. ). Проблемы, как я понимаю, обеспечены.

Читайте также:  Можно ли синхронизировать айфон с windows

Disaron

Active Member

sergey.s.betke

Well-Known Member

В том и дело, что в сети банка есть серые адреса (вижу из адресов хостов, прописанных в ключе). Техподдержка никаких подробностей открывать не хочет, поэтому выяснить адреса всех сетей, которые использовать нельзя, нет возможности. Приходится гадать.

Предположения: пакеты выходят в сеть банка с исходным ip адресом (на ФПСУ клиента никакого NAT нет). ФПСУ на стороне банка, судя по результатам тестирования без NAT на клиенте, фиксирует в момент установления связи только сокет клиента ФПСУ. В момент прохождения пакета через ФПСУ сервер от клиента дополнительную информацию не собирает. В результате, когда пакет приходит из сети клиента (но Ip отличается от ip фпсу клиента), и сервер банка отвечает на него, ФПСУ сервер уже не имеет информации – какому же ФПСУ клиенту его (ответный пакет) отправить (потому как ip назначения отличается от того, с которого была установлена связь ФПСУ ip клиентом)! Как только поднял NAT на клиенте, запросы из нашей сети (не только с ФПСУ клиента) стали успешно через этот туннель и уходить, и возвращаться. Я так понимаю, такое поведение говорит о том, что опциональный NAT на ФПСУ сервере банка выключен?

А раз NAT не работает, то как он может определить, какому ФПСУ клиенту направлять ответ? – только по ip, которые (в случае серых Ip на клиентах ФПСУ) могут дублироваться у разных клиентов. Кстати, при попытке соединения с серым ip клиент получал пакеты, которые не мог декодировать, о чём прямо и писал.

Именно поэтому, судя по всему, нам и не удаётся в течение рабочего дня установить соединение с ФПСУ банка – только раза с 30ого. А вечером – с 1ого раза. Просто клиентов на этом сервере с серыми Ip много , и у кого-то они такие же, как и у нас, что не удивительно.

Предварительно могу заявить (подтвердить смогу в понедельник) что проблема решилась следующим образом: провайдер пошёл нам навстречу, и предоставил нам с целью тестирования маленькую такую подсеть белых Ip адресов. Я заменил адреса на интерфейсах с фильтрами Амикона на белые (соответственно — уникальные). Результат – соединение с ФПСУ банка с первого раза! (оно и понятно – таких то адресов у других клиентов быть не может). В понедельник – стресс-тест, и, надеюсь, всё закончится заключением доп. соглашения с провайдером на подсеть белых адресов.

Прошу подтвердить, правильны ли мои предположения по поводу функционирования ФПСУ сервера с включенным NAT и выключенным. И решит ли, на Ваш взгляд, проблему применение белых ip.

Кстати, если всё вышеописанное подтвердится, тогда даже при типовой схеме — подключение с машины клиента-банка с ФПСУ клиентом с серым ip (даже не важно — через свисток с NAT мобильного провайдера или через свою серую сеть и isa / tmg) — будут проблемы с нестабильным коннектом, если на ФПСУ банка NAT отключен. И имеет смысл во все рекомендации по настройки подключения включить рекомендацию по использованию белого ip, либо же объяснять клиентам, что они должны так или иначе убедить банк использовать NAT на ФПСУ сервере.

Честно говоря, не могу понять архитекторов, которые умудрились применить нормальный инструмент (ваш туннель имею в виду), не позаботясь о NAT, и ориентируясь при этом на корпоративных клиентов (то бишь — с серыми сетями в основном)?

Источник