Проблеми MTU/MSS у офісних VPN: чому великі файли зависають (SMB/RDP) і як це виправити

Режим відмови: чому «великі файли» виявляють баги MTU/MSS

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

Ось що зазвичай відбувається:

• Ваші кінцеві пристрої вірять, що можуть відправляти пакети до певного розміру (зазвичай 1500 байт на Ethernet).
• VPN додає накладні витрати (инкапсуляція, шифрування, автентифікація). Тепер ефективний MTU корисного навантаження всередині тунелю менший за 1500.
• Деякий пристрій на шляху не може переслати ті більші пакети й намагається повідомити про це через ICMP «Fragmentation needed» (або еквівалент в IPv6).
• Це ICMP-повідомлення блокується або ніколи не доходить назад (привіт, «жорстке посилення безпеки»).
• TCP продовжує повторно передавати сегменти, які ніколи не проходять шлях. Малі потоки живуть, бо влазять; великі — завмирають, бо ні.

Це і є визначення PMTUD black hole: Path MTU Discovery намагається працювати, але канал зворотного зв’язку зламаний.

SMB і RDP не обов’язково падають миттєво. Вони падають найдратівливішим чином: працюють частково. Перші кілька мегабайт можуть передатись, потім ви натрапляєте на пакет, що має бути більший за те, що дозволяє шлях, і сеанс переходить з «добре» в «преслідуваний привидами».

Практичне правило: якщо малі пакети працюють, а великі зависають, перестаньте звинувачувати сховище, DNS або автентифікацію — почніть тестувати MTU.

Цікаві факти та історичний контекст

1. 1500 байт стали «за замовчуванням» здебільшого через Ethernet, а не тому, що 1500 оптимально — просто зручно й широко сумісно.
2. PPPoE відомо зменшує MTU до 1492 (8 байт накладних), тож «1492» часто з’являється в оповідях про налагодження VPN.
3. Накладні ESP в IPsec не мають одного фіксованого розміру; це залежить від режиму тунелю чи транспорту, NAT‑T, шифру, цілісності, паддінгу та вирівнювання.
4. PMTUD походить з кінця 1980-х — початку 1990-х, створена, щоб зменшити фрагментацію і підвищити ефективність — чудова ідея, але крихка при фільтрації ICMP.
5. «ICMP блокується заради безпеки» ламає мережі десятиліттями; це операційний еквівалент заклеювання індикаторів попередження в панелі приладів.
6. IPv6 намагається зробити фрагментацію розумнішою, перекладаючи відповідальність на кінцеві точки — але PMTUD black hole все ще трапляються, коли ICMPv6 неправильно обробляють.
7. MSS clamping став мейнстримом, бо PMTUD часто ламається в реальному світі; це прагматичне обхідне рішення, коли не можна довіряти шляху повідомляти MTU правильно.
8. Jumbo frames (9000 MTU) зробили невідповідності MTU частішими у змішаних середовищах: чудово в дата-центрі, хаотично, коли випадково просочується в WAN очікування.

MTU, MSS, PMTUD: що має значення в продакшені

MTU: найбільший пакет, який можна проштовхнути по лінії

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

Якщо ваш внутрішній пакет 1500 байт, а VPN додає 60–100+ байт накладних, зовнішній пакет може стати 1560–1600 байт. Якщо якийсь хоп на шляху дозволяє лише 1500, щось має поступитися.

MSS: найбільша TCP-корисна частина в сегменті

MSS (Maximum Segment Size) — це розмір TCP-корисного навантаження, без IP і TCP заголовків. Коли ви бачите MSS 1460, це 1500 MTU мінус 20 байт IPv4‑заголовок мінус 20 байт TCP‑заголовок.

Коли MTU зменшується (через VPN‑накладні), безпечний MSS теж знижується. Якщо ви не підлаштуєте MSS і PMTUD провалиться, TCP буде намагатися відправляти сегменти, що завелики для шляху, і з’являться затримки під навантаженням.

PMTUD: петля зворотного зв’язку, яку легко зламати

Path MTU Discovery покладається на маршрутизатори, що кажуть відправнику: «цей пакет занадто великий; візьми такий MTU». В IPv4 це ICMP «Fragmentation needed» (type 3, code 4). В IPv6 — ICMPv6 «Packet Too Big».

Заблокуйте ці повідомлення — і PMTUD перетворюється на «вгадай MTU шляху». Вгадайте неправильно — і TCP витрачатиме час на повторні передачі сегментів, які ніколи не доставляються.

Перефразована ідея від Werner Vogels (CTO Amazon): «Усе ламається; проектуйте так, щоб швидко відновлюватися». Проблеми MTU — ідеальний приклад: будуй під цю відмову, а не сподівайся, що шлях ввічливий.

Операційна істина в одній фразі: якщо не можете гарантувати, що PMTUD працює енд‑ту‑енд, клацніть MSS на краю тунелю.

Жарт #1 (коротко і по темі): баги MTU схожі на офісні принтери: вони застрягають тільки тоді, коли директору щось треба через п’ять хвилин.

Чому SMB і RDP перші скаржаться

SMB: балакучий, станoвий та надзвичайно добре виявляє втрати пакетів

SMB-копії файлів — це довготривалі TCP-потоці з піковими навантаженнями. Вони також виконують чимало контрольного «балакання», чутливого до затримки і повторних передач. Коли MTU неправий, великі сегменти даних застрягають, у той час як менші контрольні повідомлення можуть проходити. Це породжує божевільний симптом: шар відкривається, автентифікація працює, списки папок відображаються, але копіювання файлу зависає.

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

RDP: сеанс може залишатися живим, поки ваші великі передачі задихаються

RDP може виглядати підключеним, бо keepalive і невеликі оновлення екрану поміщаються. Перенаправлення буфера обміну, мапінг дисків, друк і копіювання файлів — ось де з’являються більші передачі і TCP-потік починає страждати. Користувачі описують це як «зависання RDP», але часто це шлях I/O, що перенаправлено, який застрягає, поки інші потокові нитки сеансу ще ледь сочаться.

Чому веб‑перегляд часто виглядає нормально

Сучасний веб‑трафік — це багато коротких підключень з конт­ролем переповнення, що швидко відновлюється, і багато контенту доставляється частинами, які не потребують тривалих великих сегментів. Також браузери агресивно повторюють запити й ховають невдачі за спінерами. SMB‑копії — чесні. Вони просто зупиняються і дивляться вам у вічі.

Швидкий план діагностики

Це порядок дій, що швидко приводить до істини, не витрачаючи півдня на переписування конфігів VPN лише тому, що «відчувається як MTU».

Перше: підтвердьте, що симптом пов’язаний з розміром, а не з іменуванням чи автентифікацією

• Чи можете ви надійно переглядати шар SMB, але копіювання великих файлів зависає?
• Чи RDP підключається миттєво, але копіювання файлів через перенаправлений диск замерзає?
• Чи малі ping‑и працюють, але великі ping‑и з DF встановленим падають?

Друге: визначте робочий path MTU за допомогою DF ping тесту

• Тестуйте з клієнта до сервера (і в зворотному напрямку, якщо можливо).
• Знайдіть найбільше корисне навантаження, яке проходить без фрагментації.
• Якщо ви бачите «Frag needed» — вам пощастило; якщо бачите тишу, можливо, у вас чорна діра.

Третє: перевірте припущення щодо накладних тунелю і клацніть MSS на краю

• Визначте, чи використовуєте ви IPsec (ESP, NAT‑T), OpenVPN (UDP/TCP), WireGuard або SSL VPN‑пристрої.
• Встановіть MTU інтерфейсу тунелю відповідно і/або затисніть TCP MSS на шлюзі/фаєрволі VPN.
• Перетестуйте копіювання великих файлів і довготривалі TCP‑потоки.

Четверте: перевірте обробку ICMP (не здогадуйтеся)

• Дозвольте потрібні типи ICMP через тунель і на WAN‑краях.
• Підтвердьте, що PMTUD працює, або прийміть, що ні — і спирайтеся на MSS clamping.

П’яте: лише потім беріться за «настройку продуктивності»

• SMB multichannel, масштабування вікна, offload‑и — це вторинні речі, коли MTU правильний.
• Не оптимізуйте зламаний шлях. Ви просто створите швидшу відмову.

Практичні завдання з командами: доведіть проблему, потім виправте

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

Завдання 1: Визначте інтерфейс VPN і його MTU (Linux)

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> mtu 65536
eth0             UP             52:54:00:12:34:56 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
wg0              UNKNOWN        9a:bc:de:f0:12:34 <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420

Що це означає: Інтерфейс тунелю (wg0) вже має MTU 1420 — поширений вибір для WireGuard. Якщо ви бачите 1500 на VPN‑інтерфейсі, це тривожний знак у більшості WAN‑сценаріїв.

Рішення: Якщо MTU на тунелі 1500, плануйте його знизити або застосувати MSS clamping.

Завдання 2: Перевірте підказки маршруту MTU (Linux)

cr0x@server:~$ ip route get 10.20.30.40
10.20.30.40 dev wg0 src 10.20.30.1 uid 1000
    cache

Що це означає: Трафік до віддаленого хоста йде через wg0. Якщо він несподівано використовує eth0, ваші правила split‑tunnel можуть бути неправильними, і ви налагоджуєте не той шлях.

Рішення: Підтвердьте, що ви дійсно тестуєте через VPN‑шлях.

Завдання 3: Знайдіть реальний path MTU за допомогою ping з DF (Linux, IPv4)

cr0x@server:~$ ping -M do -s 1472 -c 3 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1472(1500) bytes of data.

--- 10.20.30.40 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2042ms

Що це означає: Пакет 1500 байт (1472 payload + 28 байт заголовків) не пройшов. Якщо ви отримали явне «Frag needed», PMTUD принаймні частково функціонує. Тиша може означати чорну діру.

Рішення: Зменшуйте розмір payload, поки тест не вдасться; зафіксуйте найбільше робоче значення.

Завдання 4: Бінарний пошук MTU, поки не запрацює (Linux)

cr0x@server:~$ ping -M do -s 1364 -c 3 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1364(1392) bytes of data.
1372 bytes from 10.20.30.40: icmp_seq=1 ttl=63 time=31.2 ms
1372 bytes from 10.20.30.40: icmp_seq=2 ttl=63 time=30.9 ms
1372 bytes from 10.20.30.40: icmp_seq=3 ttl=63 time=31.0 ms

--- 10.20.30.40 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 30.9/31.0/31.2/0.1 ms

Що це означає: Ваш path MTU принаймні 1392 байти для IPv4‑пакетів. Це натякає на MSS близько 1352 (1392 − 40 байт IP+TCP заголовки), і слід клацнути нижче цього значення для безпеки.

Рішення: Встановіть MTU тунелю або MSS clamp у консервативне значення (зазвичай еквівалент inner MTU 1360–1380, залежно від накладних і змін).

Завдання 5: Спостерігайте MSS у SYN пакетах за допомогою tcpdump (Linux)

cr0x@server:~$ sudo tcpdump -ni wg0 'tcp[tcpflags] & (tcp-syn) != 0' -c 3
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:10:11.123456 IP 10.20.30.10.51123 > 10.20.30.40.445: Flags [S], seq 123456789, win 64240, options [mss 1460,sackOK,TS val 111 ecr 0,nop,wscale 7], length 0
12:10:12.234567 IP 10.20.30.10.51124 > 10.20.30.40.3389: Flags [S], seq 987654321, win 64240, options [mss 1460,sackOK,TS val 112 ecr 0,nop,wscale 7], length 0

Що це означає: MSS 1460 рекламовано через тунель, який, ймовірно, не може підтримувати 1500 внутрішнього MTU енд‑ту‑енд. Тут великі передачі йдуть в трубу.

Рішення: Впровадьте MSS clamping на виході/вході VPN (або виправте MTU тунелю, щоб кінцеві пристрої рекламували правильний MSS).

Завдання 6: Зажим MSS з iptables (Linux gateway)

cr0x@server:~$ sudo iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360

Що це означає: Нові TCP‑з’єднання, що форвардяться через wg0, матимуть MSS змінений на 1360, що запобіжить надто великим сегментам, навіть якщо PMTUD не працює.

Рішення: Обирайте MSS на підставі виміряного path MTU і накладних. Даєте запас ~20–40 байт, якщо шлях змінюється (LTE, домашній Wi‑Fi, особливості ISP).

Завдання 7: Перевірте, чи MSS clamp діє (Linux)

cr0x@server:~$ sudo tcpdump -ni wg0 'tcp[tcpflags] & (tcp-syn) != 0' -c 2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:12:44.111111 IP 10.20.30.10.51200 > 10.20.30.40.445: Flags [S], seq 11111111, win 64240, options [mss 1360,sackOK,TS val 210 ecr 0,nop,wscale 7], length 0
12:12:45.222222 IP 10.20.30.10.51201 > 10.20.30.40.3389: Flags [S], seq 22222222, win 64240, options [mss 1360,sackOK,TS val 211 ecr 0,nop,wscale 7], length 0

Що це означає: SYN тепер рекламує MSS 1360. Ви зняли драму з розміром пакетів зі столу.

Рішення: Перетестуйте копіювання SMB і передавання файлів по RDP. Якщо все ще погано, переходьте до діагностики втрат/затримок.

Завдання 8: Перевірте, чи ICMP «fragmentation needed» відкидається (лічильники фаєрвола Linux)

cr0x@server:~$ sudo iptables -L INPUT -v -n | head
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 120K  96M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
  120  9600 ACCEPT     icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0            icmp type 3 code 4
    0     0 DROP       icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0

Що це означає: Ви явно дозволяєте ICMP type 3 code 4 (frag needed). Якщо ці лічильники нульові під час відтворення проблеми, повідомлення можуть блокуватися вище по ланцюжку або не генеруватися.

Рішення: Переконайтеся, що ICMP «frag needed» і «packet too big» дозволені на краях мережі. Якщо не можете це гарантувати — тримайте MSS clamping.

Завдання 9: Підтвердьте налаштування MTU у WireGuard (Linux)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=
  private key: (hidden)
  listening port: 51820

peer: YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY=
  endpoint: 203.0.113.10:51820
  allowed ips: 10.20.30.0/24
  latest handshake: 1 minute, 2 seconds ago
  transfer: 2.31 GiB received, 3.02 GiB sent
  persistent keepalive: every 25 seconds

Що це означає: WireGuard тут не показує MTU; потрібно перевіряти MTU інтерфейсу через ip link. Хендшейк і передачі підтверджують, що тунель живий; MTU усе ще може бути невірним.

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

Завдання 10: Встановити MTU на тунельному інтерфейсі Linux (приклад WireGuard)

cr0x@server:~$ sudo ip link set dev wg0 mtu 1380

Що це означає: Ви примусово знижуєте MTU тунелю. Кінцеві пристрої зазвичай обиратимуть менший MSS, зменшуючи залежність від PMTUD.

Рішення: Віддавайте перевагу коректному налаштуванню MTU на тунелі плюс MSS clamping на краю, якщо обслуговуєте немодерованих клієнтів.

Завдання 11: Перевірити MTU на Windows (перевірка на стороні клієнта)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface | Sort-Object -Property InterfaceMetric | Select-Object -First 8 ifIndex,InterfaceAlias,AddressFamily,NlMtu,InterfaceMetric"
ifIndex InterfaceAlias            AddressFamily NlMtu InterfaceMetric
------ --------------            ------------- ----- ---------------
12     Wi-Fi                      IPv4         1500  25
19     VPN - Corp                  IPv4         1500  35
12     Wi-Fi                      IPv6         1500  25
19     VPN - Corp                  IPv6         1500  35

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

Рішення: Виправте MTU у профілі VPN‑адаптера там, де підтримується, або затисніть MSS на VPN‑шлюзі, щоб клієнти не повинні були бути ідеальними.

Завдання 12: Тестуйте пропускну здатність SMB і зависання з Windows без домислів

cr0x@server:~$ powershell -NoProfile -Command "robocopy \\10.20.30.40\share C:\Temp\mtu-test bigfile.bin /J /R:1 /W:1 /NP"
-------------------------------------------------------------------------------
   ROBOCOPY     ::     Robust File Copy for Windows
-------------------------------------------------------------------------------
  Started : Sunday, December 28, 2025 12:20:01
   Source : \\10.20.30.40\share\
     Dest : C:\Temp\mtu-test\

    Files : bigfile.bin

  Options : /NP /R:1 /W:1 /J

------------------------------------------------------------------------------

         1    \\10.20.30.40\share\bigfile.bin
           0%        0.0 MB         0.0 MB/s        0:00:05

Що це означає: Якщо це зависає на 0% або гальмує в певній точці — ймовірно, у вас проблема транспорту (MTU/MSS, втрата, інспекція фаєрволу), а не права доступу до файлу. Ключ /J використовує небуферизований I/O, зменшуючи ілюзії кешування на клієнті.

Рішення: Запустіть ще раз після MSS clamping / зміни MTU. Якщо відразу стало стабільно — ви довели причину.

Завдання 13: Перевірте OpenVPN‑подібний MSS‑фікс на Linux клієнті (якщо застосовується)

cr0x@server:~$ grep -E 'mssfix|tun-mtu|fragment' -n /etc/openvpn/client.conf
41:mssfix 1360
42:tun-mtu 1400

Що це означає: OpenVPN може примусово зменшувати пакети. Будьте обережні: fragment зазвичай не вітають; mssfix зазвичай безпечніший.

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

Завдання 14: Виявіть ретрансміти, що кричать «чорна діра» (Linux)

cr0x@server:~$ ss -ti dst 10.20.30.40 | head -n 20
ESTAB 0 0 10.20.30.10:51200 10.20.30.40:445
	 cubic wscale:7,7 rto:204 retrans:8/12 lost:0 sacked:0 unacked:1
	 bytes_sent:10485760 bytes_retrans:5242880 bytes_acked:5242880

Що це означає: Високі значення retransmits і retransmitted bytes під час SMB‑сесії відповідають випадкам падіння пакетів. PMTUD black hole часто породжує повторювані ретрансміти з постійним інтервалом.

Рішення: Якщо MSS clamping зменшить ретрансміти і відновить пропускну здатність — тримайте його. Якщо ні — шукайте втрати, шейпінг або зламані middlebox‑и.

Три корпоративні міні-історії (анонімізовано)

1) Інцидент, спричинений невірним припущенням

Було акуратне налаштування: невеликий штаб, кілька філій і «сучасний» IPsec VPN між сайтами. Маркетинг фаєрвол‑вендора обіцяв «автоматичну оптимізацію шляху», тому команда вирішила, що MTU опрацьовано. Ніхто не вимірював, бо «воно працює».

Перший великий інцидент стався у день виплати зарплат. Бухгалтерія не могла відкрити великі таблиці, що зберігалися на SMB‑шарі в HQ. Малі таблиці відкривалися одразу. Великі завантажувалися наполовину, потім Excel зависав настільки, що люди починали насильно закривати програму й писати тикети. RDP‑сеанси до термінального сервера фінансів залишалися підключеними, але гальмували, коли хтось копіював файли через перенаправлені диски.

Команду зі сховища викликали, бо «файли повільні». Вони перевірили CPU сервера, затримки дисків і лічильники SMB. Все виглядало нормально. Нетвік‑команда говорила «немає втрат пакетів», виходячи з помилок інтерфейсу і кількох ping‑ів. VPN‑команда наполягала, що шифрування стабільне, бо тунель тримається.

Невірне припущення було простим: «якщо тунель підключений — MTU має бути в порядку». DF ping тест через тунель не пройшов вище payload, що вказував на внутрішній MTU у високих 1300‑х. PMTUD‑повідомлення блокував upstream ACL, який хтось скопіював роки тому. Після того, як вони клацнули MSS на брандмауері філії, проблема зникла миттєво — без змін на сховищі, без налаштувань серверів, без магії Excel.

Вони могли б заощадити день, якби спочатку виміряли розмір пакетів. Натомість провели три наради і звинуватили файловий сервер, який просто виконував свою роботу.

2) Оптимізація, що обернулася проти них

Інша компанія хотіла «кращу продуктивність» для віддалених інженерів. Хтось ввімкнув jumbo frames всередині віртуального перемикача, бо SAN‑команда мала гарні результати з 9000 MTU у дата‑центрі. Потім вони поширили той самий VLAN‑профіль на набір VM для термінацій VPN, бо «послідовність».

Локально все летіло. iSCSI‑трафік покращився. East‑west трафік VM виглядав чудово. Через VPN це було повільне лихо. Деякі клієнти працювали добре, в інших були періодичні зависання. SMB‑копії через VPN стартували швидко, потім обрушувалися. RDP відчувався як модемний зв’язок, коли хтось переміщував файли.

Механізм відкату був не магічний. Це було найгірше з обох світів: сервери й VM почали вважати, що можуть відправляти більші кадри, в той час як WAN і споживчі ISP зовсім не могли. PMTUD мав би врятувати, але IDS‑правила скидали ICMP як «шум». Результат — чорна діра, що з’являлася лише при більших розмірах сегментів. Менші інтерактивні потоки залишалися переважно в порядку, що ускладнювало переконання менеджменту, що це мережева проблема.

Виправлення полягало в тому, щоб припинити трактувати «jumbo frames скрізь» як рису характеру. Вони повернули MTU на інтерфейсах, що виходять у VPN, до здорового значення, ввімкнули MSS clamping і явно дозволили ICMP «packet too big» через стек безпеки. Продуктивність стабілізувалась, а єдиний тривалий наслідок — втрата довіри команди до «одного MTU, щоб їх керувати всіма».

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

Одна IT‑команда, що використовувала WireGuard для розробників і IPsec для site‑to‑site, зробила непопулярну річ: вони вели одну сторінку «контракту розмірів пакетів». Там був перелік очікуваного MTU для типів тунелів, припущення по накладних і стандартні значення MSS clamp для кожного краю.

Коли на філії підключили нову лінію ISP, молодший інженер помітив, що великі SMB‑копії в HQ зависають, але лише з тієї філії. Перед ескалацією він запустив стандартний DF ping тест зі свого чекліста і задокументував максимальний робочий payload. Він виявився приблизно на 60 байт менший, ніж очікували.

Оскільки у них був контракт, не було дискусій про «тюнінг SMB» чи «апгрейд файлового сервера». Вони негайно перевірили підключення ISP і знайшли додатковий рівень інкапсуляції, введений CPE провайдера. Ніхто про це не повідомив; ніхто не здивувався. Вони понизили MTU тунелю і зберегли MSS clamp в уніфікованому вигляді.

Ця філія запустилася за планом. Ніхто поза IT не помітив. Ось що таке хороша експлуатація: нудно, відтворювано і тихо правильнo.

Стратегії виправлення, які справді працюють

Стратегія A: Встановіть MTU тунелю правильно (найкраще, коли ви контролюєте обидва кінці)

Якщо ви керуєте обома кінцями VPN (site‑to‑site, керовані клієнти), встановлення MTU на тунельному інтерфейсі — чисте рішення. Воно змусить кінцеві пристрої обирати менші розміри пакетів і зменшить фрагментацію та ретрансміти.

Чого уникати: випадкові числа MTU, скопійовані з форумів. Виміряйте шлях і оберіть значення з запасом.

Стратегія B: Зажміть TCP MSS на краю VPN (найкраще, коли клієнти хаотичні)

MSS clamping — це робоча конячка. Воно не вимагає, щоб кожен клієнт поводився правильно. Воно не потребує, щоб PMTUD спрацював. Воно просто змушує TCP сегментувати обережно.

Де застосовувати: на шляху форвардування, який несе клієнтський трафік у тунель (FORWARD chain на Linux шлюзах, політика фаєрволу на аплайєнсах або еквівалент).

Чого уникати: зажимати занадто низько «на всякий випадок». Ви можете калічити пропускну здатність, якщо оберете надто малий MSS. Консерватизм — добре; параною не варто переплачувати.

Стратегія C: Виправте обробку ICMP, щоб PMTUD працював (найкраще для коректності, часто політично важко)

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

Операційна реальність: команди безпеки часто бояться ICMP, бо воно видиме й легко неправильно інтерпретується. Ваше завдання — пояснити, що PMTUD не розкіш, а сантехніка.

Стратегія D: Усуньте зайві рівні інкапсуляції (найкраще для довгострокової розумності)

Іноді MTU не той, бо у вас є кілька накладених оверлеїв: GRE поверх IPsec поверх PPPoE поверх LTE з натяком NAT. Кожен шар краде байти й додає режими помилок.

Що робити: спростити. Якщо потрібні і шифрування, і маршрутизація — віддавайте перевагу одному добре підтримуваному тунелю замість вкладення.

Стратегія E: Не «виправляйте» це заставленням TCP поверх TCP, якщо не любите болю

OpenVPN over TCP може приховати деякі симптоми, але вводить режим колапсу при втраті (TCP повторні передачі всередині TCP повторних передач). Це може зробити відчуття загальмування схожим на сироп.

Рекомендація: віддавайте перевагу UDP‑тунелям для транспорту VPN, а потім керуйте MTU/MSS чисто.

Жарт #2 (коротко і по темі): блокування ICMP заради «покращення безпеки» — це як зняти лампочку масла, щоб не бачили попереджень двигуна.

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

1) Симптом: шар SMB переглядається, але копіювання великого файлу зависає на 0% або кілька відсотків

Причина: MSS занадто високий; великі TCP‑сегменти не проходять через тунель; PMTUD зворотний канал заблоковано.

Виправлення: затисніть MSS на VPN‑шлюзі (наприклад, 1360) і/або зменшіть MTU тунелю; дозволіть ICMP frag‑needed/packet‑too‑big.

2) Симптом: RDP нормальний до копіювання файлу або передачі буфера обміну, потім сеанс «зависає»

Причина: bulk‑канал RDP натрапляє на MTU black hole; keepalive і невеликі оновлення ще проходять.

Виправлення: те саме, що вище; перевірте MSS у SYN пакетах; перетестуйте контрольованою передачею файлу.

3) Симптом: працює з деяких домашніх ISP, але не з інших

Причина: змінний WAN MTU (PPPoE, LTE, DOCSIS особливості) плюс фіксоване припущення по MTU/MSS у тунелі.

Виправлення: оберіть консервативний MTU тунелю (наприклад, 1380–1420 залежно від технології), затисніть MSS і не покладайтеся на PMTUD через споживчу техніку.

4) Симптом: малі ping‑и працюють; великі DF ping‑и падають без помилки

Причина: PMTUD black hole; ICMP‑повідомлення відкидаються.

Виправлення: дозволити потрібні типи ICMP; якщо це політична боротьба — затисніть MSS і живіть далі.

5) Симптом: «Ми знизили MTU і тепер усе стало повільніше»

Причина: MTU знижений надмірно; накладні витрати зросли через надто малі сегменти; CPU‑накладні витрати піднялися.

Виправлення: виміряйте реальний максимальний MTU і встановіть MTU/MSS з мінімальним запасом. Не обрізайте до 1200, якщо це не потрібно.

6) Симптом: лише SMB через VPN погано; iperf виглядає нормально

Причина: невідповідність тестів: iperf може використовувати інші потоки, інший MSS або інакше переносити ретрансміти; SMB краще виявляє біль.

Виправлення: відтворіть проблему за допомогою DF ping і знімку пакетів; перевірте MSS; тестуйте одиничний довгий TCP‑потік, схожий на SMB.

7) Симптом: проблеми почалися після «жорсткої політики безпеки»

Причина: фільтрація ICMP або функції інспекції VPN, що заважають фрагментації/PMTUD або TCP‑опціям.

Виправлення: явно дозволіть потрібні типи ICMP; відключіть зламані «корисні» фічі (наприклад, агресивну перезапис MSS без розуміння).

8) Симптом: VPN працював місяці, потім періодично падає в пікові години

Причина: зміни шляху (новий маршрут ISP), варіабельність MTU або новий middlebox, що відкидає ICMP під навантаженням.

Виправлення: затисніть MSS (стабільність), потім дослідіть поведінку ICMP і path MTU у часі.

Чеклісти / покроковий план

Покроково: від «SMB зависає» до стабільних передач

1. Виберіть один невдалий потік: один клієнт, один сервер, один шар, один великий файл.
2. Підтвердьте маршрутизацію: переконайтесь, що трафік дійсно використовує VPN‑інтерфейс (Linux: ip route get).
3. Запустіть DF ping‑тести, щоб знайти максимальний робочий payload (Linux: ping -M do -s). Задокументуйте.
4. Захопіть SYN‑пакети і зафіксуйте рекламований MSS (Linux: фільтр tcpdump для SYN).
5. Порівняйте MSS із виміряним path MTU: якщо MSS натякає на 1500 MTU, а ви виміряли ~1392 MTU — ви знайшли невідповідність.
6. Реалізуйте MSS clamping на краю VPN для форвард‑трафіку; збережіть запис про значення і причину.
7. Опційно понизьте MTU тунелю, щоб кінцеві пристрої природно рекламували безпечніший MSS.
8. Перетестуйте те ж саме копіювання файлу. Не міняйте три речі одразу; тримайте контроль.
9. Перевірте зникнення ретрансмітів (Linux: ss -ti, або статистика захоплення пакетів).
10. Вирішіть, чи виправляти ICMP належно: дозволити потрібні типи ICMP або прийняти MSS clamping як постійне рішення.
11. Впроваджуйте по шарах: пілотуйте одну філію, потім розгортайте; уникайте «великого руху» MTU‑змін по всьому парку.
12. Запишіть контракт розмірів пакетів: стандартні MTU/MSS для типу VPN і як їх вимірювати. Це нудна практика, що рятує вихідні дні.

Політичний чекліст: що дозволяти через фаєрволи

• IPv4: ICMP type 3 code 4 («Fragmentation needed») у потрібних напрямках.
• IPv6: ICMPv6 «Packet Too Big» та суміжні neighbor discovery (не ламайте основи IPv6).
• Rate limiting: помірне обмеження швидкості ICMP допустиме; повні відмови — ні.

Операційний чекліст: що фіксувати в тикетах

• Тип клієнтської мережі (домашній Wi‑Fi, LTE‑хотспот, офісна LAN).
• Тип VPN і інкапсуляція (IPsec NAT‑T, WireGuard, SSL VPN).
• Найбільший DF ping payload, що пройшов.
• MSS, спостережений у SYN до і після змін.
• Чи бачаться ICMP frag‑needed/packet‑too‑big повідомлення.
• Чи симетрична проблема (client→server і server→client).

ЧаПи (FAQ)

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

Малі передачі часто вкладаються в менші TCP‑сегменти або закінчуються, поки з’єднання не натрапить на проблемні розміри пакетів. Великі передачі утримують великі сегменти і врешті натрапляють на реальний ліміт MTU шляху.

2) Якщо PMTUD існує, навіщо MSS clamping?

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

3) Яке значення MSS мені ставити?

Керуйтеся вимірюваннями. Знайдіть максимальний робочий IPv4‑пакет за допомогою DF ping (наприклад, 1392). Відніміть 40 байт для IP+TCP заголовків: MSS ≈ 1352. Потім оберіть трохи менше значення (наприклад, 1340–1352) для урахування варіабельності.

4) Чи краще понизити MTU тунелю, ніж MSS clamping?

Якщо ви контролюєте обидва кінці тунелю і клієнти послідовні — встановлення MTU на тунелі чисте рішення. У змішаних клієнтських середовищах (домашні мережі, мобільні ноутбуки) MSS clamping на шлюзі більш стійке.

5) Чи може шифрування або підписування SMB спричинити це?

Воно може змінити розміри пакетів і поведінку пропускної здатності, що швидше виявить наявну MTU‑проблему. Але корінь — у транспорті: пакети занадто великі для шляху і відсутній робочий канал зворотного зв’язку.

6) Чому іноді відмовляє лише один напрямок?

Асиметричні шляхи — звична річ: різні ISP, різні NAT‑пристрої, різні правила фільтрації. В одному напрямку можуть дозволяти ICMP «packet too big», а в зворотному — відкидати.

7) Чи стосується це IPv6 також?

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

8) Чи можна просто дозволити фрагментацію і забути?

Покладатися на фрагментацію зазвичай останній вихід. Вона додає накладні витрати, підвищує чутливість до втрат і може погано взаємодіяти з фаєрволами та NAT. Віддавайте перевагу коректному MTU і MSS clamping.

9) Чому трафік тесту швидкості виглядає добре, а SMB зависає?

Різні інструменти використовують різні патерни (кілька потоків, різні розміри сегментів, UDP проти TCP). SMB — довготривалий, станoвий TCP‑потік, який чудово виявляє умови з великою кількістю ретрансмітів.

10) У нас універсальний фаєрвол‑аплайнс. Де застосувати MSS clamping?

На політиці, що дозволяє трафік з внутрішньої зони в зону VPN/тунель, або на egress інтерфейсі VPN. Вендори називають це по‑різному, але мета одна: перезапис MSS у SYN пакетах, що йдуть у тунель.

Висновок: кроки, що не засоромлять вас

Якщо ваш офісний VPN «переважно працює», але великі SMB‑копії зависають або передавання файлів по RDP заморожується, сприймайте це як інцидент MTU/MSS, поки не доведено інше. Виміряйте path MTU за допомогою DF ping. Спостерігайте MSS у SYN‑пакетах. Зажміть MSS на краю VPN. І тільки потім сперечайтесь про тюнінг SMB або продуктивність сховища.

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

1. Запустіть DF ping‑тест через VPN і зафіксуйте найбільший робочий payload.
2. Захопіть SYN і підтвердьте, який MSS рекламують.
3. Впровадьте MSS clamping на VPN‑шлюзі для трафіку в тунель.
4. Опційно відкоригуйте MTU інтерфейсу тунелю, щоб відповідати реальності.
5. Запишіть обрані значення MTU/MSS і вимірювання, що за ними стоять. Майбутній ви захоче квитанції.