Налаштування MTU для VPN: чому великі файли зависають, коли веб працює (і як вибрати правильний MTU)

Ментальна модель: чому «веб працює» але великі файли — ні

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

VPN додають заголовки. Іноді багато заголовків.
Ваш «внутрішній» пакет (той, який додаток вважає, що відправляє) упаковується в «зовнішній» пакет (той, що несе Інтернет).
Якщо зовнішній шлях не може витримати такий розмір, пакет треба фрагментувати або відправник має зменшити розмір пакета.

Ось звідки береться ілюзія «веб працює»:

• Інтерактивні речі дуже малі. Натискання клавіш у SSH та запити API зазвичай вміщуються в кілька сотень байтів. Навіть якщо MTU неправильно налаштований, багато таких пакетів проходить.
• Веб-трафік стійкий. Браузери повторюють запити. CDN толерують втрати. Деякі сайти використовують менші початкові congestion windows. І багато шляхів мовчки занижують TCP MSS або випадково мають достатній запас.
• Великі передачі постійно б’ють у стелю MTU. SCP, rsync, SMB, NFS поверх TCP — вони намагаються заповнити канал. Це означає багато повно-розмірних TCP сегментів. Якщо ці сегменти «зникають», пропускна здатність руйнується.
• PMTUD крихкий у корпоративних мережах. Воно покладається на ICMP‑повідомлення «Fragmentation Needed», які повертаються від маршрутизатора до відправника. Фаєрволи люблять відкидати ICMP, бо воно «виглядає небезпечним».

Коли PMTUD не працює, ви отримуєте класичну «MTU чорну діру»: великі пакети зникають, ніхто не інформує відправника, TCP повторює той самий приречений сегмент, і передача «зависає».

Жарт №1: проблеми з MTU схожі на офісні крісла — ніхто про них не думає, поки спина не дасть збій посеред кварталу.

Цікаві факти та історичний контекст (видання MTU)

1. 1500 байт не були законом фізики. Це проектне рішення з раннього Ethernet — компроміс між ефективністю, поведінкою домену колізій і апаратними обмеженнями.
2. IP‑фрагментація існує, бо Інтернет зшивали з різних мереж. Ранні IP-поширення мусили переходити через посилання з різними максимальними розмірами кадрів, тож фрагментація була хаком сумісності.
3. IPv6 змінив правила: маршрутизатори не фрагментують. В IPv6 фрагментацію виконує тільки відправник, що робить PMTUD ще критичнішим.
4. PPPoE з MTU 1492 — класична підводна міна. Вісім байтів PPPoE‑накладних означають, що 1500 вже не поміщається, а VPN зверху робить ситуацію ще гіршою.
5. «Jumbo frames» поширені всередині дата-центрів. MTU 9000 підвищує ефективність, але змішування MTU між оверлеями (VXLAN/Geneve) створює ті самі проблеми, що і MTU для VPN.
6. PMTUD відомий як ненадійний ще з 1990-х. Проблема «чорної діри» стара: фільтрація ICMP руйнує зворотний канал.
7. TCP MSS clamping став популярним, бо люди здалися щодо PMTUD. Це не елегантно, зате прагматично, коли ви не контролюєте кожен фаєрвол на шляху.
8. IPsec може додавати більше накладних витрат, ніж очікують. У залежності від режиму (tunnel vs transport), NAT‑Traversal і алгоритмів, накладні витрати різко змінюються — і ваш безпечний MTU теж.

Як виглядає біль через MTU у реальності

Проблеми MTU рідко проявляються як «packet too big». Вони виглядають як дивні симптоми: вибіркова відмова, непослідовна поведінка додатків і продуктивність, що нагадує поганий день в провайдера.
Симптоми, які повинні змусити вас спочатку підозрювати MTU:

• SCP/rsync/SMB передачі зависають після певного обсягу даних, часто на повторюваному офсеті.
• HTTPS працює, але завантаження великого артефакта таймаутиться.
• SSH працює, але git clone через VPN повільний або зависає.
• Деякі сайти працюють, деякі ні, особливо ті, що відправляють великі куки/заголовки або використовують великі TLS‑записи.
• VPN працює з однієї мережі, але не з іншої (домашній фібер vs кафе vs корпоративний гість Wi‑Fi).
• Речі ламаються лише при ввімкненому «full tunnel» або при маршрутизації додаткових підмереж.

Під цими симптомами зазвичай ховається одна з механічних причин:
надмірні пакети + DF встановлено (dont fragment) + зламаний PMTUD = чорна діра.
Або фрагментація відбувається, але погано (втрачуються фрагменти, проблеми зі збиранням, завантаження CPU, проблеми зі stateful фаєрволом).

PMTUD та ICMP‑повідомлення, які всі блокують

Path MTU Discovery має бути простим: відправляєте пакет з DF встановленим, і якщо маршрутизатор не може його переслати, він відповідає ICMP‑повідомленням з вказівкою наступного MTU.
Відправник зменшує розмір і пробує знову. Усі щасливі.

Насправді PMTUD — це переговори між двома хостами через ланцюг пристроїв, які можуть:
блокувати ICMP, переписувати заголовки, інкапсулювати пакети або «допоміжно» нормалізувати трафік.
Якщо ICMP «Fragmentation Needed» (IPv4) або «Packet Too Big» (IPv6) фільтруються, відправник продовжує шмагати занадто великі пакети й не отримує зворотного зв’язку.

Ось і вся історія чорної діри. Єдине правило безвідмовної вади: одне правило безпеки написане в 2014‑му («відкинути весь ICMP») може вбити сучасний VPN у 2025‑му.

Ось моя думка: не вирішуйте проблеми PMTUD, сподіваючись, що PMTUD почне працювати.
У корпоративній реальності слід припускати, що якийсь middlebox відкине ICMP у найгіршому місці.
Ваше завдання — вибрати безпечний MTU або обмежити MSS, щоб TCP ніколи не відправляв пакети, які потребують PMTUD.

Накладні витрати VPN‑інкапсуляції: байти, яких ви не бачите

Інкапсуляція не безкоштовна. Кожен VPN‑протокол додає заголовки (а іноді й паддінг), що займають місце в межах зовнішнього MTU.
Якщо фізичний MTU інтерфейсу 1500, а ваш VPN додає 80 байт накладних витрат, внутрішній пакет більше не може бути 1500.

Накладні витрати варіюються. Вони залежать від протоколу, режиму, використання NAT‑Traversal і від того, чи ви на IPv4 чи IPv6 у зовнішньому транспорті.
Ось приблизні числа, з якими можна працювати (не обіцянки, а орієнтовні оцінки):

• WireGuard над IPv4/UDP: часто ~60 байт накладних; реальний безпечний MTU зазвичай ~1420.
• WireGuard над IPv6/UDP: трохи більше накладних; безпечний MTU може бути нижчим.
• IPsec ESP в режимі тунелю: зазвичай 50–80+ байт; NAT‑T додає ще (UDP‑інкапсуляція).
• OpenVPN над UDP: накладні залежать від шифру та налаштувань; 1500 → зазвичай 1400–1472 залежно від тюнінгу.
• GRE/VXLAN оверлеї: додають свої накладні; у стеку з VPN швидко втрачаєте 100+ байт.

Правильний підхід: у вас є зовнішній path MTU, і ви маєте вибрати внутрішній MTU так, щоб він завжди поміщався після додавання накладних витрат.
Якщо ви не знаєте path MTU — вимірюйте. Якщо не можете надійно виміряти — обирайте консервативно і застосовуйте clamping.

Жарт №2: накладні витрати інкапсуляції схожі на наради — ніхто їх не закладає в бюджет, а вони чудово з’їдають весь робочий час.

Як обрати «правильний» MTU для VPN

Магічного MTU не існує. Є безпечний MTU для вашого зовнішнього шляху і вашого стеку інкапсуляції.
Вибір — інженерне завдання: виміряти шлях, відняти накладні витрати й перевірити реальним трафіком.

Крок 1: визначте найменший зовнішній MTU, з яким ви стикнетеся

Якщо ви контролюєте андерлей (приватний WAN), можливо, знаєте, що там 1500 або 9000 скрізь.
Якщо ваш VPN їде по публічному Інтернету, припускайте, що ви ним не керуєте.
Споживчі провайдери, PPPoE, LTE і готельний Wi‑Fi можуть знижувати MTU і те, що змінюється залежно від локації.

Прагматична ціль для VPN в Інтернеті часто така:
MTU 1420 для WireGuard, або
MTU 1400 як консервативна «працює в більшості місць» базова установка, коли мережі змішані й є невідомі middlebox‑и.

Крок 2: вирішіть, чи покладатиметесь на PMTUD, чи обмежите MSS

Якщо ви можете гарантувати пропуск ICMP end-to-end і маєте видимість фаєрволів, PMTUD може працювати.
Більшість організацій не можуть цього гарантувати через мережі партнерів, віддалених працівників і випадковий гостьовий Wi‑Fi.

Моя базова рекомендація:
встановіть безпечний MTU тунелю та одночасно обмежуйте TCP MSS на краю VPN для defense‑in‑depth.
Це нудно. Це працює. Це той нудний підхід, що тримає ваш інцидент‑канал у тиші.

Крок 3: валідуйте через тести «do not fragment» і реальні передачі

Ping‑тест з DF встановленим — не вся історія, але швидкий спосіб знайти межу відмови.
Потім перевірте справжньою bulk‑передачею (iperf3, scp великого файлу або rsync), бо деякі шляхи ставляться до ICMP і UDP/TCP по-різному.

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

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

Перший: підтвердьте, що симптом залежить від розміру

• Малі HTTP‑запити працюють; великі завантаження падають.
• SSH підключається; scp багатогігабайтового файлу зависає.
• Ping працює з маленьким payload; падає з більшим payload + DF.

Другий: знайдіть ефективний MTU на тунелі та його андерлеї

• Перевірте MTU інтерфейсу тунелю.
• Перевірте MTU фізичного egress‑інтерфейсу.
• Шукайте PPPoE (1492), дивності LTE або обмеження хмарної мережі.

Третій: виявіть збій PMTUD і вирішіть clamp vs allow ICMP

• Запустіть DF‑ping, щоб бінарно знайти максимальний розмір.
• Захопіть трафік, щоб бачити повтори і відсутні ICMP.
• Якщо ICMP блокується в місці, яким ви не керуєте: обмежте MSS і знизьте MTU.

Четвертий: валідуйте виправлення реальною bulk‑передачею

• Використайте iperf3 або scp/rsync багатогігабайтового файлу.
• Слідкуйте за повторними передачами, out‑of‑order і стабільністю пропускної здатності.
• Підтвердіть, що ви не зламали щось інше (наприклад оверлей‑мережу).

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

Мета усунення MTU — припинити гадання.
Нижче наведені конкретні завдання, які можна виконати на Linux‑хостах та типових VPN‑шлюзах.
Кожне завдання включає: команду, приклад виводу, що це означає і яке рішення приймати далі.

Завдання 1: Перевірте MTU на всіх інтерфейсах (знайдіть тунель і реальний egress)

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> mtu 65536
eth0             UP             0a:1b:2c:3d:4e:5f <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
wg0              UP             8a:9b:aa:bb:cc:dd <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420

Що це означає: Тунель (wg0) встановлений на 1420, андерлей eth0 — 1500. Це розумна відправна точка для WireGuard.

Рішення: Якщо тунельний MTU встановлено 1500 при андерлеї 1500, ви майже напевно перевищили розмір після накладних витрат. Плануйте знизити MTU тунелю або обмежити MSS.

Завдання 2: Перевірте маршрут і визначте, який інтерфейс реально несе VPN‑трафік

cr0x@server:~$ ip route get 1.1.1.1
1.1.1.1 via 203.0.113.1 dev eth0 src 203.0.113.10 uid 1000
    cache

Що це означає: Ваш інтернет‑егрес — eth0. Це андерлей для VPN, якщо пірінги VPN знаходяться в Інтернеті.

Рішення: Якщо egress‑інтерфейс — PPPoE (часто ppp0) або VLAN з меншим MTU, використовуйте це значення як верхню межу для зовнішнього розміру пакета.

Завдання 3: Перевірте наявність PPPoE або інших лінків зі зниженим MTU

cr0x@server:~$ ip -d link show dev ppp0
6: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 3
    link/ppp

Що це означає: Зовнішній MTU — 1492, а не 1500. Якщо ви припускали 1500, ваш внутрішній MTU тунелю має бути ще меншим.

Рішення: Знизьте MTU тунелю і/або обмежте MSS відповідно. Не «оптимізуйте» це, якщо ви не контролюєте метод доступу.

Завдання 4: Швидкий DF‑ping для виявлення фрагментації/чорної діри (IPv4)

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

--- 198.51.100.20 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2053ms

Що це означає: Ваша локальна система вже знає про обмеження MTU (1420) на шляху/інтерфейсі. Пакет 1500 не поміститься.

Рішення: Не надсилайте TCP‑сегменти, що потребують 1500‑байтних пакетів по цьому шляху. Встановіть MTU тунелю відповідно до реальності або обмежте MSS.

Завдання 5: Бінарний пошук максимального DF‑payload, що працює

cr0x@server:~$ ping -M do -s 1392 -c 2 198.51.100.20
PING 198.51.100.20 (198.51.100.20) 1392(1420) bytes of data.
1400 bytes from 198.51.100.20: icmp_seq=1 ttl=57 time=28.1 ms
1400 bytes from 198.51.100.20: icmp_seq=2 ttl=57 time=27.8 ms

--- 198.51.100.20 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 27.825/27.948/28.071/0.123 ms

Що це означає: 1420 загальний IP‑пакетний розмір працює (1392 payload + 28 байт ICMP+IP заголовок). Це вказує на безпечний path MTU близько 1420 для цього потоку.

Рішення: Оберіть MTU тунелю на або нижче цієї межі (з урахуванням накладних витрат VPN). Для WireGuard 1420 часто правильний; для важчих інкапсуляцій — знижуйте ще більше.

Завдання 6: Виявлення блокування PMTUD (класичний патерн чорної діри)

cr0x@server:~$ ping -M do -s 1412 -c 2 198.51.100.20
PING 198.51.100.20 (198.51.100.20) 1412(1440) bytes of data.

--- 198.51.100.20 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 2038ms

Що це означає: Нема відповіді, і ви також не отримали корисного ICMP «frag needed». Це може бути проста втрата, але якщо менші розміри працюють стабільно, ситуація підозріла.

Рішення: Допоки не доведено інше — припускайте MTU‑чорну діру. Віддавайте перевагу MSS‑clamping і консервативному MTU тунелю. Також перевірте правила фаєрволу на ICMP тип 3 код 4 (IPv4) та ICMPv6 тип 2.

Завдання 7: Перевірте TCP MSS і поведінку шляху за допомогою ss

cr0x@server:~$ ss -ti dst 198.51.100.20
ESTAB 0 0 10.0.0.5:48216 198.51.100.20:443
	 cubic wscale:7,7 rto:204 rtt:32.4/4.1 ato:40 mss:1360 pmtu:1420 rcvmss:1360 advmss:1360 cwnd:10 bytes_sent:128734 bytes_acked:128734

Що це означає: З’єднання використовує MSS 1360 і PMTU 1420. Це узгоджено: 1420 мінус 40 байт TCP+IP заголовків ≈ 1380 (опції трохи зменшують це число).

Рішення: Якщо ви бачите MSS близько 1460, а MTU тунелю нижчий — ймовірно, є невідповідність, і слід обмежити або виправити MTU.

Завдання 8: Перевірте налаштований MTU WireGuard і шлях до піра

cr0x@server:~$ wg show
interface: wg0
  public key: 8n3r...redacted...
  listening port: 51820

peer: pQ1k...redacted...
  endpoint: 198.51.100.20:51820
  allowed ips: 10.42.0.0/16
  latest handshake: 1 minute, 12 seconds ago
  transfer: 1.23 GiB received, 2.98 GiB sent

Що це означає: Тунель живий і передає дані. Проблеми MTU не обов’язково зупиняють handshakes; вони карають bulk‑передачі й певні розміри пакета.

Рішення: Якщо handshakes в нормі, а пропускна здатність погана — зосередьтесь на MTU/MSS/PMTUD, а не на ключах чи маршрутизації.

Завдання 9: Перевірте і встановіть MTU інтерфейсу (тимчасова зміна для тесту)

cr0x@server:~$ sudo ip link set dev wg0 mtu 1380
cr0x@server:~$ ip link show dev wg0
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1380 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Що це означає: Ви примусово зменшили MTU на тунелі. Це зменшує ризик фрагментації, але підвищує накладні витрати на пакет.

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

Завдання 10: Обмежити TCP MSS на Linux‑шлюзі за допомогою iptables

cr0x@server:~$ sudo iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
cr0x@server:~$ sudo iptables -t mangle -S FORWARD
-P FORWARD ACCEPT
-A FORWARD -o wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Що це означає: Для TCP SYN‑пакетів, що виходять через wg0, MSS буде підлаштований під виявлений PMTU (або MTU інтерфейсу).

Рішення: Використовуйте це, коли ви не можете довіряти PMTUD end‑to‑end або коли клієнти мають різні MTU. Потім перевірте ss -ti, щоб переконатися, що MSS знизився.

Завдання 11: Те ж саме з nftables (поширено у сучасних дистрибутивах)

cr0x@server:~$ sudo nft add table inet mangle
cr0x@server:~$ sudo nft 'add chain inet mangle forward { type filter hook forward priority -150; }'
cr0x@server:~$ sudo nft add rule inet mangle forward oifname "wg0" tcp flags syn tcp option maxseg size set rt mtu
cr0x@server:~$ sudo nft list ruleset
table inet mangle {
	chain forward {
		type filter hook forward priority -150; policy accept;
		oifname "wg0" tcp flags syn tcp option maxseg size set rt mtu
	}
}

Що це означає: MSS встановлюється на основі MTU маршруту. Це nftables‑еквівалент «clamp to PMTU».

Рішення: Віддавайте перевагу nftables, якщо ваш флот його використовує. Зробіть правило персистентним через механізм вашого дистрибутиву (тут не показано) і тестуйте після перезавантаження.

Завдання 12: Переконайтесь, що ICMP «fragmentation needed» не відкидається локально

cr0x@server:~$ sudo iptables -S INPUT
-P INPUT DROP
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j DROP

Що це означає: Ви відкидаєте весь ICMP на хості. Це може ламати PMTUD (навіть якщо RELATED правила могли б допомогти в деяких випадках).

Рішення: Дозвольте потрібні типи ICMP або обмежте MSS, щоб не покладатися на ICMP. Якщо ви на IPv6, «відкинути весь ICMPv6» — надійний спосіб креативно зламати мережу.

Завдання 13: Захопіть докази чорної діри (повторні передачі, немає ICMP у відповідь)

cr0x@server:~$ sudo tcpdump -ni wg0 'tcp port 443 or icmp' -vv
tcpdump: listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:15:01.102334 IP 10.42.0.10.48216 > 10.42.0.20.443: Flags [P.], seq 1:1361, ack 1, win 501, length 1360
12:15:01.304982 IP 10.42.0.10.48216 > 10.42.0.20.443: Flags [P.], seq 1:1361, ack 1, win 501, length 1360
12:15:01.708115 IP 10.42.0.10.48216 > 10.42.0.20.443: Flags [P.], seq 1:1361, ack 1, win 501, length 1360

Що це означає: Повторні відправлення одного й того ж сегмента без прогресу. Якщо ви ніколи не бачите ICMP «too big» і менші MSS працюють, то це PMTUD/MTU‑проблема.

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

Завдання 14: Виміряйте пропускну здатність і стабільність за допомогою iperf3 (TCP)

cr0x@server:~$ iperf3 -c 10.42.0.20 -t 15
Connecting to host 10.42.0.20, port 5201
[  5] local 10.42.0.10 port 46012 connected to 10.42.0.20 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  6.50 MBytes  54.5 Mbits/sec   12   34.0 KBytes
[  5]   1.00-2.00   sec  2.00 MBytes  16.8 Mbits/sec   31   19.8 KBytes
[  5]   2.00-3.00   sec  1.25 MBytes  10.5 Mbits/sec   45   14.1 KBytes
[  5]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec   60   10.0 KBytes

Що це означає: Зростання повторних передач і падіння пропускної до нуля відповідає чорним‑дорам сегментів або сильним втратам. MTU‑проблеми часто виглядають саме так, коли досягається «поганий розмір».

Рішення: Знизьте MTU / обмежте MSS і запустіть знову. Хороший результат — стабільний bitrate з низькою кількістю повторів.

Завдання 15: Зверніть увагу на локальні offload‑фічі, що плутають захоплення (звичайно не корінь проблеми)

cr0x@server:~$ sudo ethtool -k eth0 | egrep 'tso|gso|gro'
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

Що це означає: Offload‑и можуть зробити захоплення пакетів дивним (великі «супер‑пакети» на боці хоста). Зазвичай вони не викликають MTU‑чорних дір, але можуть змусити помилково інтерпретувати дані.

Рішення: Якщо ви глибоко аналізуєте пакети, тимчасово вимкніть offload‑и для ясності (не як «фікс»), потім увімкніть назад, щоб уникнути регресії продуктивності.

Завдання 16: Перевірте MTU на віддаленому клієнті (бо ваш шлюз не єдиний, хто бреше)

cr0x@server:~$ ssh user@client 'ip -br link show dev wg0'
wg0              UP             3a:44:55:66:77:88 <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500

Що це означає: Клієнт wg0 має MTU 1500. Цей клієнт може відправляти внутрішні пакети, що не помістяться після інкапсуляції, в залежності від шляху.

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

Три корпоративні міні‑історії (бо продакшен — хороший вчитель)

1) Інцидент через неправильне припущення

Середня компанія розгорнула новий site‑to‑site VPN між хмарним VPC і офісом на місці.
Тести підключення виглядали чистими: ping працював, DNS працював, люди могли SSH до bastion. Усіх визнали успіх.
Два дні потому CI почав падати при завантаженні артефактів до внутрішнього реєстру, доступного тільки через той VPN.

Логи збірки показували таймаути і повтори. Розробники звинувачували реєстр. Команда реєстру звинувачувала CI‑раннери. SRE підключилися, бо інцидент набував ту «термінову, але ніхто не знає чому» енергію.
Хтось помітив закономірність: малі образи пушились нормально. Великі шари зависали назавжди.

Неправильне припущення було простим і поширеним: «Мережа — це Ethernet, тож MTU 1500 скрізь».
On‑prem uplink використовував PPPoE. Зовнішній MTU був 1492. VPN додав накладні зверху. PMTUD був зламаний через стару політику фаєрвола, що відкидав ICMP тип 3 код 4.
Тож великі TCP‑сегменти зникали в порожнечу, і TCP робив те, що TCP вміє: повторював, відступав і тихо страждав.

Виправлення не було героїчним. Вони знизили MTU тунелю до безпечного значення і ввели MSS‑clamping на шлюзі.
Завантаження стало нудно стабільним. Інцидент завершився.
Постмортемна дія була чіткою: не використовувати «ping працює» як проксі для «bulk‑трафік працює», і не скидати весь ICMP за замовчуванням.

2) Оптимізація, що відкинула назад

Інша організація мала віддалених працівників і VPN‑клієнт за замовчуванням з MTU 1420.
Мережевий інженер, намагаючись дістати більше швидкості для великих передач, впровадив політику встановити MTU 1500 «щоб відповідало Ethernet».
Також він вимкнув MSS‑clamping, бо «це не повинно бути необхідним».

Тиждень в офісі все виглядало як виграш: швидші передачі до певних внутрішніх сервісів через охайний ISP‑лінк.
Потім черга helpdesk вибухнула: віддалені користувачі мали проблеми — відеодзвінки були ок, але завантаження звітів до внутрішнього порталу падало, а деякі веб‑додатки завантажувалися без CSS.
Відмови були непостійними в залежності від ISP і локації — саме так проявляються MTU‑проблеми коли андерлей змінний.

Відкат до 1420 виправив більшість користувачів миттєво. Вони відновили MSS‑clamping на краю VPN, потім провели контрольований експеримент, щоб подивитися, чи може якась підгрупа безпечно використовувати більший MTU.
Висновок був передбачувано сумним: глобально більший MTU не вартий витрат на підтримку. Вони лишили 1420 і зосередились на покращенні маршрутизації та плануванні ємності.

3) Нудна, але правильна практика, що врятувала день

Команда фінансових послуг використовувала кілька типів VPN: WireGuard для інженерів, IPsec‑тунелі для партнерів і оверлей‑мережу в Kubernetes.
У них було правило: кожен новий тунель має приходити з MTU‑тестом і політикою MSS, плюс односторінковий ранубук з процедурою «DF ping binary search».
Нікому не подобалося це правило. Але всі його виконували, бо воно берегло вихідні дні.

Одної п’ятниці партнер змінив фаєрвол і почав блокувати більше ICMP.
IPsec‑тунель залишився «up», але великі повідомлення до API розрахунків почали перериватися спорадично. Тригери спрацювали, але команда не панікувала — у неї був плейбук і відома базова конфігурація.

Вони прогнали стандартні перевірки: DF‑ping тести, tcpdump на повтори і перевірку MSS‑clamp на краю.
Результат: clamp вже запобігав надто великим TCP‑сегментам, тож вплив обмежився підмножиною не‑TCP трафіку і специфічною службою, що посилала більші UDP‑payload.
Оскільки тунель MTU був консервативним, зона ураження була значно меншою.

Вони підкоригували розмір payload для того UDP‑шляху і погодилися з партнером дозволити потрібні типи ICMP.
Та «нудна» практика — стандартні MTU, MSS‑clamp і відтворювані тести — перетворила потенційний багатокомандний outage в обмежений операційний тікет.

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

1) Симптом: SCP зависає; інтерактивний SSH ок

Корінь проблеми: TCP‑сегменти, розраховані на MTU 1500, чорніються після інкапсуляції VPN; PMTUD/ICMP зворотний канал заблоковано.

Виправлення: Знизьте MTU тунелю (наприклад, 1420→1380 при потребі) і обмежте MSS на краю VPN. Перевірте за допомогою ss -ti і реальною передачею.

2) Симптом: Деякі сайти завантажуються, інші підвисають або втрачають ресурси (CSS/зображення)

Корінь проблеми: Змішані розміри пакетів у TLS/HTTP; більші відповіді тригерять проблеми фрагментації. Часто буває при full‑tunnel VPN і MTU‑невідповідності.

Виправлення: Обмежте MSS на вихідному TCP від клієнта або VPN‑шлюзу. Якщо ви керуєте клієнтами — стандартизуйте MTU тунелю.

3) Симптом: VPN «підключається», але пропускна здатність жахлива і багато повторів

Корінь проблеми: Фрагментація або чорна втрата на певній межі розміру; іноді загострюється стеком оверлея на оверлеї (VXLAN поверх VPN тощо).

Виправлення: Виміряйте максимальний DF‑розмір, зменшіть MTU і уникайте насладання інкапсуляцій без бюджету MTU. Якщо насладання необхідне — закладіть MTU‑математику в дизайн.

4) Симптом: Працює з офісної мережі, не працює з дому або LTE

Корінь проблеми: Андерлей MTU відрізняється (PPPoE/LTE), і ваш MTU тунелю занадто високий для деяких шляхів. PMTUD може не працювати через споживчі пристрої.

Виправлення: Використовуйте консервативний MTU для remote‑access VPN і обмежуйте MSS. Припиніть вважати офіс «Інтернетом».

5) Симптом: IPv6‑трафік через VPN крихкий; IPv4 ок

Корінь проблеми: ICMPv6 фільтрований (особливо «Packet Too Big»), що ламає IPv6 PMTUD. Також заголовки IPv6 більші, зменшуючи ефективний payload.

Виправлення: Дозвольте потрібні ICMPv6 типи або агресивніше знижуйте MTU для IPv6. Не відкидайте ICMPv6 усією сіткою.

6) Симптом: Kubernetes‑поди можуть дістатися сервісів, але великі відповіді падають

Корінь проблеми: CNI MTU не відповідає MTU вузла/тунелю; оверлей додає накладні; MTU пода занадто великий; PMTUD блокується всередині оверлеїв.

Виправлення: Встановіть CNI MTU явно, щоб він вкладався в андерлей і будь‑який VPN. Потім обмежте MSS на egress вузла, якщо потрібно.

7) Симптом: UDP‑додатки ламаються (VoIP ок, але великі UDP payload падають)

Корінь проблеми: UDP не має MSS‑переговору як TCP; надмірні датаграми фрагментуються і фрагменти втрачаються/відкидаються; або DF‑поведінка інша.

Виправлення: Зменшіть розмір payload у додатку; уникайте великих UDP‑датаграм через VPN; забезпечте, щоб фрагментація не була потрібною або оброблялась надійно.

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

Чеклист A: Коли ви на виклику і потрібен фікс менше ніж за годину

1. Підтвердьте залежність від розміру. Спробуйте великий scp/rsync/iperf3; порівняйте з малим HTTP‑запитом.
2. Перечитайте поточні MTU‑значення. ip -br link на обох кінцях; ідентифікуйте тунель і egress.
3. Запустіть DF‑ping тести. Бінарний пошук payload‑ів, щоб знайти межу.
4. Тимчасово знизьте MTU тунелю. Тестуйте 1420 → 1380 → 1360 за потреби.
5. Обмежте MSS на краю VPN. Використайте iptables/nftables для clamp‑у на PMTU.
6. Перетестуйте bulk‑передачу. iperf3 + scp багатогігабайтового файлу; впевніться, що повтори впали.
7. Зробіть зміни персистентними. Оновіть конфіг VPN і правила фаєрволу в CM; додайте регресійний тест у ранубук.

Чеклист B: Коли проектуєте VPN і хочете уникнути інциденту взагалі

1. Проінвентаризуйте шари інкапсуляції. VPN + оверлей + VLAN + PPPoE — це не стиль, це MTU‑бюджет.
2. Оберіть консервативний базовий MTU. Для Інтернет‑доступу починайте з ~1420 (WireGuard) або 1400, якщо шляхи змішані.
3. Стандартизуйте MTU на клієнтах. Не дозволяйте кінцевим пристроям гадати; видайте конфіг.
4. Обмежуйте MSS на межах. Особливо там, де трафік переходить з «всередину» в «тунель».
5. Дозвольте необхідний ICMP. Дозвольте fragmentation‑needed / packet‑too‑big. Не відкидайте весь ICMP через страшний сканер.
6. Тестуйте з «ворожих» мереж. LTE, готельний Wi‑Fi, домашній PPPoE та дещо, чим користується ваш фінансовий відділ у дорозі.
7. Напишіть ранубук. Включіть точні команди, очікувані виводи та процедури відкату.

Чеклист C: Чого уникати (бо ви про це пошкодуєте)

• Встановлення MTU тунелю на 1500 «бо Ethernet».
• Відкидання всього ICMP/ICMPv6 без розуміння PMTUD.
• Припущення, що один успішний ping означає правильний MTU.
• Насладання тунелів/оверлеїв без розрахунку запасу headroom.
• Розгортання змін MTU по флоту без канарної мережі, що включає споживчі ISP.

Поширені питання

1) Чому малі пакети працюють, а великі зависають?

Тому що малі пакети поміщаються в ефективний MTU навіть після накладних витрат VPN. Великі пакети перевищують його, їх відкидають або фрагментують, а PMTUD може бути заблокований.
TCP тоді повторює й відступає, що виглядає як «зависання».

2) Який хороший дефолтний MTU для WireGuard?

1420 — поширений і практичний дефолт на Ethernet‑андерлеї з MTU 1500. Якщо ви бачите симптоми чорної діри в деяких мережах, спробуйте 1380 або 1360.
Потім валідуйте через DF‑ping і реальні передачі.

3) Чи варто покладатися на PMTUD замість MSS‑clamping?

Якщо ви контролюєте увесь шлях і дозволяєте потрібні ICMP‑повідомлення, PMTUD може працювати.
У змішаній корпоративній/споживчій реальності MSS‑clamping зазвичай безпечніший оперативний вибір — особливо для remote‑access VPN.

4) Хіба зниження MTU не зменшує продуктивність?

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

5) А як щодо jumbo frames (9000 MTU)? Чи можу я використовувати більший MTU тунелю?

Тільки якщо весь андерлей підтримує це end‑to‑end і кожен шар інкапсуляції врахований.
Змішані MTU дуже поширені, і один хоп з MTU 1500 зіпсує вам день. Вимірюйте; не припускайте.

6) Якщо я обмежу MSS, чи все ще треба налаштовувати MTU тунелю?

Обмеження MSS захищає TCP‑потоки. Воно нічого не робить для UDP або не‑TCP протоколів.
Здоровий MTU тунелю зменшує ризик фрагментації для всього трафіку, тож зазвичай бажано мати обидва: безпечний MTU тунелю + MSS‑clamp.

7) Чому IPv6 більш чутливий до цього?

Маршрутизатори не фрагментують IPv6 пакети. Відправник має адаптуватись на основі ICMPv6 «Packet Too Big».
Якщо ICMPv6 фільтрується, PMTUD сильно ламається, і чорні діри виникають частіше, ніж з IPv4.

8) Яка різниця між MTU і MSS?

MTU — це максимальний IP‑пакетний розмір на лінку. MSS — це максимальний TCP‑payload у сегменті.
MSS зазвичай рівний MTU мінус IP+TCP заголовки (і мінус опції). Обмеження MSS запобігає формуванню TCP‑пакетів, що перевищують path MTU.

9) Чи можна «вирішити» це, дозволивши фрагментацію?

Можна, але це компроміс: фрагментація підвищує чутливість до втрат (втрата одного фрагмента — втрата всього пакета), ускладнює роботу middlebox‑ів і може підсилити проблеми з продуктивністю.
Краще уникати фрагментації, обравши відповідний MTU і обмеживши MSS.

10) Яке гарне операційне правило для ICMP у фаєрволах?

Дозвольте ICMP‑повідомлення, потрібні для PMTUD (IPv4 fragmentation‑needed, IPv6 packet‑too‑big) і базові помилки.
Не відкидайте ICMP загалом. Така політика породжує тікети «VPN начебто привидом».

Цитата, яку варто тримати на стіні

Парафраз ідеї Вернера Фогельса: «Усе ламається, весь час — проектуйте з урахуванням цього». У нашому випадку: припускайте, що PMTUD десь відмовить, і побудуйте запобіжні заходи (MTU/MSS) заздалегідь.

Висновок: практичні наступні кроки

Якщо великі файли зависають через VPN, а базовий веб‑серфінг працює — припиніть гонитву за привидами в прикладному шарі.
MTU і PMTUD зазвичай винні, і виправлення зазвичай поєднує консервативний MTU тунелю і обмеження MSS.

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

1. Запустіть DF‑ping тести, щоб знайти реальну межу розміру.
2. Уніфікуйте MTU тунелю на кінцях (не дозволяйте клієнтам фрістайлити).
3. Обмежте TCP MSS на межі VPN, щоб не покладатися на PMTUD.
4. Аудитуйте правила фаєрволу: дозвольте необхідні ICMP/ICMPv6‑повідомлення.
5. Перевірте реальну bulk‑передачу і збережіть команди в ранубуці.

Коли MTU правильний, VPN стає нудним. Це мета. Нудні мережі передають дані і тримають вас поза зайвими нарадами.