Проблеми MTU: прихована причина «деякі сайти не завантажуються»

Ментальна модель: чому MTU ламає «лише частину» трафіку

MTU (Maximum Transmission Unit) — максимальний розмір IP‑пакета, який може пройти інтерфейс без фрагментації. За замовчуванням MTU Ethernet — 1500 байт. Це число старе, практичне й досі скрізь. Проблема в тому, що сучасні мережі — це стек тунелів, оверлеїв, VPN і «дружніх» середніх пристроїв. Кожний рівень краде байти під заголовки. Якщо ви не врахуєте цей оверхед, пакети, які раніше вміщувалися, перестануть вміщуватись.

Коли пакет надто великий для наступного хопа, можливі кілька результатів:

• Відбувається фрагментація (тільки IPv4, якщо вона дозволена): маршрутизатор розбиває пакет. Часто це працює, але повільніше й крихке. Деякі пристрої неправильно обробляють фрагменти. Деякі політики безпеки їх відкидають.
• Пакет відкидається і повертається ICMP‑повідомлення: «потрібна фрагментація» (IPv4) або «Packet Too Big» (IPv6). Це здоровий шлях для Path MTU Discovery.
• Пакет відкидається і жодного корисного ICMP не повертається: це сумнозвісна PMTUD‑чорна діра. TCP продовжує перевідправляти великі пакети, які ніколи не доходять. З боку застосунку виглядає, ніби все «зависло».

Чому це вражає тільки деякі сайти? Тому що не всі потоки генерують пакети однакового розміру. Малий HTTP‑відповідь може влізти. Великий TLS‑запис, запит з великою кукою або сервер, що одразу відправляє сегмент повного розміру, можуть перевищити реальний path MTU. Деякі CDN і деякі сайти просто краще «викликають» вашу зламану трасу, ніж інші.

Ще одна важлива деталь: TCP MSS (Maximum Segment Size) контролює розмір корисного навантаження TCP, що зазвичай дорівнює MTU мінус заголовки IP+TCP. Якщо ви коректно обмежите MSS на межі тунелю, можна уникнути генерації занадто великих пакетів з самого початку. Це пластир із легітимним застосуванням.

Сухий гумор: баги MTU — це мережевий еквівалент дверей, що відчиняються всередину, коли пожежний регламент вимагає назовні — ви дізнаєтесь про це тільки під час паніки.

На рівні пакетів: що зазвичай означає «деякі сайти не завантажуються»

Типова послідовність відмови:

1. Клієнт резолвить DNS і підключається до IP сервера: OK.
2. TCP‑тривидовий рукопотиск (SYN, SYN/ACK, ACK): OK (малі пакети).
3. TLS‑рукостискання починається: часто перші кроки OK.
4. Сервер відправляє більший пакет (сертифікатний ланцюг, HTTP‑заголовки або початковий контент): пакет відкидається, якщо перевищує path MTU і PMTUD зламаний.
5. Клієнт чекає, повторює спроби, браузер крутить коліщатко, і хтось звинувачує SaaS‑провайдера.

Факти та історія: як ми дійшли до цього

Проблеми MTU здаються сучасними, бо ми найчастіше бачимо їх із VPN та оверлейними мережами, але інгредієнти старі. Кілька конкретних фактів і історичних моментів, що важливі для практики:

1. MTU 1500 байт для Ethernet стало поширеним, бо балансувало ефективність і апаратні обмеження в ранніх Ethernet‑дизайнах; це фактично «контракт за замовчуванням» для багатьох пристроїв.
2. PPPoE відомо зменшує MTU до 1492 через накладні витрати інкапсуляції; це столітня проблема для DSL і деяких оптоволоконних підключень.
3. Path MTU Discovery (PMTUD) покладається на ICMP «too big» зворотний зв’язок; коли мережі почали блокувати ICMP масштабно заради «безпеки», відмови PMTUD стали рутинними.
4. IPv6 забороняє фрагментацію в мережі; тільки кінцеві вузли можуть фрагментувати. Це робить ICMPv6 «Packet Too Big» обов’язковим для функціонального інтернету.
5. IPsec, GRE, VXLAN та WireGuard додають оверхед; безпечний MTU всередині тунелів часто нижчий, ніж люди припускають, особливо при багатошаровій інкапсуляції.
6. Jumbo frames (MTU 9000) корисні в контрольованих доменах, але стають проблемою, коли випадково поширюються через межі, які не підтримують їх.
7. TCP MSS clamping став поширеним обхідним шляхом у фаєрволах та граничних маршрутизаторах саме тому, що PMTUD у реальному житті ненадійний.
8. «Не блокувати ICMP» — стандартна порада роками, але багато корпоративних мереж досі роблять це частково — часто дозволяють echo, але блокують «потрібна фрагментація», що є неправильною половиною.
9. Поведінка браузерів посилює проблему: сучасні браузери відкривають багато з’єднань, використовують HTTP/2 або HTTP/3 і можуть приховувати затримки по одному з’єднанню під «крутяче» індикатором, що виглядає як баг застосунку.

Один вислів, який варто тримати в голові кожної операційної команди: Усе ламається, весь час. — Werner Vogels. Коротко, трохи похмуро і операційно правильно.

Швидка діагностика (першочергово/друге/третє)

Якщо у вас є десять хвилин і користувач кричить «лише деякі сайти», робіть це в порядку. Не імпровізуйте. Імпровізація призводить до перезавантаження не того маршрутизатора о 2‑й ночі.

Перше: перевірте, що це відмова MTU

• Відтворіть проблему з хоста на тому самому шляху, що й користувач (той самий VPN, VLAN, Wi‑Fi).
• Перевірте чи працюють малі відповіді, а великі зависають (це маркер).
• Використайте DF‑ping‑тест, щоб знайти найбільший робочий розмір пакета.

Друге: знайдіть межу, де MTU змінюється

• Шукайте тунелі: VPN, IPsec, GRE, WireGuard, cloud transit gateway, SD‑WAN, оверлеї, WAN‑оптимізатори.
• Порівняйте MTU інтерфейсів по обидва боки: NIC клієнта, тунельний інтерфейс, фаєрвол внутрішній/зовнішній, cloud ENI.
• Підтвердіть, що ICMP «too big» дозволений наскрізь (або компенсуйте MSS‑clamp‑ом).

Третє: застосуйте найменш ризикове виправлення

• Надавайте перевагу виправленню MTU/PMTUD і дозволу потрібних ICMP‑повідомлень.
• Якщо політика чи пристрої постачальника блокують це, застосуйте TCP MSS clamping на межі тунелю як прагматичний обхідний шлях.
• Документуйте обраний MTU і додайте його в процеси провізіонування, а не тримайте в колективній пам’яті.

Короткий жарт (останній у цьому документі): найпростіший спосіб знайти баг MTU — оголосити інцидент «ймовірно DNS». Він одразу перетвориться на MTU з принципу суперечності.

Шаблони симптомів, що кричать “MTU”

1) TLS‑рукостискання зависає після ClientHello/ServerHello

Малі пакети проходять. Потім сертифікатний ланцюг або більший handshake‑повідомлення викликає занадто великий пакет. Якщо ICMP заблоковано, жоден кінцевий вузол не дізнається path MTU, тож він продовжує слати пакети, які ніколи не доходять.

2) HTTP‑заголовки доходять, але великі завантаження падають на початку

Перша відповідь вміщується. Більші сегменти — ні. Користувачі кажуть «сторінка завантажується, але зображення не підвантажуються» або «вхід працює, але дашборд ні».

3) Працює через мобільний хот‑спот, але падає через корпоративний Wi‑Fi/VPN

Різний маршрут, різний MTU, різна ICMP‑політика. Мобільні оператори теж мають свої MTU‑особливості, але шлях інший настільки, що уникає вашої чорної діри.

4) SSH підключається, але scp зависає

Інтерактивні натискання клавіш — малі. Передача файлів заповнює TCP‑сегменти й швидко виявляє проблеми MTU.

5) IPv4 працює, IPv6 — ні (або навпаки)

IPv6 потребує ICMPv6 PTB для нормальної роботи. Якщо фаєрвол блокує його, ви отримаєте селективні IPv6‑проблеми. Навпаки, деякі IPv4‑шляхи «працюють» завдяки фрагментації, тоді як IPv6 ламався різко.

6) Kubernetes/контейнери: від вузла до зовнішнього працює, від пода — ненадійно

Оверлейні мережі (VXLAN, Geneve) зменшують ефективний MTU всередині кластера. Якщо MTU CNI неправильний, поди генерують пакети, які відкидаються при egress.

Практичні завдання: команди, виводи, рішення (12+)

Ось команди, які я реально виконую на виклику втомленим. Кожне завдання містить: команду, приклад виводу, що це означає і яке рішення прийняти.

Завдання 1: Перевірити локальний MTU інтерфейсу

cr0x@server:~$ ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff

Значення: Хост вважає, що mtu eth0 — 1500. Це лише перший хоп, а не весь шлях.

Рішення: Якщо очікуєте тунель/оверлей, перевірте цей інтерфейс теж. Не припускайте, що 1500 безпечно end‑to‑end.

Завдання 2: Перелічити тунельні інтерфейси та їх MTU

cr0x@server:~$ ip -d link show | egrep -A2 'mtu|wg0|tun0|gre|vxlan'
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none
7: vxlan.calico: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default

Значення: WireGuard 1420, VXLAN 1450. Оверхед врахований принаймні локально.

Рішення: Якщо користувачі скаржаться через VPN, 1420 може бути ще занадто великим залежно від андерлею. Перевірте DF‑ping.

Завдання 3: DF‑ping для знаходження максимально робочого MTU (IPv4)

cr0x@server:~$ ping -M do -s 1472 -c 3 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1492
ping: local error: message too long, mtu=1492
ping: local error: message too long, mtu=1492

--- 1.1.1.1 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

Значення: Ви намагались відправити IP‑пакет 1500 байт загалом (1472 payload + 28 байт заголовки). Ядро каже, що ефективний MTU — 1492 десь локально (часто PPPoE).

Рішення: Зменшіть payload, поки не пройде. Потім встановіть MTU тунелю або MSS‑clamp відповідно.

Завдання 4: Бінарний пошук робочого payload‑розміру

cr0x@server:~$ ping -M do -s 1464 -c 2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1464(1492) bytes of data.
1472 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=13.4 ms
1472 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=13.2 ms

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

Значення: Шлях підтримує IP‑пакети 1492 байти (payload 1464 + 28 байт заголовків).

Рішення: Якщо у вас VPN поверх цього лінку, відніміть оверхед тунелю від 1492, а не від 1500.

Завдання 5: Перевірити PMTUD‑ICMP у захопленні пакетів

cr0x@server:~$ sudo tcpdump -ni eth0 'icmp and (icmp[0]=3 and icmp[1]=4)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:01:44.912345 IP 203.0.113.1 > 192.0.2.10: ICMP unreachable - need to frag (mtu 1420), length 36

Значення: Ви отримуєте «need to frag» з підказкою mtu. PMTUD принаймні частково функціонує.

Рішення: Якщо ви ніколи не бачите таких повідомлень, коли очікуєте, підозрюйте правила фаєрвола, що відкидають ICMP тип 3 код 4 (IPv4) або ICMPv6 PTB.

Завдання 6: Перевірити, чи ICMP блокується на фаєрволі (nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    ip protocol icmp icmp type echo-request accept
    ip6 nexthdr icmpv6 icmpv6 type echo-request accept
  }
}

Значення: Дозволені echo‑запити, але інші типи ICMP — ні. Це класична конфігурація «ping працює, PMTUD помирає».

Рішення: Дозвольте ICMP «fragmentation needed» (IPv4) і «packet too big» (IPv6) принаймні; краще дозволити відповідні типи ICMP помилок широко.

Завдання 7: Підтвердити TCP MSS, що рекламується в SYN

cr0x@server:~$ sudo tcpdump -ni eth0 'tcp[tcpflags] & (tcp-syn) != 0 and host 93.184.216.34' -c 3
12:05:01.100001 IP 192.0.2.10.51544 > 93.184.216.34.443: Flags [S], seq 1234567890, win 64240, options [mss 1460,sackOK,TS val 111 ecr 0,nop,wscale 7], length 0
12:05:01.200002 IP 192.0.2.10.51545 > 93.184.216.34.443: Flags [S], seq 1234567891, win 64240, options [mss 1460,sackOK,TS val 112 ecr 0,nop,wscale 7], length 0
12:05:01.300003 IP 192.0.2.10.51546 > 93.184.216.34.443: Flags [S], seq 1234567892, win 64240, options [mss 1460,sackOK,TS val 113 ecr 0,nop,wscale 7], length 0

Значення: MSS 1460 натякає на припущення MTU 1500 (1460 payload + 40 байт IPv4+TCP заголовки).

Рішення: Якщо реальний path MTU — 1492 або нижче (або тунель його зменшує), слід знизити MSS на межі, щоб кінцеві вузли не надсилали занадто великі сегменти.

Завдання 8: Застосувати MSS‑clamping (iptables) як обхід

cr0x@server:~$ sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
cr0x@server:~$ sudo iptables -t mangle -S FORWARD | tail -n 3
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Значення: Ви переписуєте MSS у SYN‑пакетах на основі route MTU. Це часто дозволяє уникнути чорних дір навіть коли ICMP блокується.

Рішення: Використовуйте це, коли швидко виправити фільтрацію ICMP неможливо. Все одно заплануйте «справжнє» виправлення: коректний MTU і ICMP‑політика.

Завдання 9: Діагностика з tracepath (Linux)

cr0x@server:~$ tracepath 93.184.216.34
 1?: [LOCALHOST]                        pmtu 1500
 1:  192.0.2.1                           0.381ms
 2:  198.51.100.1                        1.992ms pmtu 1492
 3:  203.0.113.9                         6.110ms
 4:  93.184.216.34                      12.834ms reached
     Resume: pmtu 1492 hops 4 back 4

Значення: Path MTU виявлено як 1492 на хопі 2. Це цінна та дієва інформація.

Рішення: Якщо tracepath не може виявити PMTU (залишається підозріло 1500), підозрюйте блокування ICMP PTB/frag‑needed або асиметричну трасу.

Завдання 10: Перевірити hint MTU в Linux

cr0x@server:~$ ip route get 93.184.216.34
93.184.216.34 via 192.0.2.1 dev eth0 src 192.0.2.10 uid 1000
    cache mtu 1492

Значення: Кеш маршруту ядра вважає, що PMTU для цього призначення — 1492.

Рішення: Якщо застосунки все ще зависають, проблема може бути в іншому місці (TLS‑інспекція, проксі), або PMTU відрізняється для інших напрямків.

Завдання 11: Перевірити базову PMTUD‑поведінку IPv6

cr0x@server:~$ ping6 -c 2 -s 1452 -M do 2606:4700:4700::1111
PING 2606:4700:4700::1111(2606:4700:4700::1111) 1452 data bytes
1460 bytes from 2606:4700:4700::1111: icmp_seq=1 ttl=57 time=14.1 ms
1460 bytes from 2606:4700:4700::1111: icmp_seq=2 ttl=57 time=14.0 ms

--- 2606:4700:4700::1111 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Значення: Великі IPv6‑пакети проходять з DF‑семантикою (IPv6 не фрагментує в маршрутизаторі). Це добрий знак.

Рішення: Якщо IPv6 падає тільки при більших розмірах, перевірте фільтрацію ICMPv6 типу 2 (Packet Too Big) на фаєрволах.

Завдання 12: Виявити невідповідність MTU контейнер/CNI (нод Kubernetes)

cr0x@server:~$ ip link show dev cni0
9: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 0a:58:0a:f4:00:01 brd ff:ff:ff:ff:ff:ff
cr0x@server:~$ ip link show dev vxlan.calico
7: vxlan.calico: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default

Значення: Міст має 1500, але VXLAN — 1450. Поди можуть намагатись використовувати 1500 і постраждати після інкапсуляції.

Рішення: Встановіть MTU CNI/місту відповідно до ефективного оверлей‑MTU (часто 1450) так, щоб поди ніколи не генерували надто великі кадри.

Завдання 13: Підтвердити, чи PMTUD чорна діра, перевіривши великий TCP‑трансфер

cr0x@server:~$ curl -I --max-time 10 https://example.com/
HTTP/2 200
content-type: text/html
server: envoy

cr0x@server:~$ curl --max-time 10 -o /dev/null -sS https://example.com/largefile.bin
curl: (28) Operation timed out after 10002 milliseconds with 0 bytes received

Значення: Малі запити працюють; великий трансфер зависає. Не доказ, але сильний сигнал MTU/фрагментації.

Рішення: Негайно запустіть DF‑ping / tracepath і інспектуйте фільтрацію ICMP. Не витрачайте годину на теорії про TLS‑шифри.

Завдання 14: Спостерігати повторні відправлення і «застряглі» великі сегменти

cr0x@server:~$ sudo ss -ti dst 93.184.216.34:443 | sed -n '1,20p'
ESTAB 0 0 192.0.2.10:51544 93.184.216.34:443
	 cubic wscale:7,7 rto:204 rtt:52.3/1.2 ato:40 mss:1460 pmtu:1500 rcvmss:536 advmss:1460 cwnd:10 bytes_acked:3456 bytes_received:1200 segs_out:45 segs_in:38 retrans:8/12

Значення: Є повторні відправлення. MSS — 1460, pmtu виглядає як 1500, але попередні тести показували менший path MTU — щось неузгоджене.

Рішення: Підозрюйте, що ICMP «too big» не доходить до цього хоста (або асиметрична фільтрація). Впровадьте MSS‑clamp і виправте ICMP‑політику.

Три корпоративні міні‑історії з полів

Міні‑історія 1: Інцидент через хибне припущення

Компанія мала гібридне середовище: офіси на місці, VPC у хмарі і «простий» IPsec‑тунель між ними. Усім здавалося, що тунель — це просто труба. Він був встановлений роками, «працював», і нікому не подобалось ним займатись.

Потім у хмарі з’явився новий внутрішній веб‑додаток за зворотнім проксі. Користувачі в одному офісі повідомили, що сторінка входу завантажується, але після введення даних браузер крутиться вічно. Команда додатку не бачила помилок. Метрики балансувальника навантаження в хмарі були в нормі. Підтримка виконала класичний ритуал: почистити кеш, інший браузер, перезавантажити ноутбук. Нічого консистентного.

SRE нарешті відтворив проблему, підключившись через ту конкретну офісну мережу. TCP‑рукопотиск пройшов. TLS почався. Потім відповідь загинула в повітрі. Ключова деталь: цей офіс нещодавно перейшов на нового ISP з PPPoE. Їхній крайовий фаєрвол все ще припускав 1500, а оверхед IPsec виштовхнув пакети за реальний path MTU.

Хибне припущення було простим: «Ethernet — 1500, отже шлях — 1500». Виправлення теж було простим: налаштувати MTU тунелю і дозволити потрібні типи ICMP. Тимчасовий MSS‑clamp стабілізував ситуацію одразу. Постмортем‑задача була нудною, але важливою: задокументувати реальний MTU‑бюджет для кожного лінка і тунелю та перевіряти його при зміні провайдера.

Міні‑історія 2: Оптимізація, яка обернулась проти них

Інша організація вирішила «оптимізувати продуктивність» у дата‑центрі, увімкнувши jumbo frames по всій мережі. Було багато трафіку збереження, vMotion, бекапи — все виглядало чисто на папері: менше пакетів, менше переривань, вищий пропуск. Мережна команда поступово розгорнула це, і всередині дата‑центру виглядало нормально.

Потім був незначний крок: нова пара фаєрволів на межі, теж з jumbo frames на внутрішніх інтерфейсах. Припущення було, що «більше краще» і все внутрішнє це підтримує. Однак один сегмент не підтримував: старий апарат балансувальника в віддаленому стійці залишився на 1500 і не отримав оновлення.

Більшість сервісів не помітили. Ось у чому хитрість MTU‑багів: малі контрольні пакети працювали. Health check‑и були малі. Балансувальник пропускав деякі запити. Але великі відповіді та деякі TLS‑записи зникали у безодні. Патерн відмов був сюрреалістичним: «Сайт працює для мене, якщо я не натискаю на вкладку звітів».

Проблемою не були самі jumbo frames, а віра, що MTU можна змінювати як косметичну опцію. Ні — MTU — це контракт, і ви не можете односторонньо його переглядати. Вони виправили це, забезпечивши послідовність MTU у кожному L2‑домені, додавши автоматичні перевірки і відмовившись змішувати 1500 і 9000 без явного шлюзу.

Міні‑історія 3: Нудна, але правильна практика, що врятувала ситуацію

Фінтех‑компанія експлуатувала кілька концентраторів VPN для віддалених працівників. Нічого екзотичного: split tunnel для деяких сервісів, full tunnel для інших. У них була політика зміни, яка звучала надто консервативно: будь‑який новий профіль тунелю повинен включати MTU‑тест і збережене «відомо‑гарне» правило MSS‑clamp, навіть якщо його не вмикають за замовчуванням.

Під час відмови провайдера вони переключили один VPN‑ендпоінт на запасний транзитний шлях. Раптом невеликий відсоток користувачів не міг доступитись до кількох SaaS‑додатків. Більшість користувачів були в порядку. Тікети в службі підтримки були заплутані й суперечливі, бо саме так поводяться селективні відмови.

На‑черговому SRE відкрив ранубук, виконав DF‑ping з тестового хоста за шляхом відкату і підтвердив, що ефективний MTU зменшився. Вони ввімкнули заздалегідь погоджений MSS‑clamp для того VPN‑профілю і закрили інцидент швидко, без дебатів про політику фаєрвола в критичний момент.

Пізніше вони виконали «справжнє» виправлення (узгодження ICMP‑політик і коректні MTU‑налаштування), але нудна практика — мати протестований, готовий до увімкнення обхід — перетворила нічну містерію в короткий інцидент з чітким таймлайном.

Поширені помилки: симптом → корінь → виправлення

1) «Ping працює, отже мережа в порядку» → дозволено echo, але PMTUD ICMP заблокований → дозволити потрібні типи ICMP

Симптом: ping вдається, але HTTPS тупить або великі завантаження не виконуються.

Корінь: Фаєрвол дозволяє echo‑request/reply, але відкидає ICMP «fragmentation needed» (IPv4 type 3 code 4) і/або ICMPv6 Packet Too Big.

Виправлення: Дозвольте PMTUD‑пов’язані ICMP. Якщо не можете — застосуйте TCP MSS clamping на межі.

2) «VPN піднято, отже він може нести нормальний трафік» → оверхед тунелю не бюджетовано → зменшити MTU тунелю та/або MSS clamp

Симптом: SSH працює, scp зависає; деякі веб‑додатки частково завантажуються.

Корінь: IPsec/GRE/WireGuard додають оверхед і зменшують ефективний MTU. Кінцеві вузли все ще надсилають MSS, базований на 1500.

Виправлення: Встановіть MTU тунелю на безпечне значення (зазвичай 1380–1420 залежно від стеку) і перевірте через DF‑ping. Додайте MSS‑clamp, якщо потрібно.

3) «Ми увімкнули jumbo frames, нічого негайно не зламалось» → змішані MTU в одному L2 домені → забезпечити узгодженість MTU по сегменту

Симптом: періодичні відмови, часто залежні від розміру; моніторинг переважно зелений.

Корінь: Деякі лінки/пристрої на 9000, інші на 1500; чорні діри з’являються на межах.

Виправлення: Стандартизувати MTU по VLAN/L2. Там, де потрібно з’єднувати, маршрутизувати між доменами і коректно клампати/фрагментувати.

4) «Це баг застосунку» → TCP повторно відправляє, браузер чекає → доведіть це тестами розміру пакета

Симптом: лише певні сторінки або постачальники SaaS падають; інженери сперечаються в Slack.

Корінь: Великі сегменти відкидаються через PMTUD‑відмову; застосунок просто бачить затримку.

Виправлення: Запустіть tracepath і DF‑ping; зафіксуйте ICMP PTB/frag‑needed; виправте ICMP або застосуйте MSS‑clамп.

5) «IPv6 опційний» → ICMPv6 PTB заблокований → виправити політику фаєрвола для IPv6

Симптом: IPv6‑з’єднання зависають для деяких сайтів; перехід на IPv4 іноді маскує проблему.

Корінь: Блокування ICMPv6 руйнує PMTUD; IPv6 покладається на це.

Виправлення: Дозвольте ICMPv6 помилки включно з Packet Too Big; перевірте ping6 -M do тести.

6) «Контейнери — це просто процеси» → MTU CNI невірний для оверлею → встановити MTU пода/місту безпечним для андерлею

Симптом: нода може досягти зовнішніх сайтів, поди — ні (або несправно).

Корінь: Оверлей додає інкапсуляцію; якщо поди використовують 1500, вони перевищують андерлей MTU після інкапсуляції.

Виправлення: Налаштуйте CNI MTU (часто 1450 для VXLAN на андерлеї 1500, але перевіряйте). Розгортайте обережно; це впливає на мережу подів.

Контрольні списки / покроковий план

Контрольний список для інциденту: коли «деякі сайти не завантажуються» в проді

1. Відтворіть на шляху: тестуйте з тієї самої мережевої ділянки/VPN, що й постраждалі користувачі.
2. Запустіть DF‑ping‑сайзинг: визначте максимальний робочий розмір пакета до стабільного зовнішнього IP.
3. Запустіть tracepath: подивіться, чи визначається PMTU і де вона падає.
4. Перевірте ICMP‑політику фаєрвола: підтвердіть, що frag‑needed/PTB дозволені, а не лише echo.
5. Перевірте MTU тунелів/оверлеїв: порівняйте MTU фізичного NIC, тунелю та віртуальних інтерфейсів.
6. Шукайте повторні відправлення: використайте ss -ti і tcpdump, щоб підтвердити повтори великих сегментів і відсутність ICMP.
7. Застосуйте безпечний обхід: MSS‑clamp на відповідній межі, якщо потрібен негайний рілiф.
8. Перевірте великим трансфером: curl великого об’єкта, scp файлу або тест із відомого проблемного сайту.
9. Запишіть, що змінилось: заміна провайдера, новий фаєрвол, нова CNI‑конфігурація, політика SD‑WAN — MTU‑баги люблять вікна змін.

Контрольний список для змін: запобігти MTU‑баґам заздалегідь

1. Визначте MTU‑домени: по VLAN, по WAN‑лінку, по типу тунелю. Не змішуйте 1500 і 9000 бездумно.
2. Бюджетуйте оверхед: документуйте інкапсуляційний оверхед для кожного тунелю/оверлею у вашому середовищі.
3. Стандартизуйте CNI MTU: встановлюйте його явно; не дозволяйте дефолтам блукати по кластерам.
4. Перегляньте ICMP‑політику: дозвольте PMTUD‑пов’язані типи ICMP. Розглядайте їх як трафік для надійності, а не «шум».
5. Майте протестований MSS‑clamp‑план: знайте, де його застосувати і як відкотити.
6. Автоматизуйте верифікацію: запускайте заплановані DF‑ping/tracepath‑перевірки з ключових сегментів і алертуйте при зміні PMTU.
7. Документуйте «відомо‑гарні» значення: зберігайте MTU/MSS‑налаштування в infrastructure‑as‑code і в ранубуках.

Таблиця рішень: що виправляти в якому порядку

• Якщо ICMP PTB/frag‑needed заблоковано: виправте політику фаєрвола першочергово; MSS‑clamp як тимчасовий захід.
• Якщо MTU тунелю встановлено вище, ніж бюджет андерлею: знизьте MTU тунелю; потім протестуйте. Не покладайтеся тільки на MSS‑clamp, якщо це можна уникнути.
• Якщо задіяні jumbo frames: перевірте кожний хоп на підтримку. Якщо не можете гарантувати, тримайте jumbo лише в контрольованій зоні і маршрутуйте на межі.
• Якщо лише поди падають: виправте конфігурацію CNI/оверлею; не «вирішуйте» це випадковими sysctl на нодах.

FAQ

1) Чому лише деякі сайти падають, а не все?

Тому що лише деякі потоки генерують пакети достатньо великі, щоб перевищити реальний path MTU. Малі запити працюють; великі TLS‑записи, заголовки або відповіді — ні.

2) Якщо PMTUD існує, чому це досі проблема?

PMTUD потребує ICMP‑зворотного зв’язку. Багато мереж блокують саме ті ICMP‑повідомлення, які необхідні PMTUD, створюючи чорні діри. Механізм нормальний; операційна реальність — хаотична.

3) Чи справді блокування ICMP «більш безпечне»?

Ні, принаймні не в корисному сучасному сенсі. Селективне блокування ICMP шкодить діагностиці й базовим функціям (особливо в IPv6). Хороша безпека — це stateful‑фільтрація і принцип найменшої привілейованості, а не саботаж контрольної площини.

4) Чи просто клампати TCP MSS скрізь і забути?

Ні. MSS‑clamping — легітимний обхід на межах тунелю і на краю, але масове клампування може приховати підлягаючі проблеми і необґрунтовано зменшувати продуктивність. Спершу виправляйте ICMP і коректність MTU; клампіть там, де це виправдано.

5) Який MTU ставити для WireGuard?

Універсального числа немає. 1420 — поширений вибір, бо часто працює поверх типового андерлею 1500, але PPPoE, додаткові тунелі або особливості провайдера можуть вимагати менших значень. Вимірюйте DF‑ping‑ами і підлаштовуйте.

6) Як це стосується HTTP/3 і QUIC?

QUIC працює поверх UDP і все ще залежить від path MTU. Поведінка фрагментації інша, але суть та сама: занадто великі пакети відкидаються. QUIC‑стеки часто використовують PMTUD‑подібну логіку, тож фільтрація ICMP усе ще шкодить.

7) Мій ISP каже, що їхній MTU — 1500. Чому tracepath показує 1492?

Тому що частина вашого шляху (часто PPPoE або інша інкапсуляція) зменшує ефективний MTU. Заява «ISP MTU 1500» зазвичай стосується одного сегмента, а не вашого end‑to‑end шляху.

8) Чи можуть проблеми MTU виглядати як проблеми DNS?

Так, опосередковано. Якщо DNS‑відповіді великі (DNSSEC, багато записів) і шлях неправильно обробляє фрагментацію або блокує ICMP, DNS по UDP може селективно падати. Але «деякі сайти не завантажуються» частіше — це TCP/TLS MTU‑болі.

9) Яке найнадійніше негайне пом’якшення під час інциденту?

Увімкніть MSS‑clamping на крайовому пристрої, що форвардить трафік у проблемний тунель/шлях, а потім перевірте великими трансферами. Після гасіння пожежі виправте ICMP‑політику і коректні MTU‑налаштування.

10) Як довести MTU скептично налаштованій команді?

Покажіть «до/після»: максимальний розмір у DF‑ping, tracepath із падінням PMTU і захоплення пакетів з великими сегментами, що повторно відправляються без ICMP PTB. Потім застосуйте MSS‑clamp і продемонструйте, що проблема зникає.

Наступні кроки, які ви справді можете зробити

Проблеми MTU не гламурні. Вони навіть не цікаві в приємному сенсі. Вони цікаві в тому «чому тільки ноутбук генерального директора не може завантажити платіжну відомість» сенсі.

Зробіть наступне, у цьому порядку:

1. Додайте MTU/PMTU‑перевірки до інцидентної пам’яті: DF‑ping і tracepath повинні бути такими ж рутинними, як перевірка DNS.
2. Виправте ICMP‑політику навмисно: дозвольте PMTUD‑пов’язані ICMP (IPv4 frag‑needed, IPv6 packet‑too‑big). Перестаньте вважати «ping працює» доказом чогось.
3. Зробіть інвентар тунелів і оверлеїв: перераховуйте де додається оверхед і встановлюйте явні MTU там. Дефолти — не стратегія.
4. Тримайте MSS‑clamp під рукою: ставте його як вогнегасник — протестований, на місці і за потреби використовуваний.
5. Документуйте MTU‑домени: особливо якщо ви використовуєте jumbo frames. Зробіть межі змішаних MTU явними і маршрутизованими, а не випадковими.

Якщо у вашій організації при словах «деякі сайти не завантажуються» всі починають сперечатись про браузери, вам не потрібні кращі браузери. Вам потрібно краще ставлення до MTU.