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

sergey.s.betke

sergey.s.betke

Well-Known Member
<r>Наткнулся на проблему на интерфейсах, на которых установлен ФПСУ IP Клиент. Пример проблемы описан здесь: <URL url="http://sergey-s-betke.blogs.novgaro.ru/klient-bank-sberbanka-sb-rf-fpsu-ipklient-amikon-i-isa-server-stroim-specializirovannyj-fpsu-marshrutizator#ping-f"><s></s><LINK_TEXT text="http://sergey-...nyj-fpsu-marshrutizator#ping-f</LINK_TEXT><e></e></URL>.

Процитирую:
<QUOTE><s>
</s>
Очевидно, что фильтру Амикона требуется увеличить размер пакета, чтобы дописать свой заголовок. По результатам экспериментов – 28 байт требуется. В моём случае до ФПСУ банка допустим MTU 1500. Из-за дополнительного заголовка ФПСУ – 1472 байта. Первое, что приходит в голову – установить на интерфейсе Amicon MTU 1472.
Но не тут то было. Запускаем тест с рабочей станции Вашей сети:
<CODE><s>
Код: 
</s>ping -t 213.148.164.75 -f -l -1470<e>
</e></CODE>
Флагом <B><s></s>–f<e></e></B> мы запрещаем фрагментацию пакетов. Размер пакета (1470) меньше MTU (1472), поэтому ICMP ответа “требуется фрагментация” не последует. <B><s></s>Но с заголовком размер пакета составит 1498<e></e></B>. Меньше 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>
Нажмите для раскрытия...
</e></QUOTE>

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

Прошу откликнуться разработчиков. Есть ли шанс дождаться решения в какой-либо версии?</r>
 
<r>Сергей, не совсем понятно описана проблема. В частности, что Вы пытаетесь проверить командой ниже? Чей это адрес? <CODE><s>
Код: 
</s>ping -t 213.148.164.75 -f -l -1470<e>
</e></CODE>
Не забывайте, что ICMP и TCP протоколы - разные вещи. В клиенте реализован механизм регулировки <B><s></s>MSS TCP<e></e></B>. Проверка пингами в данном случае некорректна.

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

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

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

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

Все эти усложнения, по сути, прекрасно были бы замещены решением с отдельным интерфейсом, там все проблемы согласования MTU решала бы ОС, и Вы могли бы сосредоточиться на своей основной задаче...</r>
 
<r><QUOTE><s>
</s>Адрес, указанный в ping - адрес сервера банка за ФПСУ банка при поднятом VPN.<e>
Нажмите для раскрытия...
</e></QUOTE>
Что-то Вы запутались совсем. 213.148.164.75 - это Интернетовский адрес. Не понимаю, как он может быть за банковским ФПСУ. <E>:?</E>

<QUOTE><s>
</s>что же касается интерфейса и фильтра. Ничто ведь не мешается фильтр свой вешать на свой же интерфейс. <e>
Нажмите для раскрытия...
</e></QUOTE>
Здесь можно посоветовать для начала ознакомиться с ГОСТами, по требованиям которых проходит сертификация клиента. То, чего хочется Вам от клиента, в современных реалиях сертифицировать, к сожалению, будет невозможно.</r>
 
Дмитрий, я не запутался. Именно этот адрес прописан в хостах в ключе, полученном от банка. Именно на этот адрес уходят пакеты от клиента банка (если верить network monitor'у). И что с того, что у Новгородского отделения сервера имеют "белые" ip?
И совсем не понимаю Ваших сомнений по поводу того, как один белый ip может быть за другим? Дмитрий, в чём Ваши сомнения?
Кроме того, и в СПб за ФПСУ так же сервер банка имеет белый ip (правда резервным указан серый, что на мой взгляд чистой воды дурь).

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

P.S> Позвольте вопрос на несколько иную тему, Дмитрий. Я так понял, что ФПСУ банка не реализует NAT для клиентов. Вывод такой сделал по той простой причине, что без NAT на интерфейсе с фильтром Амикона с других машин сеть обмена с ФПСУ не было. Вопрос вот в чём: имеют ли возможность специалисты банка включить на ФПСУ NAT для клиента, хотя бы по заявке?
Поясню, откуда вопрос возник про NAT. Как раз с тем отделением, в котором ip сервера белый - проблем никаких. А от ФПСУ в СПб ключи получили, в которых в адресе хоста указаны два ip - один белый, другой - серый (192.168.0.чего-то, точнее не помню). У меня в сети так же есть данная подсеть. И на ФПСУ банка приходит пакет от клиента ФПСУ, на интерфейсе которого ip из 192.168. Один или несколько "внутренних" интерфейсов ФПСУ в "серой" сети банка (192.168...). Проблемы, как я понимаю, обеспечены...
 
<r><QUOTE author="sergey.s.betke"><s>
sergey.s.betke написал(а):
</s> У меня в сети так же есть данная подсеть. И на ФПСУ банка приходит пакет от клиента ФПСУ, на интерфейсе которого ip из 192.168. Один или несколько "внутренних" интерфейсов ФПСУ в "серой" сети банка (192.168...). Проблемы, как я понимаю, обеспечены...<e>
Нажмите для раскрытия...
</e></QUOTE>Косяк возникнет, если хост с клиентом и хост с адресом, аналогичным адресу прописанному в списке в ФПСУ/клиенте, входят в одну подсеть. Тогда пакеты будут улетать в туннель, а ожидаться от хоста из подсети (вроде так было - давно не сталкивался с этой проблемой). Если хосты не входят в одну подсеть - все будет работать.</r>
 
В том и дело, что в сети банка есть серые адреса (вижу из адресов хостов, прописанных в ключе). Техподдержка никаких подробностей открывать не хочет, поэтому выяснить адреса всех сетей, которые использовать нельзя, нет возможности. Приходится гадать.

Предположения: пакеты выходят в сеть банка с исходным 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, и ориентируясь при этом на корпоративных клиентов (то бишь - с серыми сетями в основном)?
 
Кстати, рискну предположить, что именно наличие уже подключенного клиента с тем же ip, что и у нашего, и вызывало проблемы с подключением. Каким образом при этом должен отвечать сервер? не возникает ли в этом случае задержки с ответом в те самые 9 секунд? Опишите пожалуйста поведение сервера в этом случае, что мы должны увидеть (хотя бы и через network monitor)? Хочется убедиться, что причина проблемы найдена.
 
Раз тема про MTU, немного теории для всех.

Есть под Windows два MTU: MTU сетевого адаптера (обычно 1514 байт) и MTU TCP/IP протокола (обычно 1500 байт). Значение MTU TCP/IP устанавливается в реестре - это делает также, например, DrTcp и наш клиент. MTU адаптера меняется где-то в настройках адаптера и равно максимальной длине Ethernet-пакета. Нам менять его не нужно.
Для чего при установке ФПСУ-IP/клиента есть галочка изменить MTU на 1400? Для того, чтобы изменить MTU именно протокола TCP/IP (меняется именно в его настройках в соответствующей ветке реестра). Сделав значение MTU 1400, TCP/IP начинает резать все пакеты от приложений под это значение. При отправке пакета в VPN-туннель к его длине прибавляется 28 байт (актуально для СКЗИ Туннель-2.0), т.е. 1428 байт плюс Ethernet-заголовок (14 байт). Итого 1442. Это меньше, чем MTU адаптера (1514 байт) --> NDIS-фильтру не приходится резать пакет на куски --> сеть работает быстрее, ФПСУ-IP на стороне банке не собирает его из кусков --> сеть работает ещё быстрее.
Если не уменьшать MTU TCP/IP протокола, NDIS-фильтр получит пакет размером 1528 байт + 14 байт заголовка и ему придется его резать...
Фильтру и ФПСУ-IP абсолютно все равно какого размера идет пакет. Вплоть до 64 КБ фильтр разрежет, ФПСУ-IP соберет --> пакет пройдет по VPN-туннелю в неизменном виде, не считая Ethernet- и IP-заголовков, в случае если установлен NAT.
В общем, любой пакет любой длинны, но не больше 64 КБ, обязательно пройдет по VPN-туннелю и выйдет из него с другой стороны. Исключением являются пакеты, имеющие ошибки: неверная контрольная сумма, неправильно зашифрованный, что проверяет как NDIS-фильтр, так и ФПСУ-IP.
 
<r>Касаемо NAT на ФПСУ-IP.

Сергей, как Вы уже прочли в <URL url="http://www.amicon.ru/forum/viewtopic.php?p=7074#7074"><s></s>соседней теме<e></e></URL>, при передаче запросов клиентов МЭ ФПСУ-IP может производить трансляцию сетевого адреса (Network Address Translation - NAT) клиента во внутренний адрес защищаемой сети. Это обеспечивает клиентам возможность мобильной работы из любой точки сети (независимо от IP-адреса) по предъявлению устройства, содержащего его идентификационные и ключевые данные (устройства VPN-key).
Нам неизвестно, как настроены комплексы в Вашем регионе. Могу сказать только, что Московский банк СБ довольно давно перевел всех своих клиентов на NAT. Вам бы не с техподдержкой отделения пообщаться, а с администратором отделенческого ФПСУ-IP, куда приходят клиенты. Судя по обращениям к нам, местная поддержка не имеет представления об архитектуре банковской сети. Думаю, в Вашем отделении примерно такая же картина.

<QUOTE><s>
</s>Кстати, рискну предположить, что именно наличие уже подключенного клиента с тем же ip, что и у нашего, и вызывало проблемы с подключением. Каким образом при этом должен отвечать сервер? не возникает ли в этом случае задержки с ответом в те самые 9 секунд? Опишите пожалуйста поведение сервера в этом случае, что мы должны увидеть (хотя бы и через network monitor)? Хочется убедиться, что причина проблемы найдена.<e>
Нажмите для раскрытия...
</e></QUOTE>
Покажите логи сервиса клиента, при такой ситуации там должны быть постоянные реконнекты. Примерно так: <CODE><s>
Код: 
</s>DrvAppFunctions.cpp:1311; OnDriverEvent; Signal from drv CALL_DRIVER_RECONNECT<e>
</e></CODE></r>
 
<r>Поздно прочитал... Теперь смогу уже только утром завтра логи прислать. Сейчас могу выложить то, что вижу в Network Monitor'е:
<CODE><s>
Код: 
</s><i>
</i>3	14402.313000		{UDP:0, IPv4:0}	192.168.202.202	84.204.34.245	UDP	UDP:SrcPort = 1068, DstPort = Any private terminal link(87), Length = 43
4	14408.781750		{UDP:1, IPv4:0}	192.168.202.202	84.204.34.245	UDP	UDP:SrcPort = 1069, DstPort = Any private terminal link(87), Length = 43
5	14411.344250		{UDP:0, IPv4:0}	84.204.34.245	192.168.202.202	UDP	UDP:SrcPort = Any private terminal link(87), DstPort = 1068, Length = 44
6	14415.344250		{UDP:2, IPv4:0}	192.168.202.202	84.204.34.245	UDP	UDP:SrcPort = 1070, DstPort = Any private terminal link(87), Length = 43
7	14417.813000		{UDP:1, IPv4:0}	84.204.34.245	192.168.202.202	UDP	UDP:SrcPort = Any private terminal link(87), DstPort = 1069, Length = 44
8	14421.906750		{UDP:3, IPv4:0}	192.168.202.202	84.204.34.245	UDP	UDP:SrcPort = 1071, DstPort = Any private terminal link(87), Length = 43
9	14424.359875		{UDP:2, IPv4:0}	84.204.34.245	192.168.202.202	UDP	UDP:SrcPort = Any private terminal link(87), DstPort = 1070, Length = 44
10	14429.047375		{UDP:4, IPv4:0}	192.168.202.202	84.204.34.245	UDP	UDP:SrcPort = 1072, DstPort = Any private terminal link(87), Length = 43
11	14430.922375		{UDP:3, IPv4:0}	84.204.34.245	192.168.202.202	UDP	UDP:SrcPort = Any private terminal link(87), DstPort = 1071, Length = 44
12	14435.813000		{UDP:5, IPv4:0}	192.168.202.202	84.204.34.245	UDP	UDP:SrcPort = 1073, DstPort = Any private terminal link(87), Length = 43
13	14438.078625		{UDP:4, IPv4:0}	84.204.34.245	192.168.202.202	UDP	UDP:SrcPort = Any private terminal link(87), DstPort = 1072, Length = 44
14	14442.203625		{UDP:6, IPv4:0}	192.168.202.202	84.204.34.245	UDP	UDP:SrcPort = 1074, DstPort = Any private terminal link(87), Length = 43
15	14444.828625		{UDP:5, IPv4:0}	84.204.34.245	192.168.202.202	UDP	UDP:SrcPort = Any private terminal link(87), DstPort = 1073, Length = 44
16	14448.625500		{UDP:7, IPv4:0}	192.168.202.202	84.204.34.245	UDP	UDP:SrcPort = 1075, DstPort = Any private terminal link(87), Length = 43
17	14451.219250		{UDP:6, IPv4:0}	84.204.34.245	192.168.202.202	UDP	UDP:SrcPort = Any private terminal link(87), DstPort = 1074, Length = 44
18	14454.984875		{UDP:9, IPv4:0}	192.168.202.202	84.204.34.245	UDP	UDP:SrcPort = 1076, DstPort = Any private terminal link(87), Length = 43
19	14457.641125		{UDP:7, IPv4:0}	84.204.34.245	192.168.202.202	UDP	UDP:SrcPort = Any private terminal link(87), DstPort = 1075, Length = 44
20	14461.438000		{UDP:10, IPv4:0}	192.168.202.202	84.204.34.245	UDP	UDP:SrcPort = 1077, DstPort = Any private terminal link(87), Length = 43
21	14464.000500		{UDP:9, IPv4:0}	84.204.34.245	192.168.202.202	UDP	UDP:SrcPort = Any private terminal link(87), DstPort = 1076, Length = 44
22	14468.078625		{UDP:11, IPv4:0}	192.168.202.202	84.204.34.245	UDP	UDP:SrcPort = 1078, DstPort = Any private terminal link(87), Length = 43
23	14470.469250		{UDP:10, IPv4:0}	84.204.34.245	192.168.202.202	UDP	UDP:SrcPort = Any private terminal link(87), DstPort = 1077, Length = 44
24	14475.078625		{UDP:12, IPv4:0}	192.168.202.202	84.204.34.245	UDP	UDP:SrcPort = 1079, DstPort = Any private terminal link(87), Length = 43
25	14477.094250		{UDP:11, IPv4:0}	84.204.34.245	192.168.202.202	UDP	UDP:SrcPort = Any private terminal link(87), DstPort = 1078, Length = 44
26	14482.141125		{UDP:15, IPv4:0}	192.168.202.202	84.204.34.245	UDP	UDP:SrcPort = 1080, DstPort = Any private terminal link(87), Length = 43
27	14484.094250		{UDP:12, IPv4:0}	84.204.34.245	192.168.202.202	UDP	UDP:SrcPort = Any private terminal link(87), DstPort = 1079, Length = 44
28	14489.328625		{UDP:16, IPv4:0}	192.168.202.202	84.204.34.245	UDP	UDP:SrcPort = 1081, DstPort = Any private terminal link(87), Length = 43
29	14491.203625		{UDP:15, IPv4:0}	84.204.34.245	192.168.202.202	UDP	UDP:SrcPort = Any private terminal link(87), DstPort = 1080, Length = 44
30	14497.219250		{UDP:17, IPv4:0}	192.168.202.202	84.204.34.245	UDP	UDP:SrcPort = 1082, DstPort = Any private terminal link(87), Length = 43
31	14498.344250		{UDP:16, IPv4:0}	84.204.34.245	192.168.202.202	UDP	UDP:SrcPort = Any private terminal link(87), DstPort = 1081, Length = 44
32	14506.250500		{UDP:17, IPv4:0}	84.204.34.245	192.168.202.202	UDP	UDP:SrcPort = Any private terminal link(87), DstPort = 1082, Length = 44
33	14506.828625		{UDP:18, IPv4:0}	192.168.202.202	84.204.34.245	UDP	UDP:SrcPort = 1083, DstPort = Any private terminal link(87), Length = 43
34	14515.844250		{UDP:18, IPv4:0}	84.204.34.245	192.168.202.202	UDP	UDP:SrcPort = Any private terminal link(87), DstPort = 1083, Length = 44
35	14516.328625		{UDP:19, IPv4:0}	192.168.202.202	84.204.34.245	UDP	UDP:SrcPort = 1084, DstPort = Any private terminal link(87), Length = 43
36	14516.344250		{UDP:19, IPv4:0}	84.204.34.245	192.168.202.202	UDP	UDP:SrcPort = Any private terminal link(87), DstPort = 1084, Length = 44
37	14516.625500		{UDP:19, IPv4:0}	192.168.202.202	84.204.34.245	UDP	UDP:SrcPort = 1084, DstPort = Any private terminal link(87), Length = 145
38	14516.641125		{UDP:19, IPv4:0}	84.204.34.245	192.168.202.202	UDP	UDP:SrcPort = Any private terminal link(87), DstPort = 1084, Length = 186

<e>
</e></CODE>
Обратите внимание не второе поле (time offset) некое время в секундах (от запуска системы). Первый пакет - ушёл. Клиент не дождался ответа и отправляет второй пакет - через 6.5 секунды. Но ответ на первый пакет всё-таки вернулся (третий захваченный пакет) - через 9 секунд после запроса! Ну и так далее, всё хорошо просматривается. Я подозреваю, что если бы удалось увеличить время ожидания ответа клиентом (более 10 секунд), то связь поднималась бы с первого раза. Но это - мои предположения, такие настройки мне недоступны, а лезть дебаггером в код клиента как неправильно будет. Может, такая возможность есть среди недокументированных (время ожидания ответа)?

Логи клиента Вам завтра вышлю в первой половине дня.

А по поводу MTU - проблема есть, если стоит флаг запрета фрагментации (пример с Ping -f я уже приводил). Пакет просто "пропадает", что и понятно, в общем то. Фильтр, видимо, просто дорисовывает свой заголовок, флаг копирует исходный (то есть - новый пакет запрещён к фрагментации) - и результат: пакет больше MTU интерфейса, фрагментировать нелья, и он - отброшен. При этом ICMP ответ возвращается отправителю (в данном случае - на интерфейс с фильтром Амикона обратно, потому как фильтр реинжектировал увеличенный пакет и указал в качестве отправителя адрес интерфейса, на котром "сидит"). И ФПСУ клиент его исходному клиенту не возращает. Будет к Вам просьба - пересылайте пожалуйста ICMP пакеты исходному отправителю, тогда и автоопределение MTU заработает, и чёрных дыр... или всё не совсем так?

По поводу связи с банком - Ваши бы слова... Про техподдержку банка просто уже не пишу, - всё и всеми уже везде написано. А до админов ФПСУ банка не особо дозвонишься, они отправляют обратно на техподдержку в наш город, ФПСУ - в СПб. На мой вопрос о возможности включения NAT для нас ответили, что такой возможности у них нет. И что я должен им в этом случае сказать? я прекрасно понимаю, что они открыто врали в лицо, но от того, что я нахамил бы им в ответ - стало бы лучше? Ну нет на них управы, и они это понимают. Я бы написал письмо начальнику отдела безопасности, так там именно "безопасник", лицо, далёкое от ИТ в принципе. Ему NAT что китайская грамота - приблизительно одинаково воспринимаются.

Ладно, лирику откинем, утром пришлю логи...</r>
 
<r>Вернусь к исходному вопросу темы - к MTU. Картинка сейчас ещё интереснее:
<CODE><s>
Код: 
</s><i>
</i>ping 55.251.189.1 -t -f -l 1438

Ответ от 55.251.189.1: число байт=1438 время=11мс TTL=127
Ответ от 55.251.189.1: число байт=1438 время=11мс TTL=127
Ответ от 55.251.189.1: число байт=1438 время=14мс TTL=127
^C

ping 55.251.189.1 -t -f -l 1440

Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.
^C

ping 55.251.189.1 -t -l 1472

Обмен пакетами с 55.251.189.1 по 1472 байт:

Ответ от 55.251.189.1: число байт=1472 время=19мс TTL=127
Ответ от 55.251.189.1: число байт=1472 время=13мс TTL=127
Ответ от 55.251.189.1: число байт=1472 время=11мс TTL=127
^C

ping 55.251.189.1 -t -l 1474

Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
^C

ping 55.251.189.1 -t -l 2000

Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
^C
<e>
</e></CODE>

При этом должен сказать следующее - с машины, на которой установлен ФПСУ клиента, icmp запросы прекрасно бьются и возвращаются. с других машин сети через эту машину маршрутизируются успешно только icmp запросы размером меньше MTU. фрагментированные icmp запросы уходят, возвращаются клиенту, но с клиента в сеть уже не уходят.

Не подскажете, в чём может быть проблема с маршрутизацией фрагментированных icmp запросов через интерфейс с ФПСУ фильтром? при том, что нефрагментированные (меньше MTU) успешно ходят...</r>
 
есть одна особенность ключа -l команды ping. Это не длина ip паке пакета, а размер данных помещенных с ICMP пакет. 28 байт это заголовки ICMP и IP вместе, а не заголовок ФПСУ-IP. На сколько я помню, детектировать сквозь туннель длину пакета не удается.
 
Войдите или зарегистрируйтесь для ответа.
Назад
Сверху