15.7. Решение проблемы с Path MTU Discovery путем настройки MSS.
Как уже говорилось выше, Path MTU Discovery не работает в Интернет должным образом. Если вам известны факты существования сегментов в вашей сети, где размер MTU ограничен, то вы уже не можете полагаться на безотказную работу Path MTU Discovery.
Однако, помимо MTU, есть еще один способ ограничения размера пакета — это, так называемый MSS (Maximum Segment Size — Максимальный Размер Сегмента). MSS — это поле в заголовке TCP-пакета SYN.
С недавних пор, ядра Linux и некоторые драйверы PPPoE, стали поддерживать такую особенность, как ‘clamp the MSS’ (ограничение размера MSS).
В этом есть свои плюсы и минусы. С одной стороны, устанавливая MSS, вы недвусмысленно извещаете удаленную сторону о том, что размер пакета не должен превышать заданную величину. Причем для этого не требуется передачи ICMP-сообщений.
С другой стороны — за атакущим сохраняется возможность нарушить связь путем модификации пакетов. Однако, следует заметить, что мы довольно часто используем эту возможность и это приносит свои положительные плоды.
Чтобы иметь возможность манипулировать размером сегмента, у вас должны быть установлены iptables , не ниже 1.2.1a и ядро Linux, не ниже 2.4.3. Основная команда iptables :
# iptables -A FORWARD -p tcp —tcp-flags SYN,RST SYN -j TCPMSS —clamp-mss-to-pmtu
Она рассчитает правильный MSS для вашего соединения. Если вы достаточно уверены в себе и в своих знаниях, можете попробовать нечто подобное:
# iptables -A FORWARD -p tcp —tcp-flags SYN,RST SYN -j TCPMSS —set-mss 128
Это правило устанавливает MSS равным 128. Очень полезно, если вы наблюдаете разрывы при передаче голосовых данных, когда поток небольших пакетов VoIP прерывается «огромными» http-пакетами.
| Назад | В начало документа | Вперед |
| Решение проблемы с Path MTU Discovery путем настройки MTU. | К началу раздела | Формирователь трафика: Низкая задержка, максимальная производительность. |
Провайдеры и MTU/MSS/PMTU
Значит нужен мне второй канал связи, да этак мегабит 300 в секунду. В моём городе немного провайдеров, поэтому выбрать не дали и пришлось подключаться к WiFire (он же NetByNet, MegaFon и так далее). Подключился, потестил, 300 мегабит, балдеж. Решил я значит почитать что нового на своем любимом Хабре и опа: он не открывается, но охотно пингуется.
Диагностика
Ну думаю: что-то тут не так. Сетевое у меня Mikrotik, возможностей уйма, пойду искать причину на своей стороне. Лезу в логи и вижу как посыпался DoH (РКН, приветик) и крайне удивляюсь этому. решил временно отрубить DoH и дать 1.1.1.1. Ситуация не изменилась. Начал резолвить адреса хотя бы чего-нибудь, все через раз. Решил прокинуть трейс до Хабра и смотрю на «потяряшки». Думаю дай звякну в поддержку, вдруг умное чего скажут. Те репу почесали, сказали что не видят мою сеть за роутером (nat >> forward >> change ttl >>+1 😀) и изобразили что-то вроде «Мы ХЗ».
Начал копать дальше. Вспомнил всю балду, которую знаю о пакетах и тут осенило.
Что такое 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 — не логировать
и бинго, наконец-то открывается Хабр и все что мне нужно.
В сетевой части я не «Ас», поэтому сумбурно вышло, да и на Хабре статьи не нашел похожей, может будет кому полезно.
iptables clamp-mss-to-pmtu и выбор цепочки.
Где правильно применять clamp-mss-to-pmtu и —set-mss в iptables. В FORWARD, в mangle FORWARD или в POSTROUTING? Сколько не смотрел доков и статей, единства не нашел.
iptables -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380 или iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380 или iptables -t mangle -A POSTROUTING -o tun0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1381:1536 -j TCPMSS --set-mss 1380
akv_
28.03.19 08:42:06 MSK
Общий ответ в mangle. А forward или postrouting зависит от желаемого результата, через forward пройдут только транзитные пакеты, через postrouting и транзитные и локальные.
anc ★★★★★
( 28.03.19 08:58:29 MSK )
Ответ на: комментарий от anc 28.03.19 08:58:29 MSK
Благодарю! Еще вопрос о направлении трафика достаточно одного правила out или нужно еще in?
akv_
( 28.03.19 12:27:37 MSK ) автор топика
Ответ на: комментарий от akv_ 28.03.19 12:27:37 MSK
Вы имеете в виду входящие/исходящие? mss корректируют у исходящих пакетов. Входящий к Вам уже пришел.
funky ★
( 28.03.19 15:17:49 MSK )
Ответ на: комментарий от funky 28.03.19 15:17:49 MSK
Некоторые сайты не открываются через тунель.
Вот так не работает, с одним правилом.
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu а если добавить:
iptables -t mangle -A FORWARD -i tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu То начинает работать.
akv_
( 28.03.19 18:58:41 MSK ) автор топика
Ответ на: комментарий от akv_ 28.03.19 18:58:41 MSK
Как я уже писал «зависит от желаемого результата». В общем случае построутинга хватит всем 🙂
anc ★★★★★
( 28.03.19 21:19:38 MSK )
Ответ на: комментарий от anc 28.03.19 21:19:38 MSK
В вашем примере это два почти разных по поведению правила. В первом случае пакет «нового соединения» который улетит с tun0 и без разницы с какого интерфейса он прилетел включая тот же tun0. Во втором, пакет «нового соединения» который прилетел на tun0 и улетит с любого интерфейса включая тот же tun0. Одинаковое поведение у этих правил будет только в случае если у пакета входящий и исходящий интерфейсы tun0.
ЗЫ Простите, может невнятно написал, в первом моем ответе я не рассматривал указание интерфейса, подразумевал только таблицу mangle и цепочку FORWARD или POSTROUTING.
anc ★★★★★
( 28.03.19 21:37:59 MSK )
Последнее исправление: anc 28.03.19 21:41:15 MSK (всего исправлений: 1)
Ответ на: комментарий от akv_ 28.03.19 18:58:41 MSK
Во первых, что у Вас за tun0? И во вторых, —clamp-mss-to-pmtu делают на интерфейсе, смотрящем в провайдера, т.е. никак не tun0. Если у Вас tun0 — это openvpn, то в нем самом нужно фиксить mss. Там есть параметр в конфиге, нет под рукой — погуглите.
funky ★
( 29.03.19 11:15:46 MSK )
Ответ на: комментарий от funky 29.03.19 11:15:46 MSK
Схема следующая, туннель gre/ipsec на одном конце MikroTik на другом VPS Ubuntu. MTU на туннельном интерфейсе 1418 одинаков и на Linux и на Mikrotik. Со стороны Mikrotik есть несколько клиентов которые должны ходить через этот тунель. Возникла проблема с некоторым кол-вом сайтов, которые не открываются, видимо PMTUD по какой либо причине не может быть задействован. По этой причине возникла идея с MSS. Сейчас на Ubuntu:
iptables -t mangle -A FORWARD -i tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu C этим правилом все работает. Мне нужно менять MSS только на туннельном интерфейсе.
akv_
( 29.03.19 13:10:24 MSK ) автор топика
Ответ на: комментарий от anc 28.03.19 21:19:38 MSK
Ну вот у меня например wifi на мобилу раздаётся, мне как прописывать?
anonymous
( 29.03.19 13:20:25 MSK )
Ответ на: комментарий от anonymous 29.03.19 13:20:25 MSK
iptables -t mangle -A POSTROUTING -p tcp —tcp-flags SYN,RST SYN -j TCPMSS —clamp-mss-to-pmtu
anc ★★★★★
( 29.03.19 23:20:13 MSK )
Ответ на: комментарий от funky 29.03.19 11:15:46 MSK
И во вторых, —clamp-mss-to-pmtu делают на интерфейсе, смотрящем в провайдера, т.е. никак не tun0.
Да шо ви говорите? Ну вот интерфейс прова у меня eth1, но дэфроут улетает на tun15 через прова по udp, и как мне поможет в этом случае исправление mss на интерфейсе eth1 ?
А если нет? Что делааать, что делааать? Памагите.
Вы очень узко рассматриваете задачу, в виде один входящий, один исходящий и mss-to-pmtu. Но вот представьте вариант (не реальный, но описывающий саму проблему). У вас сервер на котором исходящих интерфейсов более одного, на котором:
1. сервер ovpn1, всем клиентам на исходящие новые соединения надо установить mss 1000, клиентов раскидываем по разным исходящим интерфейсам.
2. серер ovpn2, всем клиентам на исходящие новые соединения надо установить mss 1200, клиентов раскидываем по разным исходящим интерфейсам.
3. ipsec — клиентам устанавливаем mss 1380
4. локальный исходящий, mss не трогаем
Решение возможно только с указанием входящего интерфейса (в случае ipsec направления), но никак не исходящего.
Mss clamping что это
You are using an outdated browser. Please upgrade your browser to improve your experience.
expand-card-line
calendar-line —>
TCP MSS clamping enables you to reduce the maximum segment size (MSS) value used by a TCP session during a connection establishment through a VPN tunnel.
TCP MSS is the maximum amount of data in bytes that a host is willing to accept in a single TCP segment. Each end of a TCP connection sends its desired MSS value to its peer-end during the three-way handshake, where MSS is one of the TCP header options used in a TCP SYN packet. The sender host calculates the TCP MSS based on the maximum transmission unit (MTU) of its egress interface.
When a TCP traffic goes through any kind of VPN tunnel, additional headers are added to the original packet to keep it secure. For IPSec tunnel mode, additional headers used are IP, ESP, and optionally UDP (if a port translation is present in the network). Because of these additional headers, the size of the encapsulated packet goes beyond the MTU of the VPN interface. The packet can get fragmented or dropped based on the DF policy.
To avoid packet fragmentation or drop in an IPSec VPN session, you can adjust the MSS value for the IPSec session by enabling the TCP MSS clamping feature. Navigate to Networking > VPN > IPSec Sessions . When you are adding an IPSec session or editing an existing one, expand the Advanced Properties section, and enable TCP MSS Clamping . By default, the TCP MSS Clamping feature is disabled for an IPSec session.
When the TCP MSS Clamping feature is enabled for an IPSec session, you can configure the pre-calculated MSS value suitable for the IPSec session by setting both TCP MSS Direction and TCP MSS Value . The configured MSS value is used for MSS clamping. You can opt to use the dynamic MSS calculation by setting the TCP MSS Direction and leaving TCP MSS Value blank. The MSS value is auto-calculated based on the VPN interface MTU, VPN overhead, and the path MTU (PMTU) when it is already determined. The effective MSS is recalculated during each TCP handshake to handle the MTU or PMTU changes dynamically. See Add a Policy-Based IPSec Session or Add a Route-Based IPSec Session for more information.
Similarly, for L2 VPN, TCP MSS Clamping configuration is given only in the L2 VPN server session. You can navigate to Networking > VPN > L2 VPN Sessions . Select Add L2 VPN Session > L2 VPN Server and expand the Advanced Properties section. TCP MSS Clamping is enabled by default for both the directions with auto-calculation mode, but you can configure a desired TCP MSS value that is suitable for the topology or disable it. See Add an L2 VPN Server Session for more information.