VPN повільніший, ніж очікували: діагностика CPU роутера, крипто та MSS clamping як слід

January 7, 2026 • February 3, 2026 • Читання: 6 хв • Views: 10

Було корисно?

Ваш VPN-лінк «вгору», пінг виглядає нормально, але копіювання файлів повзе, немов це 2003 рік і хтось підняв трубку.
Ласкаво просимо до найпоширенішого режиму відмови VPN у продакшні: не «впав», а соромливо повільніший, ніж те, за що ви платите.

Виправлення рідко містичне. Зазвичай це вузьке місце, яке можна виміряти: CPU роутера, завантажений криптою, однопотоковий демон,
проблеми з PMTUD, або MSS clamping, зроблений «майже правильно» (найгірший різновид правильного).
Ось як діагностувати це без культу налаштувань, поки «не здається краще».

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

Це послідовність, що швидко знаходить вузьке місце. Мета не «зібрати дані». Мета — приймати рішення після кожного кроку:
обмеження CPU? MTU? втрата/bufferbloat? шейпінг? однопотоковість? оффлоад вимкнено? Рухайтесь далі тільки коли можете сказати «не це».

1) Доведіть, чи обмежена пропускна здатність тунелю кінцями чи шляхом

Запустіть iperf3 через VPN в обох напрямках. Використайте кілька паралельних потоків (1 і 4).
Якщо 1 потік повільний, а 4 потоки значно швидші, у вас проблема з TCP/переповненням/MTU/втратою, а не з чистим лінком.
Порівняйте з тестом iperf поза VPN (якщо можливо). Якщо WAN швидкість в нормі, а VPN ні — проблема в оверхеді тунелю або обчисленнях на кінцях.

2) Перевірте CPU роутера (особливо шлях крипто)

Шукайте один ядро, зафіксоване на 100% (класичний OpenVPN) або високий softirq / ksoftirqd (обробка пакетів).
Підтвердьте, чи активне апаратне прискорення крипто/оффлоад. Воно часто вимикається, коли вмикають NAT, policy routing або «корисну» функцію.

3) Перевірте MTU/PMTUD/MSS перед тим, як «підганяти TCP»

Виконайте бінарний пошук за допомогою ping з DF (не фрагментувати). Знайдіть реальний path MTU через тунель.
Якщо ICMP frag-needed блокується десь, PMTUD ламається і TCP зависає або робить ретрансмісії. MSS clamping може маскувати це, але тільки якщо налаштований правильно.

4) Виміряйте втрати, перестановки та bufferbloat

Використовуйте mtr і iperf3 у режимі UDP з обережністю. Якщо бачите втрати під навантаженням, виправляйте черги/шейпінг, а не налаштування шифрування.

5) Лише потім: беріться за специфіку конфігурації (набори шифрів, режим тунелю, фрагментація)

Не починайте зі зміни AES-256 на ChaCha20 «бо Reddit». Якщо CPU простий і MTU коректний, вибір шифру — не ваш вузький шлях.

Ментальна модель, яка запобігає дурним здогадкам

Продуктивність VPN — це добуток трьох окремих систем, які люблять виходити з ладу незалежно:

Обчислення: Чи може ваш кінцевий вузол шифрувати/дешифрувати пакети на швидкості лінії? Це охоплює CPU, апаратне прискорення крипто, kernel vs userspace
і те, чи випадково ви пропустили всі пакети через повільний шлях.
Розмір пакетів: Інкапсуляція додає оверхед. Якщо ефективний MTU неправильний, ви отримуєте фрагментацію, втрати і дивну поведінку TCP.
PMTUD мав це вирішувати, поки хтось не заблокував ICMP «ради безпеки».
Транспортна динаміка: Пропускна здатність TCP залежить від RTT, втрат і чергування. VPN часто додають дещо RTT і можуть посилити bufferbloat,
що вбиває пропускну здатність задовго до заповнення лінку.

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

Є цитата, яку варто мати на стікері, бо вона дуже доречна тут:
«Надія — не стратегія.» — Gordon R. Sullivan

Цікаві факти та коротка історія (бо пояснює дивності)

IPsec передує «модерній інтернет-параною». Ранні RFC для IPsec датуються серединою 1990-х; він був розроблений для захисту IP сам по собі,
задовго до того, як «zero trust» став шаблоном слайдів.
Класична архітектура OpenVPN історично ворожа до CPU. Класичний OpenVPN працює в userspace і (часто) проганяє більшу частину трафіку через
один потік, тому одне завантажене ядро може обмежувати пропускну здатність, навіть якщо решта ядер майже порожні.
WireGuard навмисно компактний. Його кодова база відома своєю компактністю в порівнянні з типовими VPN-стеками, що зменшує площу атаки і часто покращує
продуктивність через інтеграцію з ядром і сучасні крипто-вибори.
PMTUD мала ліквідувати фрагментацію. Path MTU discovery (концепт кінця 1980-х, широко впроваджений пізніше) покладається на ICMP-повідомлення.
Заблокуйте ICMP — і ви повертаєтесь до «таємничих зависань».
MSS clamping — це старе обхідне рішення, яке відмовляється вмирати. Його використовують десятиліттями, щоб уникнути фрагментації, коли PMTUD ламається,
особливо через PPPoE і тунелі.
AES-NI змінив економіку VPN. Коли поширилися x86 CPU з прискоренням AES, твердження «крипто повільне» перестало бути істинним загалом.
На невеликих роутерах і ARM SoC це досі дуже актуально.
GCM vs CBC — це не лише академічне питання. AEAD-режими, як AES-GCM, можуть бути швидшими й безпечнішими в сучасних реалізаціях, але лише якщо апарат і драйвери
добре їх підтримують; інакше можна отримати повільніший результат, ніж очікували.
Оверхед інкапсуляції — це не обхідні фізичні закони. Ви платите байтами за заголовки, теги автентифікації і іноді UDP-обертання.
Це зменшує ефективність корисного навантаження і може виштовхнути вас за межі MTU.

Жарт #1: Діагностика VPN схожа на археологію — ви зчищаєте шари «тимчасових» виправлень, поки не знайдете фосилізований MTU з 2014 року.

Симптоми, що мають значення (і ті, що вводять в оману)

Симптоми, які реально звужують пошук

Пропускна здатність обрізана на підозріле число (наприклад, 80–200 Мбіт/с) незалежно від WAN — часто CPU/crypto або однопотокові обмеження.
В одному напрямку швидко, в іншому повільно: асиметрична маршрутизація, асиметричний шейпінг або CPU, зафіксований лише на одній стороні.
Малі передачі «виконуються нормально», великі застрягають: MTU/PMTUD проблеми або bufferbloat під навантаженням.
Кілька TCP-потоків значно краще за один: втрата пакетів, перестановки або MTU black-hole; чистий лінк, ймовірно, в порядку.
UDP трафік в нормі, TCP жахливий: класичний симптом втрат/чергування/MTU, а не обмеження сирого каналу.

Симптоми, на які витрачаєте час, якщо надто на них фіксуєтесь

Пінг виглядає чудово: пінг — це крихітні пакети; ваша проблема зазвичай у великих пакетах під навантаженням.
Середній CPU низький: важливо одне зафіксоване ядро; середні значення брешуть.
«Після вмикання функції безпеки X стало гірше»: можливо, але вимірюйте. Кореляція — наркотик для кар’єри.

CPU роутера і обмеження крипто: мовчазний убивця пропускної спроможності

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

Шаблони вузьких місць CPU, які можна швидко розпізнати

На товарних роутерах пропуск VPN часто обмежений:

Однопотокове шифрування (поширено в OpenVPN): одне ядро досягає 100%, пропускна здатність вирівнюється, і ви не можете «оптимізувати» це, окрім як змінити архітектуру (DCO, kernel mode, інший протокол) або апаратне забезпечення.
Навантаження на обробку пакетів у ядрі: високі softirq, ksoftirqd, багато дрібних пакетів (ACKи), NAT, conntrack і firewall-правила.
Апаратне прискорення крипто не використовується: ви купили пристрій з прискоренням, але шлях трафіку його не зачіпає.
Або обрані шифри/налаштування обходять апарат.

Крипто — це не тільки «AES проти ChaCha»; це весь шлях даних

Люди люблять сварки про шифри, бо це наче налаштовувати гоночну машину. Але більшість проблем продуктивності VPN ближче до «шини спущена».
Задайте некрасиві питання:

Чи VPN у ядрі чи в userspace?
Чи це UDP або TCP транспорт?
Чи апаратний оффлоад активний наскрізь?
Чи увімкнення NAT або policy routing відключило fast-path forwarding?
Чи робите ви deep packet inspection або надмірне логування firewall на зашифрованих потоках?

Ключова діагностика: якщо збільшення паралельних потоків значно підвищує пропускну здатність, ви не повністю CPU-заблоковані криптою.
Якщо пропускна здатність вирівнюється на тому ж числі незалежно від потоків і розміру пакетів, імовірно, ви заблоковані.

MTU, PMTUD-чорні діри та MSS clamping: де «працює» перетворюється на «повільно»

VPN додає заголовки. Заголовки відбирають MTU. Коли ви це ігноруєте, отримуєте фрагментацію або втрати. Коли PMTUD поламано, ви не бачите чистого збою.
Ви отримуєте тайм-аути, ретрансміти і пропускну здатність, яка виглядає як випадкова величина.

Оверхед інкапсуляції: математика, яка вам справді потрібна

Почніть просто: Ethernet MTU зазвичай 1500 байт. VPN-пакет має вміститись в це.
Якщо ви додаєте (наприклад) IP + UDP + VPN-заголовок + тег автентифікації, ви зменшуєте корисне навантаження.

Точний оверхед варіюється за протоколом і налаштуваннями. Не вгадуйте. Виміряйте реальний ефективний path MTU через тунель.

PMTUD-чорна діра: класична «помилка безпеки»

PMTUD покладається на ICMP «Fragmentation Needed». Блокуйте їх — і TCP продовжує відправляти надто великі пакети з встановленим DF, які відкидаються непомітно.
TCP тоді відступає, робить ретрансміти і повзе.

MSS clamping — це обхід: якщо ви зменшите TCP MSS так, щоб кінцеві вузли ніколи не відправляли пакети, що потребують фрагментації, ви обходите PMTUD.
Але потрібно клампити на правильному інтерфейсі, у правильному напрямку, для правильного трафіку.

Чому MSS clamping іноді «трохи допомагає», але не вирішує

Ви клампнули MSS на WAN-інтерфейсі замість тунельного (або навпаки).
Ви клампнули тільки пересланий трафік, а не локально згенерований (або навпаки).
Ви клампнули до значення, яке все ще занадто велике для реального інкапсульованого MTU.
Ви клампнули TCP, але проблемний трафік — UDP (деякі додатки) або у вас IPsec з проблемами ESP-фрагментації.

Жарт #2: MSS clamping — як підстригати чубчик бензопилою — може спрацювати, але вам не сподобається процес і крайні випадки.

Поведінка TCP через VPN: чому затримка і втрата множать біль

Пропускна здатність TCP — це не просто «швидкість». Це пропускна здатність, обмежена поведінкою контролю затору і добутком пропускної здатності на затримку.
VPN часто додають трохи затримки. Вони також часто додають чергування (особливо якщо роутер занадто буферизує).
Невелика кількість втрат під навантаженням може драматично скоротити пропускну здатність.

Що насправді означає «декілька потоків швидше, ніж один»

Коли один TCP-потік повільний, але чотири паралельні насичують канал, ви бачите одне або більше з наступного:

події втрат, що призводять до колапсу вікна одного потоку
bufferbloat, що створює велику варіацію RTT і затримку ACK
ретрансміти через проблеми MTU/фрагментації
настройка політики на потік/поліцингу на якомусь middlebox

Не «виправляйте» це, змушуючи користувачів використовувати більше паралелізму. Це перетворює вашу мережу на експеримент з чергуваннням.
Виправте корінь: коректний MTU, керування чергами (fq_codel/cake), правильний шейпінг на краю або кращий datapath VPN.

VPN поверх TCP — зазвичай самі винні

Запуск VPN-тунелю поверх TCP, а потім TCP всередині нього створює TCP-over-TCP мелтдаун: ретрансміти та контролі затору конфліктують.
Якщо можна, використовуйте UDP для транспорту тунелю. Якщо ні — очікуйте «працює, але дивно повільно при втратах».

Апаратне прискорення, NAT і чому прискорення іноді зникає

Багато роутерів рекламують «гігабітний VPN». Потім ви вмикаєте NAT, QoS, IDS, VLAN tagging, policy routing або просто інший шифр, і раптом маєте 120 Мбіт/с.
Пропущений елемент зазвичай — fast-path/offload. Апаратне прискорення примхливе; воно часто вимагає дуже конкретного шляху трафіку.

Типові способи випадково вимкнути оффлоад

NAT на зашифрованому інтерфейсі, коли оффлоад-двигун очікує маршрутизований forwarding.
Правила фаєрвола, що вимагають глибокої інспекції на datapath (або логування кожного пакета «через аудит»).
Policy-based routing, що виводить пакети з прискореного конвеєра.
Використання непідтриманого шифру/режиму для апаратного движка.
Обробка фрагментації у софті через невідповідність MTU.

Вам не потрібно поклонятися оффлоаду. Але потрібно знати, чи він активний. Інакше ви налаштовуєте не той двигун.

Практичні завдання (команди, виводи, рішення) — робіть це, а не настрій

Нижче — конкретні завдання. Кожне містить команди, зразковий вивід, що це означає, і рішення, яке ви приймаєте.
Запускайте їх на кінцях VPN (роутери, Linux-шлюзи або сервери) і на клієнті, якщо потрібно.

Завдання 1: Виміряти сирий пропуск за допомогою iperf3 (1 потік vs 4 потоки)

cr0x@server:~$ iperf3 -s
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------

cr0x@server:~$ iperf3 -c 10.20.0.10 -P 1 -t 15
Connecting to host 10.20.0.10, port 5201
[  5]   0.00-15.00  sec   145 MBytes  81.0 Mbits/sec  0             sender
[  5]   0.00-15.01  sec   143 MBytes  79.8 Mbits/sec                receiver

cr0x@server:~$ iperf3 -c 10.20.0.10 -P 4 -t 15
Connecting to host 10.20.0.10, port 5201
[SUM]   0.00-15.00  sec   580 MBytes   324 Mbits/sec  12             sender
[SUM]   0.00-15.01  sec   575 MBytes   321 Mbits/sec                receiver

Значення: Один потік — 80 Мбіт/с, чотири потоки — 320 Мбіт/с. Шлях може передавати дані, але один TCP-потік страждає.
Рішення: Пріоритезуйте діагностику MTU/PMTUD, втрат і чергування. Не купуйте новий хардвер одразу.

Завдання 2: Перевірте насичення CPU та «гарячі» ядра (Linux)

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.8.0 (gw-a)  12/28/2025  _x86_64_  (8 CPU)

12:10:01 AM  CPU   %usr %nice  %sys %iowait  %irq %soft  %steal %idle
12:10:02 AM  all    6.2  0.0   9.8    0.0    0.0  4.1     0.0  79.9
12:10:02 AM    0    2.0  0.0   6.0    0.0    0.0  1.0     0.0  91.0
12:10:02 AM    1   38.0  0.0  55.0    0.0    0.0  7.0     0.0   0.0
12:10:02 AM    2    1.0  0.0   2.0    0.0    0.0  0.0     0.0  97.0

Значення: CPU1 зафіксований (0% idle), інші переважно вільні. Це кричить «однопотоковий вузький шлях» або одна черга IRQ.
Рішення: Якщо це OpenVPN — протестуйте DCO або інший протокол. Якщо це IRQ — подумайте про налаштування RSS/RPS/XPS та черги NIC.

Завдання 3: Визначити процес VPN і чи він є гарячою точкою

cr0x@server:~$ top -H -b -n 1 | head -30
top - 00:10:12 up 12 days,  3:44,  1 user,  load average: 1.12, 0.98, 0.91
Threads: 274 total,   2 running, 272 sleeping,   0 stopped,   0 zombie
%Cpu(s): 45.3 us, 10.4 sy,  0.0 ni, 44.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 8421 root      20   0  164796  23452  10652 R  99.3   0.6  12:33.14 openvpn
 8428 root      20   0  164796  23452  10652 R  98.7   0.6  12:30.09 openvpn

Значення: Треди OpenVPN споживають CPU. Навіть якщо тредів два, datapath може бути обмежений способом обробки пакетів.
Рішення: Перевірте режим OpenVPN (userspace vs DCO), розгляньте перехід на WireGuard або IPsec з kernel-акселерацією, якщо доречно.

Завдання 4: Перевірити, чи доступне прискорення AES (x86 AES-NI)

cr0x@server:~$ grep -m1 -o 'aes\|avx\|sha_ni' /proc/cpuinfo | sort -u
aes
avx

Значення: CPU підтримує AES-інструкції. Це не гарантує, що ваш VPN їх використовує, але робить високу пропускну здатність реалістичною.
Рішення: Якщо пропускна здатність все ще низька, а CPU високий — підозрюйте неакселерований шлях, overhead userspace або вимкнений оффлоад.

Завдання 5: Підтвердити Handshake WireGuard і швидкості по peer

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

peer: 9q3B...redacted...
  endpoint: 198.51.100.20:49012
  allowed ips: 10.20.0.0/24
  latest handshake: 38 seconds ago
  transfer: 21.14 GiB received, 18.02 GiB sent
  persistent keepalive: every 25 seconds

Значення: Тунель живий. Лічильники передавання рухаються. Якщо продуктивність погана, вже не можна звинувачувати «нестабільність handshakes».
Рішення: Перейдіть до тестів MTU/чергування і профілювання CPU; сам WireGuard рідко є вузьким місцем, якщо коробка не слабка.

Завдання 6: Перевірити стан IPsec і чи занадто часто виконується rekey

cr0x@server:~$ sudo ip -s xfrm state
src 203.0.113.10 dst 198.51.100.20
	proto esp spi 0x0000000b reqid 1 mode tunnel
	replay-window 32 flag af-unspec
	aead rfc4106(gcm(aes)) 0x... 128
	anti-replay context: seq 0x0007a12f, oseq 0x0, bitmap 0x00000000
	lifetime config:
	  limit: soft (INF) hard (INF)
	lifetime current:
	  12345(s) 0(bytes)
	stats:
	  replay-window 0 replay 0 failed 0
	  bytes 9823141234 packets 912341 errors 0

Значення: IPsec стабільний (помилок немає, лічильники зростають). Rekey-чарн означав би повторювані зміни SA і іноді короткі паузи.
Рішення: Якщо CPU високий тут — шукати відсутнє апаратне прискорення або overhead малих пакетів; інакше йти до MTU/PMTUD.

Завдання 7: Знайти ефективний MTU через тунель за допомогою DF-пінгів (бінарний пошук)

cr0x@server:~$ ping -M do -s 1472 -c 3 10.20.0.10
PING 10.20.0.10 (10.20.0.10) 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

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

cr0x@server:~$ ping -M do -s 1392 -c 3 10.20.0.10
PING 10.20.0.10 (10.20.0.10) 1392(1420) bytes of data.
1400 bytes from 10.20.0.10: icmp_seq=1 ttl=64 time=18.6 ms
1400 bytes from 10.20.0.10: icmp_seq=2 ttl=64 time=18.7 ms
1400 bytes from 10.20.0.10: icmp_seq=3 ttl=64 time=18.5 ms

--- 10.20.0.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Значення: Ви виявили реальне MTU-обмеження (1420). Якщо тунельний інтерфейс налаштований вищим, ймовірні фрагментація або втрати.
Рішення: Встановіть MTU тунелю відповідно і/або клампіть MSS. Також перевірте, що ICMP frag-needed не блокується на шляху.

Завдання 8: Перевірити поточні MTU на інтерфейсах

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

Значення: wg0 MTU відповідає виявленому обмеженню. Добре.
Рішення: Якщо ви знайшли нижчий path MTU, ніж MTU інтерфейсу — зменшіть його; не «дозвольте фрагментації і надіятись».

Завдання 9: Перевірити правила MSS clamping (iptables) і підтвердити інкремент лічильників

cr0x@server:~$ sudo iptables -t mangle -S | grep -E 'TCPMSS|MSS'
-A FORWARD -o wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -i wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

cr0x@server:~$ sudo iptables -t mangle -L FORWARD -v -n | grep TCPMSS
  842K   52M TCP  --  *  wg0  0.0.0.0/0  0.0.0.0/0  tcp flags:0x02/0x02 TCPMSS clamp to PMTU
  799K   49M TCP  --  wg0 *   0.0.0.0/0  0.0.0.0/0  tcp flags:0x02/0x02 TCPMSS clamp to PMTU

Значення: MSS clamping застосований в обох напрямках і лічильники ростуть. Це бажано, коли PMTUD ненадійний.
Рішення: Якщо лічильники нульові — ви клампите не в тій ланці/інтерфейсі; виправте розташування. Якщо PMTUD працює — clamping може бути опцією.

Завдання 10: Підтвердити, що ICMP «fragmentation needed» не відкидається (приклад nftables)

cr0x@server:~$ sudo nft list ruleset | grep -n 'icmp type'
42:    ip protocol icmp icmp type { echo-request, echo-reply, destination-unreachable, time-exceeded } accept

Значення: «destination-unreachable» включає frag-needed повідомлення у багатьох налаштуваннях; блокування цього — як створити PMTUD-чорну діру.
Рішення: Якщо ваш набір правил дозволяє лише echo-request/echo-reply — розширте його. Команди безпеки можуть логувати це; вони не повинні відкидати.

Завдання 11: Шукати сигнали фрагментації і збирання в лічильниках інтерфейсу

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped overrun mcast
    9812312312 81231231 0       1234    0       0
    TX:  bytes  packets  errors  dropped carrier collsns
    8712312312 70123123 0       9876    0       0

Значення: Втрачені пакети під навантаженням (TX dropped, RX dropped) сильно корелюють з тиском буферів, помилками шейпінгу або проблемами MTU.
Рішення: Якщо дропи зростають під iperf, виправляйте чергування/шейпінг. Якщо дропи лише для великих пакетів — повертайтеся до MTU/MSS.

Завдання 12: Перевірити ретрансміти і TCP-проблеми (ss -i)

cr0x@server:~$ ss -ti dst 10.20.0.10 | head -20
ESTAB 0 0 10.10.0.5:46732 10.20.0.10:445
	 cubic wscale:7,7 rto:220 rtt:48.3/12.1 ato:40 mss:1360 pmtu:1420 rcvmss:1360 advmss:1360 cwnd:18 bytes_acked:8123412 segs_out:51234 segs_in:49871 send 40.5Mbps lastsnd:28 lastrcv:12 lastack:12 pacing_rate 81.0Mbps retrans:214/51234

Значення: Немаленькі ретрансміти (214) плюс скромне cwnd свідчать про втрати/чергування/MTU-проблеми, що впливають на TCP.
Рішення: Якщо ретрансміти ростуть під час передач — знайдіть, де пакети відкидаються. Не чіпайте sysctl, поки не припините дропи.

Завдання 13: Виявити bufferbloat під навантаженням, використовуючи ping під час насичення

cr0x@server:~$ ping -i 0.2 -c 20 10.20.0.10
PING 10.20.0.10 (10.20.0.10) 56(84) bytes of data.
64 bytes from 10.20.0.10: icmp_seq=1 ttl=64 time=19.2 ms
64 bytes from 10.20.0.10: icmp_seq=2 ttl=64 time=18.9 ms
64 bytes from 10.20.0.10: icmp_seq=3 ttl=64 time=210.5 ms
64 bytes from 10.20.0.10: icmp_seq=4 ttl=64 time=243.1 ms
64 bytes from 10.20.0.10: icmp_seq=5 ttl=64 time=198.7 ms

Значення: Сплески затримки під навантаженням — це чергування/bufferbloat. Це знищує TCP-пропускну здатність і робить додатки «зламаними».
Рішення: Впровадьте адекватне керування чергами (fq_codel/cake) і зробіть шейпінг на вузькому місці, зазвичай на виході WAN.

Завдання 14: Підтвердити qdisc і застосувати fq_codel (Linux) якщо потрібно

cr0x@server:~$ tc qdisc show dev eth0
qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

cr0x@server:~$ sudo tc qdisc replace dev eth0 root fq_codel
cr0x@server:~$ tc qdisc show dev eth0
qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn

Значення: pfifo_fast — музейний експонат. fq_codel забезпечує активне управління чергами, що зменшує bufferbloat.
Рішення: Якщо затримка стрибає під навантаженням — залиште fq_codel (або cake) і додайте шейпінг, якщо вузьке місце знаходиться вище.

Завдання 15: Перевірити NIC і розподіл IRQ (порада по RSS/RPS)

cr0x@server:~$ cat /proc/interrupts | head -12
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
  35:   9123412  781234123      12345      11234      10987      10321      10012       9987  IR-PCI-MSI 524288-edge  eth0-TxRx-0

Значення: Одна черга переривань, що лягає здебільшого на CPU1, може створити вузьке місце на ядрі, навіть якщо загальний CPU в порядку.
Рішення: Якщо одне ядро зафіксоване, а IRQ розподіл однобокий — налаштуйте RSS/RPS або змініть афінітет IRQ; або оновіть апарат/драйвер NIC.

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

Міні-історія 1: Інцидент через хибне припущення (PMTUD «закріплення безпеки»)

Середня компанія розгорнула site-to-site VPN між двома офісами і cloud VPC. Пінги були чудові. RDP працював.
Потім фінансисти почали експортувати великі звіти, і передача завмирала на 2–5% на хвилини, потім продовжувалась, потім знову зависала.
Початкове припущення: «крипто VPN занадто повільне; потрібні більші коробки».

Нет-команда перевірила CPU. Багато вільних ресурсів. Вони все одно поміняли шифри, бо люди так роблять, коли застрягають.
Невеликі покращення в одному напрямку, гірше в іншому. Проблема лишалась дивною і переривчастою — це розпалює погані теорії.

Один SRE зробив DF ping тест і миттєво отримав «message too long» MTU близько 1412 байт — менше ніж очікували.
Потім перевірили правила фаєрвола і знайшли, що ICMP destination-unreachable відкидається на «загартованому» perimeter ACL.
PMTUD був мертвий, тому TCP-сеанси чорними дірами відкидали більші пакети до тих пір, поки ретрансміти і тайм-аути не дозволяли просунутись.

Виправлення не вимагало більшого роутера. Потрібно було дозволити конкретні типи ICMP для PMTUD і додати MSS clamping як страхувальну міру.
Передачі перейшли з «хвилини зависань» до «надзвичайно швидко». Постмортем не був «не жорсткіть безпеки».
Це було «не ламаємо фундаментальні протоколи і не називаємо це безпекою».

Міні-історія 2: Оптимізація, що дала зворотний ефект (увімкнення «прискорення», яке відключило fast path)

Інша організація мала IPsec-тунель з доволі прийнятною продуктивністю. Нет-інженер увімкнув фічу вендора під назвою «advanced traffic inspection»
для «кращої видимості». Це мало бути легковаговим. Їх також ввімкнули глобально через зручність UI.

Протягом дня почали надходити скарги: джиттер VoIP, повільні копії файлів, лаги реплікації баз даних.
Моніторинг показав завантаження WAN нижче звичного, а затримки додатків зросли. Це завжди підказка: мережа не насичена; вона забита всередині.

CPU роутера не був загально зафіксований, але обробка пакетів стрибнула і переривання зросли. Лічильники оффлоаду впали.
Фіча інспекції змусила пакети вийти з прискореного datapath і піти в софтову «повільну смугу».
Раптом той самий хардвер почав виконувати більше роботи на пакет, і він не витримував піку.

Вимкнення фічі відновило оффлоад і пропускну здатність. Пізніше видимість повернули через flow logs на розшифрованій стороні і вибіркову вибірку,
а не інспекцію кожного пакета на тунельному інтерфейсі. Урок не «ніколи не інспектувати».
Урок — «якщо вмикаєте фічу, яка торкається кожного пакета, доведіть, що вона не вимикає те, що оплачує вашу продуктивність».

Міні-історія 3: Нудна, але правильна практика, що врятувала день (базові тести і дисципліна змін)

Компанія планувала міграцію сервісів між дата-центрами через VPN. Тунель «здавався нормальним» при випадкових тестах.
Але SRE наполягли на базовій перевірці: iperf3 в обох напрямках, 1 і 4 потоки, DF MTU-тести та ping під навантаженням.
Вони зафіксували результати не як академічне вправу, а як довідкові дані до/після.

Під час вікна міграції пропускність впала на ~60% і з’явились стрибки затримки під навантаженням.
Оскільки у них був базовий рівень, вони не витрачали час на суперечки про «нормальну інтернет-змінність».
Вони точно знали, як виглядає «нормально» для їхнього шляху.

Вони відкотили останню зміну: оновлення політики QoS на WAN-краю, яке випадково двічі шейпило тунельний трафік
(раз на фізичному інтерфейсі і ще раз на VLAN-субінтерфейсі). Подвійне шейпування спричинило чергування і дропи.
Виправлення було неславетне: один шейпер на реальному вузькому місці, fq_codel для справедливості і чітка відповідальність за політику.

Ніхто не отримав трофей за це. Але реплікація закінчилась вчасно і міграція не перетворилась на бриґаду інцидентів на вихідні.
Нудні практики — бази, інкрементальні зміни і «один шейпер для всіх» — це те, як дорослі тримають VPN швидкими.

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

Ось повторювані випадки. Якщо ви впізнаєте свою ситуацію — пропустіть імпровізації і зробіть конкретне виправлення.

1) Симптом: Швидкість обмежується на 80–200 Мбіт/с незалежно від умов

Корінна причина: CPU/crypto вузьке місце, однопотоковий VPN або вимкнений оффлоад.
Виправлення: Перевірте завантаження по ядрам. Підтвердіть статус оффлоаду. Перейдіть на kernel datapath (WireGuard, IPsec kernel) або OpenVPN DCO де можливо; інакше апгрейдніть хардвер.

2) Симптом: Малі веб-завантаження в нормі, великі файли зависають або повзуть

Корінна причина: Невідповідний MTU або PMTUD-чорна діра, що призводить до відкидання великих пакетів.
Виправлення: DF ping для знаходження реального MTU. Дозвольте ICMP destination-unreachable/time-exceeded. Клампіть MSS на шляху пересилання тунелю.

3) Симптом: В одному напрямку швидко, в зворотному повільно

Корінна причина: Асиметрична маршрутизація, асиметричний шейпінг або один кінець CPU-забитий шифром.
Виправлення: Тестуйте iperf3 в обох напрямках. Перевірте CPU і qdisc з обох боків. Підтвердіть таблиці маршрутизації і policy routing.

4) Симптом: VPN працює до збільшення трафіку, потім затримка вибухає

Корінна причина: Bufferbloat або перевантажений uplink без шейпінгу/AQM.
Виправлення: Впровадьте fq_codel/cake і шейпінг на справжньому вузькому місці (зазвичай вихід WAN). Повторіть тест ping під навантаженням.

5) Симптом: «Ми включили QoS і тепер VPN повільніший»

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

6) Симптом: OpenVPN дуже погано працює на швидких лінках

Корінна причина: Userspace overhead і обмеження однопотоковості.
Виправлення: Розгляньте OpenVPN DCO або міграцію на WireGuard/IPsec для великої пропускної здатності. Якщо застрягли — переконайтеся в UDP-режимі, налаштуйте MTU/MSS і прив’яжіть процеси до швидших ядер.

7) Симптом: Пропускна здатність IPsec впала після вмикання NAT на шляху тунелю

Корінна причина: Оффлоад вимкнено або невідповідність політик; NAT примушує до повільного шляху.
Виправлення: Перепроєктуйте, щоб уникнути NAT через тунель коли можливо. Якщо потрібно — переконайтесь, що апарат/драйвер підтримує це; інакше прийміть знижену пропускну здатність або апгрейд.

8) Симптом: Тести швидкості сильно варіюють залежно від часу доби

Корінна причина: Пересічне завантаження апстріму, шейпінг ISP або насичення загального середовища; VPN просто робить це очевиднішим.
Виправлення: Встановіть базові показники, вимірюйте поза VPN, і шейпіть трафік щоб зменшити втрати. Якщо проблема у ISP — ескалюйте з доказами.

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

Чекліст A: Послідовність «припиніть гадати»

Запустіть iperf3 через VPN: 1 потік і 4 потоки, в обох напрямках.
Перевірте завантаження по ядрам і переривання під час тесту.
DF ping для знаходження ефективного MTU через тунель.
Переконайтесь, що ICMP frag-needed не блокується; підтвердіть, що лічильники MSS clamp інкрементуються, якщо використовуєте.
Тест ping під навантаженням, щоб виявити bufferbloat.
Перевірте дропи на відповідних інтерфейсах (WAN і тунель).

Чекліст B: Дерево рішень для інцидентної сесії

Якщо ядро CPU зафіксоване: підтвердіть тип VPN; перейдіть на kernel/offload або апгрейдніть хардвер; припиніть підлаштовувати MTU поки не зможете шифрувати на швидкості.
Якщо multi-stream допомагає значно: шукайте MTU/PMTUD та втрати/чергування; впровадьте AQM і шейпінг перед тим, як чіпати крипто.
Якщо DF ping не проходить при несподівано малих розмірах: виправте MTU та ICMP; клампіть MSS; повторіть тест.
Якщо затримка стрибає під навантаженням: впровадьте fq_codel/cake; шейпіть на вузькому місці; повторіть тест.
Якщо продуктивність змінилася після вмикання фічі: підтвердіть статус оффлоаду/fast path; відкатіть фічу і повертайте її селективно.

Чекліст C: Що документувати, щоб не вчитись заново наступного кварталу

Базові результати iperf3 (1 vs 4 потоки, обидва напрямки) і умови тесту.
Ефективний MTU через тунель і налаштований MTU інтерфейсу.
Чи використовується MSS clamping, де і чому (PMTUD надійний чи ні).
Статус оффлоаду/акселерації і які фічі його вимикають.
Налаштування чергування/шейпінгу і обґрунтування вибраних лімітів.

Питання та відповіді

1) Чому мій VPN повільний, коли тест ISP показує швидко?

ISP-тести часто використовують кілька паралельних потоків і можуть запускатись до найближчих серверів. Ваш VPN-трафік може бути однопотоковим,
мати більший RTT і бути обмеженим crypto кінців або MTU-проблемами. Тестуйте iperf3 через VPN і порівнюйте 1 vs 4 потоки.

2) Як зрозуміти, це CPU/crypto чи MTU?

CPU/crypto вузьке місце зазвичай демонструє жорстку стелю пропускної здатності і зафіксоване ядро під навантаженням.
MTU/PMTUD проблеми показують зависання, ретрансміти і великий приріст при клампінгу MSS або зниженні MTU; багато потоків часто допомагають.

3) Чи варто просто перейти на WireGuard?

Якщо ви застрягли на однопотоковому userspace VPN і вам потрібно сотні Мбіт/с чи більше, перехід часто допомагає.
Але не використовуйте це як заміну діагностики MTU та чергування; WireGuard теж може бути повільним, якщо шлях відкидає пакети або є сильний bufferbloat.

4) Чи завжди потрібен MSS clamping?

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

5) Яке значення MSS слід встановлювати?

Краще використовувати --clamp-mss-to-pmtu де доступно; воно адаптується до MTU інтерфейсу.
Якщо доводиться встановлювати фіксоване MSS — вирахуйте його з ефективного path MTU і стандартних заголовків (зазвичай MTU мінус 40 для IPv4 TCP-заголовків, для IPv6 більше).
Спочатку виміряйте; вгадування тут породжує нові проблеми.

6) Чому пінг виглядає нормально, а передача файлів повільна?

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

7) Чи може логування фаєрвола справді сповільнити VPN?

Так. Логування кожного пакета додає CPU і I/O навантаження, і може вимкнути fast-path/offload на деяких платформах.
Логируйте потоки або вибіркові події замість кожного пакета на високо-чергових шляхах.

8) Яка найпоширеніша «безпекова» зміна, що ламає пропуск VPN?

Блокування ICMP destination-unreachable/time-exceeded. Це ламає PMTUD і перетворює MTU-проблеми на невидимі втрати і шторм ретрансмітів.
Дозвольте потрібні типи ICMP; безпека може залишатись суворою, не саботуючи протоколи.

9) Чому кілька TCP-потоків «вирішують» мою пропускну здатність?

Кілька потоків ховають втрати/чергування/MTU-проблеми, дозволяючи хоча б частині потоків рухатись, поки інші відступають.
Це діагностичний підказ — не справжнє рішення. Виправляйте дропи, PMTUD і bufferbloat замість цього.

10) Як пояснити це менеджменту без враження відмазки?

Покажіть два графіки: пропускна здатність vs завантаження ядра CPU, і пінг під навантаженням. Додайте результати iperf3 1-потік vs 4-потоки.
Це докази, де знаходиться вузьке місце і яка зміна його вирішить.

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

Діагностуйте повільність VPN як будь-яку іншу продукційну проблему продуктивності: вимірюйте, ізолюйте, потім міняйте одну змінну.
Не починайте з велосипедних суперечок про шифри. Почніть зі швидкого плану: iperf3 (1 vs 4 потоки), per-core CPU, DF MTU-тести, MSS/ICMP-перевірка,
і пінг під навантаженням, щоб виявити bufferbloat.

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

Запустіть iperf3 через VPN в обох напрямках з 1 і 4 потоками; зафіксуйте числа.
Під час тесту зніміть завантаження по ядрам і розподіл переривань; доведіть або виключіть обмеження обчислень кінців.
Виміряйте реальний path MTU за допомогою DF ping; вирівняйте MTU тунелю і застосуйте MSS clamping, якщо PMTUD ненадійний.
Перевірте дропи і сплески затримки під навантаженням; виправте керування чергами і шейпінг на вузькому місці.
Якщо підтверджено обмеження крипто datapath — змініть архітектуру (kernel/offload/DCO) або хардвер. Все інше — театр.

Схожі статті

OpenVPN: Налаштуйте правильно (і чому він часто повільніший за WireGuard)