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

Обновлено: 06.07.2024

ping [ -LRUbdfnqrvVaAB ] [ -c количество ] [ -i интервал ] [ -l преднагрузка ] [ -p шаблон ] [ -s размер-пакета ] [ -t ttl ] [ -w ограничение-на-время-работы ] [ -F идентификатор-потока ] [ -I адрес ] [ -M указание ] [ -Q тип-обслуживания ] [ -S буфер-отправки ] [ -T параметр-временной-метки ] [ -W время-ожидания-ответа ] [ переход . ] назначение

ОПИСАНИЕ

Датаграммы ECHO_REQUEST состоят из заголовков IP и ICMP, структуры данных struct timeval и произвольного числа несмысловых байтов для заполнения пакета.

ОПЦИИ

При использовании команды ping для локализации неполадки сначала запустите её с адресом локального хоста для проверки работоспособности локального сетевого интерфейса. Затем проверяйте связь посредством ping со всё более удалёнными компьютерами и шлюзами. Время прохождения сигналов в обе стороны и потери пакетов подсчитываются и анализируются позднее. Если принимаются дублированные пакеты, то они не включаются в статистику утерянных пакетов, хотя время прохода таких пакетов включается в статистику минимального/среднего/максимального времени. После отправки и получения указанного количества пакетов или при прерывании работы программы сигналом SIGINT выводится краткий итог работы. Более краткую статистику можно получить без прерывания процесса с помощью сигнала SIGQUIT.

Если ответные пакеты не будут получены, то программа завершит работу с кодом выхода 1. Если указаны количество пакетов и ограничение-на-время-работы , но по истечении этого времени принято менее запрошенного числа пакетов, то программа также завершит работу с кодом выхода 1. При других ошибках выход будет произведен с кодом 2. Иначе программа завершает работу с кодом 0. Эти значения позволяют использовать коды выхода для определения доступности серверов и компьютеров в сети.

Эта программа предназначена для тестирования сетей, управления сетями и измерения производительности. Из-за нагрузок, которые она создаёт в сети, неразумно использовать ping в рабочее время или в автоматических сценариях.

ОПИСАНИЕ ПАКЕТОВ ICMP

Заголовок IP без параметров имеет размер 20 байтов. Пакет ICMP ECHO_REQUEST содержит дополнительные 8 байтов, предназначенные для заголовка ICMP, и произвольное количество заполняющих байтов (для обеспечения требуемого размера пакета), определяемое аргументом размер-пакета данных (по умолчанию 56). Поэтому количество полученных данных из пакета IP типа ICMP ECHO_REPLY всегда будет на 8 байтов (заголовок ICMP) больше, чем задаваемое.

Если заданный размер данных не меньше размера struct timeval, то программа включает в них временную метку, используемую для измерения времени прохода сигнала в обе стороны. В противном случае такое время не будет измеряться.

ПОВТОРЯЮЩИЕСЯ И ПОВРЕЖДЁННЫЕ ПАКЕТЫ

Повреждённые пакеты являются прямым свидетельством неполадок в аппаратной части на одном из участков сети, через который проходили пакеты.

ТЕСТИРОВАНИЕ НА РАЗЛИЧНЫХ ДАННЫХ

(Меж)сетевая часть механизма передачи данных не должна обрабатывать пакеты по-разному, в зависимости от содержащихся в них данных. К сожалению такие проблемы часто встречаются в сетях и остаются невыявленными достаточно долго. Во многих случаях оказывается, что некорректно обрабатывается некоторый вырожденный шаблон, например, состоящий из одних нулей или единиц, либо близкий к нему. Простой проверки по вырожденным шаблонам данных недостаточно, т.к речь идёт о данных на уровне канала данных, которые могут соотноситься с указываемыми вами данными самым сложным образом.

В любом случае, такие проблемы означают, что вам предстоит очень много работ по тестированию и выявлению вышедшего из строя элемента. Если вам повезёт, то вы найдёте файл, который вообще не будет передаваться по сети, или будет передаваться очень долго (по сравнению с файлами такого же размера), и затем сможете исследовать его на предмет возможных проблемных шаблонов, проверить которые можно с помощью ключа -p программы ping .

ВРЕМЯ АКТУАЛЬНОСТИ (TTL)

Значение TTL для пакетов IP задаёт максимальное количество IP-маршрутизаторов, через которое пакет ещё будет доставляться, а не считаться утерянным. Сейчас каждый маршрутизатор в Интернете уменьшает поле TTL при обработке пакета на единицу.

Согласно спецификации TCP/IP значение поля TTL для пакетов TCP должно быть равно 60, но многие системы используют меньшие значения (4.3 BSD использует 30, 4.2 использует 15).

Максимальное значение данного поля равно 255, и многие Unix-системы устанавливают поле TTL для пакетов ICMP ECHO_REQUEST в 255. Поэтому иногда получается, что вы можете проверить связь командой `ping' до некоторых компьютеров, но не можете связаться с ними программами telnet (1) или ftp (1).

В обычном режиме ping выводит значения времени актуальности принятых (возвращённых) пакетов. При приёме пакета удалённой системой она может выполнить одно из трёх возможных действий с полем TTL в ответ: * Не изменять его; это делали системы Berkeley Unix до выпуска BSD 4.3 Tahoe. TTL в принятом пакете будет 255 минус количество пройденных маршрутизаторов на пути в обе стороны. * Установить его в 255: это то, что системы Berkeley Unix делают сейчас. В этом случае значение TTL в принятом пакете будет 255 минус количество пройденных маршрутизаторов от удалённой системы до исходной. * Установить его в какое-либо другое значение. Некоторые машины устанавливают его равным используемому для TCP пакетов, например, либо 30 либо 60. Другие системы могут использовать вообще непредсказуемые значения.

ИЗВЕСТНЫЕ ОШИБКИ

* Многие узлы и шлюзы игнорируют параметр RECORD_ROUTE. * Максимальная длина заголовка IP слишком мала для полноценной работы таких параметров, как RECORD_ROUTE. * Использовать лавинообразный режим вообще не рекомендуется, а в случаях когда целью является широковещательный адрес, лавинообразный режим следует применять в условиях тщательного контроля.

СМ. ТАКЖЕ

ИСТОРИЯ

Настоящим документом описывается адаптированная для Linux версия программы.

Однажды для каждого настоящего системного администратора (или исполняющего обязанности такового) наступает момент истины. Ему выпадает судьба настроить маршрутизатор на компьютере с установленной ОС GNU/Linux. Те, кто это уже прошел, знают, что ничего сложного в этом нет и можно уложиться в пару команд. И вот наш админ находит эти команды, вбивает их в консоль и гордо идет к пользователям сказать, что уже все работает. Но не тут-то было – пользователи говорят что их любимые сайты не открываются. После траты некоторой части своей жизни на выяснение подробностей обнаруживается, что большая часть сайтов ведет себя следующим образом:
1. При открытии страницы загружается заголовок и больше ничего;
2. В таком состоянии страница висит неопределенно долгое время;
3. Строка статуса браузера все это время показывает что загружает страницу;
4. Пинги и трассировка до данного сайта проходят нормально;
5. Соединение по telnet на 80 порт тоже проходит нормально.
Обескураженный админ звонит в техподдержку провайдера, но там от него быстро избавляются, советуя попробовать настроить маршрутизатор на OC Windows, а если уж и там не работает тогда… купить аппаратный маршрутизатор.
Я думаю, эта ситуация знакома многим. Некоторые в нее попадали сами, у кого-то с ней сталкивались знакомые, а кто-то встречал таких админов на форумах и прочих конференциях. Итак: если у Вас Такая Ситуация, то — Поздравляю! Вы столкнулись с Path MTU Discovering Black Hole. Данная статья посвящается тому, отчего это бывает, и как решить эту проблему.

Термины, необходимые для понимания статьи

Тестовый полигон

С данной проблемой лучше всего знакомится на практике (но не в цейтноте, когда начальство орет над ухом). Для этого я создал тестовую сеть, изображенную на рис.1

Рис. 1. Тестовая сеть.

Нормальное определение PMTU

1 IP 172.16.5.3.48547 > 192.168.0.1.80: Flags [S], seq 2947128725, win 5840, options [mss 1460. ], length 0
2 IP 192.168.0.1.80 > 172.16.5.3.48547: Flags [S.], seq 757312786, ack 2947128726, win 5792, options [mss 1460. ], length 0
3 IP 172.16.5.3.48547 > 192.168.0.1.80: Flags [.], ack 1, win 1460, options [. ], length 0
4 IP 172.16.5.3.48547 > 192.168.0.1.80: Flags [P.], seq 1:118, ack 1, win 1460, options [. ], length 117
5 IP 192.168.0.1.80 > 172.16.5.3.48547: Flags [.], ack 118, win 181, options [. ], length 0
6 IP 192.168.0.1.80 > 172.16.5.3.48547: Flags [.], seq 1:2897, ack 118, win 181, options [. ], length 2896
7 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
8 IP 192.168.0.1.80 > 172.16.5.3.48547: Flags [.], seq 1:1349, ack 118, win 181, options [. ], length 1348
9 IP 192.168.0.1.80 > 172.16.5.3.48547: Flags [.], seq 1349:2697, ack 118, win 181, options [. ], length 1348
10 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556

Рис 2. Процедура определения PMTU.

Встреча с Path MTU Discovery Black Hole

1 IP 172.16.5.3.57925 > 192.168.0.1.80: Flags [S], seq 1723325723, win 5840, options [mss 1460. ], length 0
2 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [S.], seq 2482933888, ack 1723325724, win 5792, options [mss 1460. ], length 0
3 IP 172.16.5.3.57925 > 192.168.0.1.80: Flags [.], ack 1, win 1460, options [. ], length 0
4 IP 172.16.5.3.57925 > 192.168.0.1.80: Flags [P.], seq 1:118, ack 1, win 1460, options [. ], length 117
5 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], ack 118, win 181, options [. ], length 0
6 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [. ], length 1448
7 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
8 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1449:2897, ack 118, win 181, options [. ], length 1448
9 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
10 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [. ], length 1448
11 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
12 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [. ], length 1448
13 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
14 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [. ], length 1448
15 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
16 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [. ], length 1448
17 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
18 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [. ], length 1448
19 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
20 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [. ], length 1448

Рис. 3. Черная дыра в определении PMTU.

Эта проблема совсем не нова. Она описана в RFC 2923 в 2000 году. Но тем не менее, продолжает встречаться с завидным упорством у многих провайдеров. А ведь именно провайдер виноват в данной ситуации: не нужно блокировать ICMP тип 3 код 4. Причем слушаться «голоса разума» ( т. е. клиентов, понимающих в чем проблема) они обычно не хотят.

Решение проблемы с PMTU

Не будем звонить в техподдержку, а попробуем решить проблему, исходя из собственных средств.
Разработчики Linux, тоже знающие о ней, предусмотрели специальную опцию в iptables. Цитата из man iptables:

TCPMSS
This target allows to alter the MSS value of TCP SYN packets, to control the maximum size for that connection (usually limiting it to your outgoing interface’s MTU minus 40 for IPv4 or 60 for IPv6, respectively). Of course, it can only be used in conjunction with -p tcp. It is only valid in the mangle table. This target is used to overcome criminally braindead ISPs or servers which block "ICMP Fragmentation Needed" or "ICMPv6 Packet Too Big" packets. The symptoms of this problem are that everything works fine from your Linux firewall/router, but machines behind it can never exchange large packets:
1) Web browsers connect, then hang with no data received.
2) Small mail works fine, but large emails hang.
3) ssh works fine, but scp hangs after initial handshaking.
Workaround: activate this option and add a rule to your firewall configuration like:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu

--set-mss value
Explicitly set MSS option to specified value.

--clamp-mss-to-pmtu
Automatically clamp MSS value to (path_MTU - 40 for IPv4; -60 for IPv6).

These options are mutually exclusive.

Мой вольный перевод для тех, у кого туго с английским:

TCPMSS
Это действие позволяет изменять значение MSS в TCP SYN пакетах, для контроля максимального размера пакетов в этом соединении (Обычно ограничивая его MTU исходящего интерфейса минус 40 байт для IPv4 или минус 60 для IPv6). Конечно, это действие может использоваться только в сочетании с -p tcp. Разрешено это только в таблице mangle. Это действие используется для преодоления преступной некомпетентности провайдеров и серверов, блокирующих "ICMP Fragmentation Needed" или "ICMPv6 Packet Too Big" пакеты. Симптомы этой проблемы – все прекрасно работает на вашем сетевом экране или роутере, но машины за ним никогда не смогут обмениваться большими пакетами:
1) Веб браузеры связываются, но просто висят без пересылки данных.
2) маленькие электронные письма приходят нормально, но большие висят.
3) ssh работает отлично, но scp висит после начальных рукопожатий(прим пер: процесс установки TCP соединения также называют "тройным рукопожатием").
Решение: активировать эту опцию и добавить правило, подобное нижеприведенному, в конфигурацию своего сетевого экрана:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu

--set-mss значение
Явная установка в опции MSS специфического значения.

1 IP 172.16.5.3.33792 > 192.168.0.1.80: flags [s], seq 1484543117, win 5840, options [mss 1360. ], length 0
2 IP 192.168.0.1.80 > 172.16.5.3.33792: flags [s.], seq 2230206317, ack 1484543118, win 5792, options [mss 1460. ], length 0
3 IP 172.16.5.3.33792 > 192.168.0.1.80: flags [.], ack 1, win 1460, options [. ], length 0
4 IP 172.16.5.3.33792 > 192.168.0.1.80: flags [p.], seq 1:118, ack 1, win 1460, options [. ], length 117
5 IP 192.168.0.1.80 > 172.16.5.3.33792: flags [.], ack 118, win 181, options [. ], length 0
6 IP 192.168.0.1.80 > 172.16.5.3.33792: flags [.], seq 1:2697, ack 118, win 181, options [. ], length 2696
7 IP 172.16.5.3.33792 > 192.168.0.1.80: flags [.], ack 1349, win 2184, options [. ], length 0
8 IP 192.168.0.1.80 > 172.16.5.3.33792: flags [.], seq 2697:5393, ack 118, win 181, options [. ], length 2696
9 IP 192.168.0.1.80 > 172.16.5.3.33792: flags [fp.], seq 5393:6380, ack 118, win 181, options [. ], length 987
10 IP 172.16.5.3.33792 > 192.168.0.1.80: flags [.], ack 2697, win 2908, options [. ], length 0

1 IP 172.16.5.3.33792 > 192.168.0.1.80: Flags [S], seq 1484543117, win 5840, options [mss 1460. ], length 0
2 IP 192.168.0.1.80 > 172.16.5.3.33792: Flags [S.], seq 2230206317, ack 1484543118, win 5792, options [mss 1360. ], length 0
3 IP 172.16.5.3.33792 > 192.168.0.1.80: Flags [.], ack 1, win 1460, options [. ], length 0
4 IP 172.16.5.3.33792 > 192.168.0.1.80: Flags [P.], seq 1:118, ack 1, win 1460, options [. ], length 117
5 IP 192.168.0.1.80 > 172.16.5.3.33792: Flags [.], ack 118, win 181, options [. ], length 0
6 IP 192.168.0.1.80 > 172.16.5.3.33792: Flags [.], seq 1:1349, ack 118, win 181, options [. ], length 1348
7 IP 192.168.0.1.80 > 172.16.5.3.33792: Flags [.], seq 1349:2697, ack 118, win 181, options [. ], length 1348
8 IP 172.16.5.3.33792 > 192.168.0.1.80: Flags [.], ack 1349, win 2184, options [. ], length 0
9 IP 172.16.5.3.33792 > 192.168.0.1.80: Flags [.], ack 2697, win 2908, options [. ], length 0
10 IP 192.168.0.1.80 > 172.16.5.3.33792: Flags [.], seq 2697:4045, ack 118, win 181, options [. ], length 1348

В упрощенном виде поведение MSS представлено на рис. 4. Я не стал показывать обмен данными, так как он аналогичен обычному поведению.

Рис. 4. Изменение MSS на лету.

Хотя в man iptables описаны две опции, но я пока примененил только одну. Нужная опция зависит от конкретной ситуации. Все ситуации можно разделить на 2 типа:

1. На вашем маршрутизаторе сайты открываются нормально, у клиентов в локальной сети наблюдаются проблемы.
В этом случае наименьший MTU на всем пути находится именно на вашем сервере. Обычно это некие протоколы инкапсуляции, типа PPPoE, PPtP и тд. Для данной ситуации лучше всего подойдет опция –clamp-mss-to-pmtu, которая автоматически установит минимальный MSS на все транзитные пакеты.

2. На вашем маршрутизаторе и у клиентов в локальной сети сайты не открываются.
В таком случае наименьший MTU находится где-то у провайдера и вычислить его стандартными средствами сложновато. Специально для этого я написал небольшой скрипт на python(не особо заботясь о PEP8 и невозможности выстрелить в ногу), который поможет определить необходимый размер MSS для данной ситуации:

Запускать скрипт нужно с правами суперпользователя. Алгоритм его работы таков:
1. Пытаемся получить некоторое количество данных с сайта с нормальным значением MSS.
2. Если это не получается, то понижаем MSS на iptables цепочке OUTPUT до MTU — 40 – LIM.
3. Если и после этого мы не можем получить данные, то выдаем ошибку о том, что LIM имеет слишком маленькое значение.
4. Последовательно наращивая MSS, ищем тот момент, когда данные перестанут поступать. После этого выводим последнее рабочее значение MSS.
5. Если мы дошли до MSS=MTU-40, то выводим ошибку о том, что не можем определить MSS. Данная ситуация является ошибочной, т. к. в пункте 1 проводим аналогичную проверку, и, если результаты не совпадают, это повод задуматься.

После получения нужного MSS необходимо вписать его в соответствующее правило. Можно обойтись и без скрипта, на глаз понизив значение MSS, но лучше выяснить его точно – меньше накладые расходы на пересылку пакетов.

Часто на форумах можно встретить советы понизить MTU на том или ином интерфейсе. Нужно понимать, что это не панацея, и результат зависит от того, на каком интерфейсе понижать. Если понизим на одном из интерфейсов участников TCP соединения, то это принесет эффект, так как заявленная MSS будет соответствовать минимальному размеру пакета. Но если это будут не конечные точки, а один из транзитных маршрутизаторов, то без включения опции --clamp-mss-to-pmtu никакого эффекта не будет.

Надеюсь данная статья поможет Вам решить подобную проблему как у себя, так и у ваших друзей и знакомых. Еще раз обращаюсь к специалистам провайдеров – БЕЗ КРАЙНЕЙ НЕОБХОДИМОСТИ НЕ БЛОКИРУЙТЕ ICMP ТИП 3 КОД 4 – этим вы создаете проблемы вашим колегам.

</s>
Очевидно, что фильтру Амикона требуется увеличить размер пакета, чтобы дописать свой заголовок. По результатам экспериментов – 28 байт требуется. В моём случае до ФПСУ банка допустим MTU 1500. Из-за дополнительного заголовка ФПСУ – 1472 байта. Первое, что приходит в голову – установить на интерфейсе Amicon MTU 1472.
Но не тут то было. Запускаем тест с рабочей станции Вашей сети:
<CODE><s>

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

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

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

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

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

Dmitriy

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

<r>Сергей, не совсем понятно описана проблема. В частности, что Вы пытаетесь проверить командой ниже? Чей это адрес? <CODE><s>

</e></CODE>
Не забывайте, что ICMP и TCP протоколы - разные вещи. В клиенте реализован механизм регулировки <s></s>MSS TCP<e></e>. Проверка пингами в данном случае некорректна.

</s>Есть ли шанс дождаться редакции клиента, которая будет создавать именно новый виртуальный сетевой интерфейс для VPN соединения, естественно - правильно при этом расчитывая MTU (лучше всего - поддерживая при этом механизмы автоопределения размеров MTU для конкретного маршрута, и по алгоритму определения "чёрных дыр", и по корректным ответам ICMP).<e> </e></QUOTE>
Нет, нового сетевого интерфейса ждать не следует. Дело в том, что, помимо основной функции построения защищенных каналов связи между оборудованными комплексом рабочими станциями и межсетевыми экранами "ФПСУ-IP", ПАК "ФПСУ-IP/клиент" имеет свой локальный межсетевой экран. Со схемой работы через новый сетевой интерфейс невозможно будет анализировать поступающие на интерфейсы исходящие и входящие пакеты данных.</r>

sergey.s.betke

Well-Known Member

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

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

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

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

Dmitriy

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

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

</e></QUOTE>
Что-то Вы запутались совсем. 213.148.164.75 - это Интернетовский адрес. Не понимаю, как он может быть за банковским ФПСУ. <E>:?</E>

</s>что же касается интерфейса и фильтра. Ничто ведь не мешается фильтр свой вешать на свой же интерфейс. <e> </e></QUOTE>
Здесь можно посоветовать для начала ознакомиться с ГОСТами, по требованиям которых проходит сертификация клиента. То, чего хочется Вам от клиента, в современных реалиях сертифицировать, к сожалению, будет невозможно.</r>

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. ). Проблемы, как я понимаю, обеспечены.

Disaron

Active Member

</s> У меня в сети так же есть данная подсеть. И на ФПСУ банка приходит пакет от клиента ФПСУ, на интерфейсе которого ip из 192.168. Один или несколько "внутренних" интерфейсов ФПСУ в "серой" сети банка (192.168. ). Проблемы, как я понимаю, обеспечены. <e> </e></QUOTE>Косяк возникнет, если хост с клиентом и хост с адресом, аналогичным адресу прописанному в списке в ФПСУ/клиенте, входят в одну подсеть. Тогда пакеты будут улетать в туннель, а ожидаться от хоста из подсети (вроде так было - давно не сталкивался с этой проблемой). Если хосты не входят в одну подсеть - все будет работать.</r>

sergey.s.betke

Well-Known Member

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

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

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

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

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

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

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

Мы рассмотрим использование команды ping для Windows и, немного, для Linux.

Параметры команды ping и их описание

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

Общий синтаксис

Независимо от системы, команду ping можно применять так:

ping [опции] <имя сервера или IP-адрес>

Windows

Для просмотра в Windows также используйте команду ping /?

Параметр	Описание
-t	Команда будет отправлять запросы на проверку постоянно, пока ее не прервать клавишами Ctrl + C. Удобно, если сеть не работает и чтобы постоянно не проверять, появилась ли связь.
-a	Пытается определить имя узла через DNS.
-n	Задает определенное число попыток отправки запроса.
-l	Размер пакета. Используется для проверки стабильности сети, создания тестовой нагрузки и так далее.
-f	По умолчанию ping разрешает фрагментацию, то есть пакет может быть разбит на несколько для соответствия минимальному пропускаемому размеру (MTU). Данный флаг это запрещает. Используется для определения вышеупомянутого MTU.
-i	Задает срок жизни пакета (количество сетевых устройств, через которые может пройти сигнал). Может использоваться в случаях, когда количество оборудования слишком велико. Также можно определить его количества.
-w	Устанавливает время ожидания. Применяется, если существуют проблемы производительности на сети или расстояние до узла очень большое.
-S	Позволяет выполнить проверку сети с определенного источника. Может быть использовано с узла с несколькими сетевыми адаптерами и отправкой запроса с определенного.
-4	Использовать только IPv4.
-6	Использовать только IPv6.

Параметр	Описание
-r	Записывает маршрут для указанного числа прыжков.
-s	Задает метку времени для указанного числа прыжков.
-j	Задает свободный выбор маршрута по списку узлов.
-k	Задает жесткий выбор маршрута по списку узлов.
-R	Использует заголовок маршрута для проверки и обратного маршрута.

Linux

При минимальной инсталляциии данной системы или использовании docker, утилиты ping может не быть. В таком случае мы увидим ошибку:

bash: ping: command not found

Для ее установки можно воспользоваться менеджером установки пакетов. В зависимости от типа операционной системы, наши команды будут немного отличаться.

а) для систем на базе deb (Debian, Ubuntu, Mint):

apt install iputils-ping

б) для систем на базе RPM (Rocky Linux, CentOS, Red Hat, Fedora):

yum install iputils

Готово, теперь можно пользоваться командой ping.

Список ключей можно посмотреть так:

Примеры использования

Простой пример использования команды ping

Примерный ответ с исправной связью:

Пример ответа, если узел недоступен:

* до удаленного узла нет сигнала. Возможно, существуют неполадки на сети.

При проверке связи не удалось обнаружить узел
Проверьте имя узла и повторите попытку.

* не удалось определить имя узла. Возможные неполадки: нет связи с DNS, не работает DNS, запрашиваемого имени узла не существует.

В Linux при отсутствии ответа, мы ничего не увидим, но если нам нужно видеть неудачные попытки, то используем ping с опцией -O:

ping -O 206.190.36.45

Открытие порта для Ping

Справедливо заметить, что не во всех случаях отсутствие ответа на ping означает, что удаленный узел недоступен. Администратор ресурса может намеренно отключить ответы на эхо-запросы.

Также важно знать, что ping не использует конкретный номер порта. Чтобы открыть возможность пинга, необходимо либо найти соответствующую опцию (во многих домашних роутерах) или разрешить ICMP (Internet Control Message Protocol) на брандмауэре. Ну, или наоборот — чтобы закрыть возможность пинга, блокируем запросы ICMP.

Проверка портов

С помощью команды ping нельзя проверить открытость того или иного порта.

Для этих целей используется команда telnet или программа, например, nmap.

Читайте также: