Mtu в видеорегистраторе что это

Обновлено: 08.01.2025

Значит нужен мне второй канал связи, да этак мегабит 300 в секунду. В моём городе немного провайдеров, по этому выбрать не дали и пришлось подключаться к WiFire (он же NetByNet, MegaFon и так далее). Подключился, потестил, 300 мегабит, балдеж. Решил я значит почитать что нового на своем любимом Хабре и опа: он не открывается, но охотно пингуется.

Диагностика

Ну думаю: что-то тут не так. Сетевое у меня Mikrotik, возможностей уйма, пойду искать причину на своей стороне. Лезу в логи и вижу как посыпался DoH (РКН, приветик) и крайне удивляюсь этому. решил временно отрубить DoH и дать 1.1.1.1. Ситуация не изменилась. Начал резолвить адреса хотя бы чего-нибудь, все через раз. Решил прокинуть трейс до Хабра и смотрю на "потяряшки". Думаю дай звякну в поддержку, вдруг умное чего скажут. Те репу почесали, сказали что не видят мою сеть за роутером (nat >> forward >> change ttl >>+1 :D) и изобразили что-то вроде "Мы ХЗ".

Начал копать дальше. Вспомнил всю балду, которую знаю о пакетах и тут осенило.

Что такое MTU и MSS?

MTU (англ. maximum transmission unit) означает максимальный размер полезного блока данных одного пакета (англ. payload), который может быть передан протоколом без фрагментации.

MSS (англ. Maximum segment size) является параметром протокола TCP и определяет максимальный размер полезного блока данных в байтах для TCP-пакета (сегмента). Таким образом этот параметр не учитывает длину заголовков TCP и IP.

PMTU (Path MTU) - данный параметр обозначает наименьший MTU среди MTU каналов данных, находящихся между источником и приемником.

Википедии, конечно, спасибо, но если по-русски, то грубо говоря каждый пакет в сети - это бандероль со своими габаритами и вот как раз эти габариты надо менять, подгоняя под оператора связи (ISP). Не долго думая я начал пинговать Хабр с разным размером юнита (MTU) и уткнулся в 1450. Проставил все порты под новый MTU - мало, все равно не открывается. Решил не мучаться и воткнуть динамический MTU. Тут на помощь приходит PMTU. Вообще вот статейка в которой все хорошо объяснено на счет PMTU.

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

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

Топаем в консоль и пишем:

/ip firewall mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=no tcp-flags=syn protocol=tcp out-interface=*название WAN интерфеса* tcp-mss=1300-65535 log=no

/ip firewall mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=no tcp-flags=syn protocol=tcp in-interface=*название WAN интерфеса* tcp-mss=1300-65535 log=no

Разбираем что написали:

/ip firewall mangle - переходим по разделам и выберем что нужно.

add - команда добавления правила

chain=forward - указываем тип цепочки

action=change-mss - указываем что нужно менять MSS

new-mss=clamp-to-pmtu - указываем параметры, что используем PMTU и базируемся на нем

passthrough=no - не преходить к след. правилу пока не выполним это

tcp-flags=syn - выставляем флаг пакета для нумерации, что бы не терялся

protocol=tcp - указываем протокол с которым будем работать

in-interface\out-interface - интерфейсы вход\выход

tcp-mss=1300-65535 - разрешенный диапазон размера пакета

log=no - не логировать

и бинго, наконец-то открывается Хабр и все что мне нужно.

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

Форум по системам видеонаблюдения, безопасности, пожарным и охранным сигнализациям, контролю доступа.

Здравствуйте, дорогие участники форума !

До сих пор не могу понять, почему у меня отваливается интернет от 4g модема beeline(Huawei E3272) когда я вытаскиваю адаптер питания роутера(Netis MW 5230) из розетки а затем втыкаю вновь. Приходится вытаскивать модем из роутера и заново вставлять!
P2P статус меняется с "Зондирование DNS" на "Соединителтный" но не на "Связаный" ! Иногда становится "Связаный"

Возможно, что надо поменять параметр MTU ?
У меня в регистраторе стоит 1280 байт, в роутере стоит 1480. Читал, что MTU узнается у провайдера, я звонил в Beeline, они его мне не сказали.
Помогите пожалуйста разобраться.

Pierre Cardin писал(а): когда я вытаскиваю адаптер питания роутера(Netis MW 5230) из розетки а затем втыкаю вновь. Приходится вытаскивать модем из роутера и заново вставлять!

Поэтому, прежде чем лезть так глубоко в MTU, убедитесь сначала что мощности блока питания вашего роутера, достаточно не только для запуска и питания самого роутера, но еще и достаточно - для запуска и питания модема.

kROOT писал(а): Если есть интернет на роутере, то и через облако должно работать. Какие исх/вх скорости по тестам?

Для меня это все темный лес, но я постепенно прогрессирую. Каким тестом померить скорость ?

Сейчас я пробую пользоваться ping.
Я отключил роутер от регистратора, подключил роутер по витой паре к ноутбуку. В роутер воткнут 4G модем. Интернет работает.
В роутере MTU стоит 1480

Запустил ping при 1480,1460, 1400. Скрин прикладываю.
При 1480 отправлено =4, получено=0, потеряно = 4
При 1460 отправлено = 4, получено =4, потеряно =0 TTL = 49
При 1400 отправлено =4, получено = 4, потеряно = 0 TTL = 57мсек

Вопросы: Стоит мне поменять в роутере 1480 на 1460(или на меньшее/большее значение) ? Провести мне ping просто вставив только модем в ноутбук ?

Подскажите пожалуйста, это делаетя как то программно, или обычными электро замерами с помощью электротестера?

Pierre Cardin писал(а): Вопросы: Стоит мне поменять в роутере 1480 на 1460(или на меньшее/большее значение) ? Провести мне ping просто вставив только модем в ноутбук ?

Никакие MTU не надо нигде менять, если чтото поменяли, лучше сбросьте настройки. По умолчанию все должно работать. И пинги не нужны, надо мерить скорость на спидтесте или https://internet.yandex.ru" onclick back2top"> Вернуться к началу

Pierre Cardin писал(а): Подскажите пожалуйста, это делаетя как то программно, или обычными электро замерами с помощью электротестера?

Замерами просади напряжения.
Но для начала можете посмотреть в паспортных данных требуемую мощность потребление отдельно для роутера и отдельно для модема, если сумма мощностей будет превышать мощность штатного адаптера питания, то его следу заменить на более мощный.
PS
Вашего исходящего аплоада в 0,4 Мбайт/сек - в любом случае слишком мало для полноценного функционирования СВН (максимум что сможете получить - так это дай Бог, слайд шоу от одной камеры).

Сделал запрос производителям 4G Модема и Роутера
Модем потребляет более 500mA x 5v итого 2.5 Bатт
USB версии 2.0 которое на роутере сила тока ограничена 500 мА как я знаю, но это не точно
Производитель роутера написал что внутри устройства параметры могут отличаться. Я запросил у него средний разброс.
Роутер питается от адаптера 12v 1A.
Исходя из этих данных можно сделать какое нибудь заключение ?
Менял адаптер на 12v 2A. Ничего не менялось.

По поводу 0,4Мбайт/сек. Я живу в С-Пб, тестирую пока в городе и я пока не заметил каких то тормозов или изменения качества картинки. На днях поеду попробую протестирую прием на даче в 75км от города. Эту скорость можно увеличить ? или надо менять модем ?

Maximum transmission unit (MTU) это максимальный объём данных, который может быть передан протоколом за одну итерацию. К примеру, Ethernet MTU равняется 1500, что означает, что максимальный объём данных, переносимый Ethernet фреймом не может превышать 1500 байт (без учёта Ethernet заголовка и FCS — Рис. 1).

Рис. 1

Давайте пробежимся с MTU по уровням OSI:

Layer 2.

Ethernet MTU является частным случаем Hardware MTU. Определение Hardware MTU вытекает из общего определения:
Hardware MTU — это максимальный размер пакета, который может быть передан интерфейсом за одну итерацию (по крайней мере значение указано в спецификациях устройства – по факту некоторые чипсеты поддерживают передачу больших размеров пакетов, чем заявлено). Поэтому если взглянуть на рисунок 1 в отрыве от Ethernet, то получим следующее:

Рис. 2

Замечание: Однако и тут не обойтись без оговорки. Как вы видите, HW MTU (Ethernet MTU в частности) не включает заголовок L2 в себя. Однако это справедливо для IOS и IOS XE, но для IOS XR и JunOS заголовок L2 включен в размер HW MTU – Рис. 3. Эта особенность может привезти к проблемам при установке OSPF neighborship между платформами под управлением IOS(XE) и IOS XR (OSPF требует совпадения MTU в Hello пакетах). Поэтому, при конфигурации MTU для Ethernet интерфейсов, на стороне IOS XR MTU должно быть на 14 байт больше (12 байт src mac+dst mac и 2 байт EtherType). К примеру, MTU в 1500 в Cisco IOS эквивалентно MTU в 1514 для IOS XR.

Рис. 3

Конфигурация и проверка.

Для того что бы изменить MTU на маршрутизаторах под управлением Cisco IOS используется команда интерфейс уровня:

Layer3.

Конфигурация и проверка.

Для изменения IP MTU на маршрутизаторах под управлением Cisco IOS используется команда интерфейс уровня:

Вот те раз. Команда ip mtu не видна в show run. Да тут есть интересный нюанс – если ip mtu совпадает с hw mtu, то в выводе show run будет отображаться только hw mtu. Если значения разные то отображаются оба.

Layer 4.

TCP Maximum Segment Size (MSS) определяет максимальный размер TCP сегмента (без TCP заголовка!), который может быть использован (отправлен/принят) в ходе TCP сессии. Анонс (именно анонс, не хендшейк) размеров TCP MSS происходит во время установки TCP сессии – принимающая сторона анонсирует стороне отправляющей какой размер TCP сегмент она может принять. Соответственно размер TCP MSS может различаться в рамках одной TCP сессии в зависимости от направления.

Рис. 4

Сторона, производящая анонс, высчитывает значение TCP MSS для себя по следующей формуле:
TCM MSS = (IP MTU – [IPHDR + TCPHDR])

Конфигурация.

Тут у нас возможны два сценария – маршрутизатор является транзитным или участником TCP сессии.
1) Транзитное устройство:
Для предотвращения дропа пакетов промежуточным устройством в случае наличия линка с малым MTU, маршрутизатор будет прослушивать TCP SYN пакеты и подменять значения MSS анонсируемые конечным устройством. Что приведет к отправке пакетов меньшей величины конечным устройством и вуаля – проблема с дропами на линке с малым MTU упреждена.

2) Терминирующее устройство:
Здесь всё просто – маршрутизатор является участником TCP сессии и мы можем установить принудительно, размер MSS который он будет анонсировать.

Кажется всё? Нет, не всё. Вспоминаем про MPLS. Вспоминаем… Закончили вспоминать, переходим к рассмотрению.

Layer 2,5. MPLS.

Рис. 5

Что здесь ещё интересного? MPLS MTU может быть больше HW MTU (поэтому на Рис. 3 HW MTU частично обозначено пунктиром). При этом IOS выдаст варнинг, но в большинстве случаев будет работать (зависит от чипсета интерфейса) и успешно пропускать по крайней мере baby-giant фреймы. А в иной раз можно получить дроп пакетов, повреждение данных, и сто лет без урожая.

Конфигурация и проверка.

Замечание: MPLS MTU отображается в running конфиге, также как и IP MTU — только в случае, если значение отличается от HW MTU. Но, в отличие от IP MTU, любое изменение HW MTU меняет значение MPLS MTU до значения HW MTU (IP MTU это действие не меняет).

MTU на коммутаторах Cisco.

На заметку администратору.

Так как основным методом проверки MTU и по сей день является команда PING, с выставленным df-bit и рамером пакета, приведу в заключение пару полезных триков:

1) Для того, что бы найти минимальный MTU (забавное сочетание) на сети можно использовать расширенную команду ping, причём как c конечных станций/серверов так и с оборудования Cisco. Пропингуем с маршрутизатора R01 маршрутизатор R02 с выставленным df-bit, c начальным размером пакета в 1000 байт, конечным 1500 байт, и шагом 100 байт. Кол-во повторений 2.

Как видите, проходит только 6 ICMP пакетов размером 1000, 1100, 1200, 1300 байт
Начиная с 1400 байт и выше пакеты не проходят. Следовательно, минимальное MTU между двумя точками — 1300 и 1400, что можно уточнить ещё за несколько циклов, ужимая диапазон и умешьшая шаг.

2) Частая проблема возникающая при взаимодействии сетевых и системных администраторов — с конечного устройства проходят пакеты одного размера, с ближнего к нему сетевого устройства большего размера. Причина лежит в том, что операционные системы (в частности Windows), когда вы задаёте размер пакета команде ping, воспринимают это значение как чистый paiload — без заголовков ICMP и IP, т.е. при указании ping 192.168.1.2 -l 100 система будет генерировать пакеты величиной 128 байт, а не 100 (8 байт ICMP заголовок и 20 байт IP). При указании же размера ICMP пакета на сетевом оборудовании Cisco указываемый вами размер включает уже оба заголовка. Поэтому на дефолтном Ethernet линке пинги с Windows OS (к примеру) покажут 1472 байт максимальный размер пакета проходящий без фрагментации, а Cisco 1500 байт. JunOS, кстати ведет себя также как и операционные системы (не включает заголовки)

На этом всё. Есть ещё в закромах старый драфт статьи по размерам фреймов и их эволюции, где описаны понятия Jumbo Frame, Baby-Giant Frame, встречающиеся в этой статье. Если посчитаете нужным, могу доработать и выложить и её.

Однажды для каждого настоящего системного администратора (или исполняющего обязанности такового) наступает момент истины. Ему выпадает судьба настроить маршрутизатор на компьютере с установленной ОС 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.

Решение проблемы с 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 – этим вы создаете проблемы вашим колегам.

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