OpenVPN: чому він здається повільним (і налаштування, що роблять його швидким)

February 11, 2026 • February 11, 2026 • Читання: 5 хв • Views: 3

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

Декотра повільність VPN — реальна; дещо — оптична ілюзія; більшість — самостворена. Ви вмикаєте OpenVPN, результати тесту швидкості падають з «добре» до «навіщо я плачу за оптоволокно», і раптом кожен вважає себе мережевим інженером-аматором.

OpenVPN може передавати серйозний трафік. Він також може непомітно зіпсувати усе через один невідповідний MTU, TCP-over-TCP провал або CPU, що завантажений шифруванням у єдиному потокі. Давайте діагностувати по-дорослому: знайти вузьке місце, підтвердити його командами, а потім налаштовувати лише те, що можна обґрунтувати.

Що насправді означає «повільно» в OpenVPN

«Повільно» — це суміш різних явищ. Потрібно назвати проблему, перш ніж чіпати налаштування:

Низька пропускна здатність: великі завантаження повільні, резервні копії тайм-аутяться, артефакти CI передаються вічно.
Висока затримка: SSH відчувається «липким», RDP підвисає, VoIP втрачає слова.
Джиттер: наче все добре, поки раптом не ні; інтерактивні навантаження відчуваються «примарними».
Нестабільність з’єднання: петлі перепідключень, інтенсивні TLS-переговори, раптові зависання.

Продуктивність OpenVPN — це не один регулятор. Це конвеєр: шифрування в user-space + тунелювання в ядрі + маршрутизація/NAT + реальна мережа. Будь-яка частина може стати обмежувальною. Тому починаємо з швидкої сортировки, потім заглиблюємося.

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

По-перше: визначте, чи обмежує CPU, чи мережа

Перевірте завантаження CPU на сервері під час передачі. Якщо один ядро завантажене на 100%, швидше за все ви обмежені шифруванням/запуском в user-space.
Перевірте якість каналу (втрати, ретрансміти, проблеми MTU). Якщо бачите фрагментацію або ретрансміти, ймовірно проблема в маршруті/MTU.
Перевірте вибір протоколу. TCP-over-TCP — класичний сценарій «працює в тесті, падає в продакшені».

По-друге: підтвердьте коректність MTU/MSS

Шукайте ICMP «Fragmentation needed» чорні діри.
Підтвердіть, що фрагментація не відбувається всередині тунелю.
Встановіть mssfix/tun-mtu консервативно та перевірте за допомогою захоплення пакетів.

По-третє: перевірте буфери, черги та планування

Сокетні буфери та дисципліни черг в ядрі.
Опції OpenVPN, як-от sndbuf/rcvbuf, та системні ліміти на зразок net.core.rmem_max.
Поведінка черги TUN/TAP та multi-queue там, де застосовно.

Якщо ви робите тільки одну річ: підтвердіть вузьке місце вимірами. Налаштування без вимірювань — це шлях зробити своє майбутнє несолодким.

Як OpenVPN рухає пакети (і де втрачає продуктивність)

OpenVPN переважно працює в user-space. Це і його сила, і його плата. Пакети проходять так:

Додаток генерує трафік (TCP/UDP).
Ядро направляє його в інтерфейс TUN.
OpenVPN читає з TUN у user-space.
OpenVPN шифрує/автентифікує, додає оверхед (хедери, IV, теги).
OpenVPN записує інкапсульовані пакети в UDP або TCP сокет.
Інтернет робить те, що інтернет робить: NAT, втрати, перемішування, дивні MTU.
На іншому боці: процес відбувається у зворотному порядку.

Наслідки для продуктивності передбачувані:

Перемикання контексту: цикли читання/запису в user-space додають оверхед.
Гарячі точки однопоточності: один процес може стати пляшковим горлечком.
Вартість криптографії: залежить від шифру, можливостей CPU та розподілу розмірів пакетів.
Оверхед інкапсуляції: зменшує ефективний MTU і може викликати фрагментацію.
Поведіка TCP: якщо ви тунелюєте TCP всередині TCP, керування заторами стає… філософією.

Цитата, яку варто мати в кожному керівництві з продуктивності VPN: парафразована ідея від Jim Gray: «Виміряй, потім вирішуй; припущення про продуктивність зазвичай помилкові.» Це суть підходу.

Жарт №1: Налаштовувати OpenVPN без метрик — це як оптимізувати базу даних, просто дивлячись на неї сильніше. База даних не поважає вашу впевненість.

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

Перші публічні релізи OpenVPN були на початку 2000-х, його робили портативним і правильним у часи, коли «VPN-апарат» часто означав «таємнича коробка».
Дизайн в user-space був свідомим вибором: це уникало проблем з модулями ядра на різних ОС і спрощувало аудит, за рахунок додаткових копій і перемикань контексту.
Абстракції TUN/TAP прийшли з історії Unix-мереж; TUN (L3) зазвичай швидший і простіший за TAP (L2), якщо вам не потрібен Ethernet-бриджинг.
Режим UDP став рекомендованим за замовчуванням, бо режим TCP посилює латентність і патології ретрансляцій при втратах.
«TLS auth» / «tls-crypt» еволюціонували частково як відповідь на фоновий шум в інтернеті та активні сканування.
AES-NI змінило правила гри для пропускної здатності OpenVPN на x86: шифрування перестало бути обов’язково вузьким місцем — часто обробка пакетів була повільніше.
ChaCha20-Poly1305 здобув популярність бо показує хорошу продуктивність на пристроях без апаратного прискорення AES (багато невеликих роутерів і деякі віртуалки).
Відвантаження каналу даних не є основною історією OpenVPN, як для деяких VPN в ядрі; OpenVPN виграє в зрілості й гнучкості, а не в нуль-копі оптимізаціях.
Багато звітів «OpenVPN повільний» насправді пов’язані з MTU чорними дірами, створеними мережами, які блокують ICMP, необхідний для Path MTU Discovery.

Типові вузькі місця: CPU, MTU, буфери, маршрутизація та погані налаштування за замовчуванням

1) Обмеження CPU шифруванням (або, частіше, churn пакетів у user-space)

Якщо один процес OpenVPN виконує всю роботу, можна наситити одне ядро задовго до насичення 1 Гбіт лінку — особливо при багатьох дрібних пакетах (інтерактивний трафік, чат, API, DNS, RDP, метадані SMB). Крипто дорогий, але так само дорого «просто переміщати пакети» в user-space.

Що погіршує ситуацію:

Запуск OpenVPN у маленькій віртуалці з обмеженим плануванням CPU.
Використання шифру, що повільний на вашому CPU (або відсутнє апаратне прискорення).
Високий пакетний рейт: пропускна здатність може виглядати посередньою, навіть якщо Mbps не велике.

2) Невідповідність MTU/MSS і фрагментація

Інкапсуляція «краде» байти з корисного навантаження. Якщо внутрішній трафік очікує MTU 1500, а ваш тунельний шлях може переносити, скажімо, 1472 байти (або менше), з’являється фрагментація. Фрагментація може бути просто неефективною або катастрофічною, коли ICMP блокується і PMTUD ламається.

Класичний сценарій:

Малі запити працюють.
Великі завантаження зависають, особливо по TCP.
Деякі сайти працюють, інші загадково зависають.

3) Розвал TCP-over-TCP

Тунелювання TCP через OpenVPN поверх TCP — це еквівалент того, як накласти два контролери заторів і попросити їх координуватися на інтуїції. При втратах обидва рівні роблять ретрансміти й відступають, і затримка зростає. У лабораторії може «працювати», а в реальному світі — колапсувати.

4) Буфери і черги (aka «затримка — це проблема зберігання для пакетів»)

Буфери потрібні, щоб згладжувати сплески. Занадто малі — втрачаєте пакети. Занадто великі — отримуєте bufferbloat і додаєте затримку. OpenVPN має власні сокетні буфери, а ОС має ліміти. Потрібно розумне масштабування і адекватні дисципліни черг, особливо для широкосмугових/довгих BDP мереж.

5) Помилки маршрутизації/NAT і асиметричні шляхи

OpenVPN може бути швидким тоді, коли ваша маршрутизація повільна. Якщо трафік йде «через петлю» через файрвол, або правила NAT змушують conntrack працювати інтенсивно, ви звинуватите VPN, бо це видима зміна. Не робіть цього. Слідкуйте за пакетами.

6) Тиха вбивця: DNS і вирішення імен

Іноді тунель в порядку, але DNS через тунель — ні. Затримки, повторні спроби, неправильно налаштований split-DNS або резолвери, які не повинні використовуватись. Користувачі кажуть «VPN повільний», коли насправді «кожна сторінка чекає на DNS».

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

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

Завдання 1: Підтвердьте режим OpenVPN, шифр і чи використовується UDP

cr0x@server:~$ sudo ss -lntup | awk 'NR==1 || /openvpn/'
Netid State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp   UNCONN 0      0      0.0.0.0:1194      0.0.0.0:*     users:(("openvpn",pid=1324,fd=6))

Значення: Ви слухаєте на UDP/1194. Добрий стандарт для продуктивності.

Рішення: Якщо тут бачите tcp, будьте підозрілі. Використовуйте TCP лише якщо дійсно потрібно проходити через суворі мережі.

Завдання 2: Перевірте завантаження CPU сервера під час передачі

cr0x@server:~$ top -b -n 1 -o %CPU | head -n 12
top - 10:21:33 up 31 days,  4:02,  1 user,  load average: 1.92, 1.41, 1.22
Tasks: 162 total,   1 running, 161 sleeping,   0 stopped,   0 zombie
%Cpu(s):  8.2 us,  1.0 sy,  0.0 ni, 90.5 id,  0.2 wa,  0.0 hi,  0.1 si,  0.0 st
MiB Mem :  7986.4 total,  2141.2 free,  1680.0 used,  4165.2 buff/cache
MiB Swap:  2048.0 total,  2048.0 free,     0.0 used.  5789.1 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1324 nobody    20   0  178248  18624   7512 R  98.7   0.2  52:14.11 openvpn

Значення: OpenVPN займає ядро. Ймовірно, ви обмежені CPU/user-space.

Рішення: Розгляньте швидші шифри для вашого CPU, перевірте AES-NI, зменшіть проблеми з рейтами пакетів або масштабуйтесь (більше інстансів, більше тунелів або інша VPN-технологія, якщо потрібні мультигігабіти).

Завдання 3: Перевірте апаратні можливості крипто (AES-NI) на x86

cr0x@server:~$ lscpu | egrep 'Model name|Flags' | head -n 2
Model name:                           Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
Flags:                                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr ... aes ...

Значення: прапорець aes присутній; ймовірно доступне апаратне прискорення AES.

Рішення: Віддавайте перевагу AES-GCM на CPU з AES-NI. Якщо відсутнє (часто на маленьких ARM-пристроях), розгляньте ChaCha20-Poly1305 (якщо збірка OpenVPN його підтримує).

Завдання 4: Виявлення втрат пакетів і ретрансмітів на фізичному інтерфейсі

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
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    9812345678 8123456      0   12890       0       0
    TX:  bytes packets errors dropped carrier collsns
    8765432109 7345678      0    4321       0       0

Значення: Втрати на RX/TX можуть вказувати на перевантаження, проблеми драйвера або тиск у буферах.

Рішення: Якщо втрати ростуть під навантаженням VPN, налаштуйте дисципліни черг, акуратно збільшіть буфери або виправте налаштування NIC/virtio. Втрати — не «норма». Це підказка.

Завдання 5: Перевірте помилки прийому UDP на рівні ядра

cr0x@server:~$ netstat -su | egrep -i 'packet receive errors|receive buffer errors|ignored|InDatagrams'
    1892345 packets received
    0 packet receive errors
    0 receive buffer errors
    1892345 InDatagrams

Значення: Якщо receive buffer errors інкрементується, ядро відкидає UDP через замалі буфери або CPU не встигає.

Рішення: Збільште системні ліміти сокетних буферів і розгляньте опції OpenVPN rcvbuf/sndbuf з push (але не ставте їх «в нескінченність» сліпо).

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

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

cr0x@server:~$ iperf3 -c 10.8.0.1 -P 4 -t 15
Connecting to host 10.8.0.1, port 5201
[SUM]   0.00-15.00  sec   620 MBytes   347 Mbits/sec  sender
[SUM]   0.00-15.00  sec   616 MBytes   344 Mbits/sec  receiver

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

Рішення: Якщо один потік повільний, а кілька — нормальні, дивіться на TCP-вікна/латентність і контроль заторів, а не на сирий канал.

Завдання 7: Виявлення MTU чорної діри за допомогою ping з «не фрагментувати»

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

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

Значення: Ваш шлях MTU менший за 1500 байт очікування. Через тунель він буде ще меншим.

Рішення: Встановіть tun-mtu і mssfix, щоб уникнути фрагментації. Не вгадуйте; знайдіть найбільший робочий розмір по шляху тунелю.

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

cr0x@server:~$ ip link show dev tun0
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 500
    link/none

Значення: MTU на tun0 — 1500. Це може бути неправильним залежно від інкапсуляції і шляху.

Рішення: Якщо бачите фрагментацію або зависання, зменшіть tun-mtu (і зажміть MSS). Поширене «здорове» початкове значення — 1500 мінус оверхед; багато операторів зупиняються в районі 1400–1450 залежно від середовища.

Завдання 9: Спостерігайте реальну фрагментацію за допомогою tcpdump

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 1194 -vv -c 10
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:25:11.123456 IP (tos 0x0, ttl 64, id 54321, offset 0, flags [+], proto UDP (17), length 1514)
    203.0.113.10.1194 > 198.51.100.20.51123: UDP, length 1486
10:25:11.123457 IP (tos 0x0, ttl 64, id 54321, offset 1480, flags [none], proto UDP (17), length 54)
    203.0.113.10.1194 > 198.51.100.20.51123: UDP, length 26

Значення: flags [+] і offsets показують фрагментацію.

Рішення: Зменшіть MTU тунелю і застосуйте MSS clamping. Фрагментація — це податок; фрагментація, що блокується, — це відмова в обслуговуванні.

Завдання 10: Перевірте TCP ретрансміти (симптом втрат або проблем з MTU)

cr0x@server:~$ ss -ti dst 10.8.0.2 | head -n 30
ESTAB 0 0 10.8.0.1:5201 10.8.0.2:51044
	 cubic wscale:7,7 rto:204 rtt:45.2/3.1 ato:40 mss:1360 pmtu:1400 rcvmss:1360 advmss:1360 cwnd:26 bytes_sent:12345678 bytes_retrans:23456 bytes_acked:12320000

Значення: bytes_retrans що зростає вказує на ретрансміти; зверніть увагу також на pmtu і mss.

Рішення: Якщо ретрансміти різко зростають, спочатку виправляйте втрати (Wi‑Fi, LTE, перевантажені лінії), потім MTU. Не «оптимізуйте» шифри, поки шлях палає.

Завдання 11: Підтвердіть маршрутизацію: чи дійсно трафік йде через тунель?

cr0x@server:~$ ip route get 8.8.8.8
8.8.8.8 via 10.8.0.5 dev tun0 src 10.8.0.1 uid 0
    cache

Значення: Ціль маршрутується через tun0. Добре.

Рішення: Якщо трафік виходить через eth0, коли ви очікуєте tun0, є проблеми політики маршрутизації або push-route — користувачі можуть петляти або витікати трафік ненавмисно.

Завдання 12: Підтвердіть NAT/форвардинг для site-to-site або «push redirect-gateway» налаштувань

cr0x@server:~$ sudo sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    iifname "tun0" oifname "eth0" accept
    iifname "eth0" oifname "tun0" ct state established,related accept
  }
}
table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "eth0" ip saddr 10.8.0.0/24 masquerade
  }
}

Значення: Форвардинг увімкнений і NAT налаштований для клієнтів тунелю, що виходять через eth0.

Рішення: Якщо форвардинг вимкнено або правила відкидають трафік, ви отримаєте «VPN підключається, але інтернет не працює» або дивні затримки через асиметрію шляхів.

Завдання 13: Перевірте максимальні розміри сокетних буферів (системні ліміти)

cr0x@server:~$ sysctl net.core.rmem_max net.core.wmem_max net.ipv4.udp_rmem_min net.ipv4.udp_wmem_min
net.core.rmem_max = 212992
net.core.wmem_max = 212992
net.ipv4.udp_rmem_min = 4096
net.ipv4.udp_wmem_min = 4096

Значення: Значення за замовчуванням консервативні. На лінках з великим BDP це може обмежувати пропускну здатність або викликати втрати.

Рішення: Збільшуйте їх обережно (і відстежуйте). Якщо ви піднімаєте буфери OpenVPN, але максимум ОС малий, ваші налаштування не застосуються.

Завдання 14: Перевірте дисципліну черг (контроль bufferbloat)

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

Значення: fq_codel загалом дружній до затримки під навантаженням.

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

Налаштування, що дають швидкість (і чого уникати)

Обирайте UDP, якщо немає реальної причини інакше

UDP не «швидший через те, що це UDP». Він швидший тому, що уникає TCP-over-TCP колапсу та дає внутрішнім TCP-сесіям робити свою роботу без обгортки в додатковий рівень надійності.

Робіть: proto udp для більшості розгортань.

Уникайте: proto tcp як дефолт. Використовуйте його для captive portal-ів і зачинених мереж, приймаючи втрачену в продуктивності ціну.

Використовуйте TUN (маршрутний) якщо вам справді не потрібен TAP (бриджинг)

TAP тягне за собою Ethernet-семантику: широкомовлення, ARP-шум і більші кадри. Іноді це потрібно (спадкові додатки, L2 суміжність). Частіше — ні.

Робіть: dev tun для site-to-site і клієнтських VPN.

Уникайте: dev tap коли єдиним аргументом є «так написано в блозі».

Правильно встановіть MTU/MSS і потім не чіпайте їх

Якщо запам’ятати одне правило налаштування: уникати фрагментації всередині тунелю. Використовуйте mssfix щоб зажати TCP MSS і запобігти відправці сегментів, що перевищують ефективний MTU шляху. Використовуйте tun-mtu для налаштування MTU тунелю при потребі.

Типові серверні фрагменти конфігурації (ілюстративно, не універсально):

mssfix: обмежує TCP MSS; корисно для уникнення проблем з PMTUD.
tun-mtu: встановлює MTU тунелю; допомагає забезпечити розміри без фрагментації.
fragment: загалом уникайте; фрагментація — це зазвичай тимчасовий хак для зламаного шляху і може погано взаємодіяти з сучасними мережами.

Обирайте сучасні шифри, зважаючи на ваш CPU

На x86 з AES-NI, AES-128-GCM часто — оптимальний компроміс. AES-256-GCM теж може бути добрим, але не платіть додатковими циклами дарма. На пристроях без апаратного прискорення AES ChaCha20-Poly1305 може працювати краще.

Також: договірність по шифру і сумісність важливі. «Швидкий» шифр, який ви не зможете використовувати скрізь — ризик у майбутньому.

Не збільшуйте буфери бездумно

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

Keepalive і renegotiation: не створюйте самостійно джиттер

Перепереговори і агресивні keepalive можуть спричиняти періодичні паузи. Встановлюйте keepalive відповідно до таймаутів NAT і не перегенеруйтесь TLS без причини. Якщо бачите періодичні «зависання на секунду», перевірте інтервали renegotiation і сплески CPU.

Масштабуйте, коли досягаєте межі одного процесу

OpenVPN добре обслуговує багато клієнтів, але існують реальні обмеження на процес залежно від пакетного рейтa, крипто і CPU. Якщо ви прагнете великої сумарної пропускної здатності, розгляньте:

Кілька інстансів OpenVPN, прив’язаних до різних портів/IP.
Розподіл клієнтів між інстансами.
Більше CPU і швидші ядра (не тільки більше RAM).
Оцінку, чи краще підійде VPN у ядрі, якщо прагнете мультигігабітної пропускної здатності на тунель.

Жарт №2: Якщо ви встановили всі буфери по 16 МБ, ви не налаштували VPN. Ви побудували музей затримок і берете плату за вхід.

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

Міні-історія 1: Інцидент через неправильне припущення

Середня компанія розгорнула OpenVPN для підключення віддалених співробітників до внутрішніх інструментів. Пілотна група була задоволена. Розгортання пішло глобально. Потім черга тикетів почала виглядати як DDoS, хіба що нападниками були співробітники.

Симптоми були непослідовні: деякі користувачі могли завантажувати внутрішні веб-додатки нормально, але завантаження великих файлів з артефактного сховища зависало. Інші повідомляли, що лише певні сайти не працюють, і збої змінювалися в залежності від готельного Wi‑Fi. Звісно, всі звинуватили OpenVPN-сервер, бо це була нова річ.

Неправильне припущення: «MTU просто працюватиме, бо Ethernet — 1500». Мережева команда мала шлях з меншим MTU посередині (фрагмент провайдера і VPN-в-VPN хоп), і ICMP «fragmentation needed» фільтрувався. Path MTU Discovery не міг виконувати роботу. Малі пакети проходили; великі вмирали мовчки.

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

Міні-історія 2: Оптимізація, що відкотилася

Інша організація хотіла вищу пропускну здатність для нічної синхронізації даних. Хтось прочитав, що «більші буфери поліпшують продуктивність» і накрутив OpenVPN sndbuf/rcvbuf на максимум, плюс збільшив ядрові максимуми. Пропускна здатність зросла в синтетичних тестах. Святкування почалося.

Потім почалися скарги: якість VoIP впала, термінальні сесії відчували затримки, моніторинг почав флапати. Нічого не «впало», але все стало гірше. Це та деградація, яка змушує сумніватися у виборі кар’єри.

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

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

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

Регульована компанія використовувала OpenVPN для доступу постачальників до сегментованого середовища. Нічого героїчного: суворі правила файрвола, явні маршрути і вікна змін, що могли «законсервувати» баг репорт.

Команда робила одну нудну річ постійно: вони вели базовий runbook продуктивності з повторюваними тестами — iperf3 через тунель, MTU-проби, знімки CPU і захоплення пакетів для контрольного та дата-каналу. Кожен запит на зміну містив «до» і «після» результати.

Одного місяця скарги на продуктивність зросли після оновлення політик файрвола. Оскільки у них були базові показники, вони швидко довели, що VPN-сервер не був обмежувачем: CPU в нормі, без фрагментації, стабільна пропускна здатність на сервері. Захоплення пакетів показало збільшення ретрансмітів і позачергову доставку, що починалася на периметрі.

Виявилось, що нова політика інспекції на файрволі погано взаємодіяла з UDP-потоками на масштабі. Вони відкотили ту політику і відновили нормальну продуктивність. Без базових вимірів звинувачення впали б на OpenVPN (і на людей, що його підтримують), а виправлення зайняло б тижні помилкового тонування.

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

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

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

Виправлення: Встановіть mssfix і, можливо, зменшіть tun-mtu; перевірте за допомогою ping -M do та tcpdump на предмет фрагментації.
Симптом: «Пропускна здатність принижена, підозріло низька; CPU виглядає завантаженим.»

Корінна причина: OpenVPN процес обмежений CPU; повільний шифр на цьому CPU; високий оверхед на пакет.

Виправлення: Віддавайте перевагу AES-GCM на CPU з AES-NI або ChaCha20 на пристроях без AES; виділіть швидші ядра; масштабуйтесь інстансами.
Симптом: «Працює в офісі, жахливо на мобільному або Wi‑Fi.»

Корінна причина: Втрати пакетів і перемішування; TCP-over-TCP якщо OpenVPN працює по TCP; або агресивний MTU.

Виправлення: Використовуйте транспорт UDP; зажміть MSS; розгляньте консервативний MTU; переконайтесь, що keepalive підходить для NAT.
Симптом: «Тести швидкості показують високу затримку під навантаженням; дзвінки спотворюються під час великих передач.»

Корінна причина: Bufferbloat через надмірні буфери або погану qdisc.

Виправлення: Використовуйте fq_codel/cake де можливо; тримайте буфери в межах; обмежуйте масові потоки.
Симптом: «Тільки DNS повільний; все інше підозріло затримується при завантаженні сторінки.»

Корінна причина: Резолвери через тунель повільні/недоступні; split DNS налаштований неправильно.

Виправлення: Перевірте доступність/латентність резолверів; пуште правильні DNS; уникайте петляння до далекого резолвера.
Симптом: «Пропускна здатність VPN нормальна для деяких клієнтів, жахлива для інших.»

Корінна причина: Проблеми на клієнтській стороні: MTU/Wi‑Fi/LTE; різна поведінка NAT провайдерів; різні маршрути до серверних POP.

Виправлення: Тестуйте MTU і втрати для кожного клієнта; віддавайте перевагу найближчим точкам присутності; стандартизовуйте конфіги клієнтів; вимірюйте шлях за допомогою mtr.
Симптом: «Після включення стиснення швидкість погіршилася, і CPU нагрівся.»

Корінна причина: Стиснення на вже стисненому трафіку; проблеми безпеки; додаткове навантаження на CPU в user-space.

Виправлення: Вимкніть стиснення для загального інтернет-трафіку; використовуйте його лише в вузьких, контрольованих випадках з виміреними перевагами.
Симптом: «Перервні зависання кожні N хвилин.»

Корінна причина: Події повторного ключування/переговорів спричиняють сплески CPU; таймаути NAT викликають короткі збої; watchdog перезапускає сервіси.

Виправлення: Перевірте логи на предмет renegotiation; відкоригуйте keepalive; переконайтесь, що системні ресурси стабільні; не ставте агресивні інтервали rekey без потреби.

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

Покроково: зробіть OpenVPN швидким, не зробивши його крихким

Встановіть базову метрику: запустіть iperf3 через тунель (1 потік і кілька потоків), зафіксуйте RTT і ретрансміти.
Підтвердьте транспорт: використовуйте UDP, якщо немає суворого обмеження на TCP.
Перевірте CPU: якщо одне ядро зайняте, виправляйте вибір шифру/виділення CPU/масштабування перш ніж чіпати MTU.
Виправте MTU/MSS: пробуйте MTU; встановіть mssfix; налаштуйте tun-mtu за потреби; підтвердіть, що фрагментація зникла.
Перевірте втрати ядра: використовуйте ip -s link і netstat -su; якщо є втрати — вирішіть питання буферів/CPU/NIC.
Підтвердіть маршрути: переконайтесь, що маршрути як очікується; уникайте петлянь; перевірте симетрію повернення шляхів.
Контролюйте черги: перевірте qdisc; уникайте bufferbloat; якщо потрібно пріоритизувати — робіть це явно.
Повторно тестуйте: повторіть базові тести і порівняйте. Якщо ви не вимірювали — ви не полагодили.
Документуйте «відомо гарну» конфігурацію: включіть припущення по MTU, вибір шифрів і використані системні sysctl.
Моніторьте постійно: CPU, втрата пакетів і час життя тунелю мають бути на дашбордах, а не в чиїйсь голові.

Короткий чекліст: що робити і чого уникати при налаштуванні продуктивності

Робіть використовуйте UDP транспорт для продуктивності.
Робіть зажміть MSS, щоб уникнути несподіваної фрагментації.
Робіть перевірте AES-NI / можливості CPU і підбирайте шифри відповідно.
Робіть використовуйте справедливе чергування на WAN інтерфейсах, де можливо.
Не робіть використовуйте TCP-over-TCP, хіба що вам подобається дебаг ретрансмітів як тренування.
Не робіть «вирішуйте» пропускну здатність, роздуваючи буфери до затримки як риса характеру.
Не робіть вмикайте стиснення як універсальну кнопку швидкості.
Не робіть налаштовуйте в темряві — логируйте, вимірюйте, а потім змінюйте по одному параметру.

FAQ

1) Чому OpenVPN здається повільнішим за мій «чистий» інтернет-з’єднання?

Тому що ви додали оверхед шифрування, додаткові заголовки (менший ефективний MTU) і обробку пакетів у user-space. Будь-який з цих факторів може стати обмежувачем.

2) Чи завжди UDP швидший за TCP для OpenVPN?

Не завжди, але зазвичай більш стійкий і продуктивніший при втратах. TCP-transport іноді необхідний для обмежених мереж, але це компроміс продуктивності.

3) Яка найпоширеніша у реальному світі причина «OpenVPN повільний»?

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

4) Чи варто вмикати стиснення, щоб зробити OpenVPN швидше?

Загалом ні. Більшість сучасного трафіку вже стиснутий (HTTPS, відео, завантаження). Стиснення спалює CPU і може створювати проблеми з безпекою. Використовуйте його тільки якщо довели користь для вашого специфічного набору трафіку.

5) Як зрозуміти, чи я обмежений CPU?

Під час передачі, якщо процес OpenVPN завантажує ядро і пропускна здатність не росте, ви обмежені CPU/user-space. Підтвердіть за допомогою top і подивіться, чи змінюється пропускна здатність після зміни шифрів або виділення CPU.

6) Який MTU мені встановити для OpenVPN?

Універсального числа немає. Почніть з виміру path MTU, а потім встановіть mssfix щоб запобігти TCP сегментам, що перевищують ефективний MTU. Багато середовищ фіксуються в діапазоні 1400–1450 для тунельного MTU, але вимірюйте.

7) Чому кілька iperf3 потоків підвищують пропускну здатність?

Один потік може бути обмежений ростом TCP вікна і відновленням після втрат. Декілька потоків краще використовують канал на шляхах з великою затримкою. Це також підказка: якщо паралельні потоки допомагають, проблема не в сирому bandwidth.

8) Чи може OpenVPN робити гігабітні швидкості?

Так, у деяких налаштуваннях з потужними CPU та хорошим тюнінгом. Але важливий пакетний рейт: багато дрібних пакетів можуть обмежити вас раніше, ніж Mbps. Після певної межі масштабування інстансів або зміна технології VPN може бути чистішим рішенням.

9) Чи варто використовувати TAP для «кращої продуктивності»?

Ні. TAP потрібен для L2-вимог, а не для швидкості. Він часто додає оверхед через широкомовлення і ARP-шум. Використовуйте TUN, якщо вам не потрібна Ethernet-суміжність.

10) Чому в офісі все добре, а для віддалених користувачів погано?

Тому що інтернет — це не єдина мережа. Віддалі користувачі мають різні MTU, поведінку NAT, рівні втрат і маршрути. Вимірюйте з боку користувача і налаштовуйтеся на ворожі мережі.

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

Якщо OpenVPN здається повільним, не починайте з ритуального переглядання конфігів. Почніть з доказів.

Запустіть iperf3 через тунель (один і паралельні потоки). Зафіксуйте пропускну здатність і RTT.
Перевірте CPU під час тесту. Якщо ядро завантажене, вирішіть це спочатку.
Пропробуйте MTU і усуньте фрагментацію. Зажміть MSS. Підтвердіть за допомогою tcpdump.
Шукайте втрати і помилки буферів у статистиці ядра. Виправляйте черги і ліміти буферів розумно.
Повторно тестуйте і документуйте «відомо добру» конфігурацію, щоб майбутні інциденти мали менше невизначеностей.

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