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

Ментальна модель «швидкості VPN», яка справді допомагає

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

Рівень 1: Якість шляху (втрати, джиттер і bufferbloat)

VPN підсилюють посередні мережі. Якщо остання миля втрачає пакети, шифрування цього не виправить; навпаки, воно ускладнює діагностику.
Тунель також змінює розмір і темп пакета, що взаємодіє з буферами в побутових роутерах і мережах LTE.
Стрибки затримки відчуваються як «повільний VPN», навіть коли тести пропускної здатності в порядку.

Рівень 2: Накладні витрати інкапсуляції (MTU/MSS)

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

Рівень 3: Крипто та обробка пакетів

Тут OpenVPN проти WireGuard стає помітним. WireGuard у Linux працює в ядрі, тому гарячий шлях мінімальний.
Класичний OpenVPN здебільшого живе в userland. Userland не обов’язково повільний, але він платить додатково за контекст‑перемикання, копіювання пам’яті
та планування, особливо при високих швидкостях пакетів.

Рівень 4: Вибір транспорту (UDP vs TCP та пастка TCP-over-TCP)

UDP зазвичай правильний вибір для каналу даних VPN. TCP всередині TCP може створити петлю зворотного зв’язку, де обидва шари ретрансмісують,
обидва шари відступають, і продуктивність руйнується при втратах. Це не теорія; так ви отримуєте 2 Мбіт/с на гіга‑лінку.

Цікаві факти та історія (що пояснює сучасні компроміси)

• OpenVPN з’явився у 2001 році, побудований навколо TLS і гнучкого userland‑дизайну. Ця гнучкість пояснює, чому він працює майже всюди — але й чому він важчий.
• WireGuard почався в середині 2010‑х з навмисно невеликою кодовою базою і сучасними криптопримітивами, оптимізованими для простоти та аудиту.
• OpenVPN став «корпоративним стандартом» частково тому, що був раннім і добре проходив через NAT/фаєрволи, задовго до того, як «zero trust» з’явився у презентаціях.
• Крипто‑історія OpenVPN еволюціонувала від старіших режимів CBC і HMAC до AES‑GCM і сучасних значень за умовчанням, але старі конфіги ще довго лишаються в експлуатації.
• Довго тонке налаштування продуктивності OpenVPN зводилося до «вибери UDP і молись»; пізніші покращення, як ovpn-dco (Data Channel Offload), з’явилися, щоб зменшити накладні витрати userland.
• WireGuard використовує Noise‑handshakes і концепцію «cryptokey routing», що зменшує складність контрольної площини і уникає драм при повторних переговорів.
• Набір функцій OpenVPN величезний (плагіни автентифікації, pushed routes, хook‑скрипти, кілька методів автентифікації). Кожна функція — важіль, а важелі спричиняють помилки.
• У Linux важливі ядрові швидкі шляхи: можливість обробляти пакети без стрибків між ядром і userland часто є різницею між «нормально» і «чому одне ядро на 100%?»

Одна оперативна парафразована ідея від відомого надійника тут доречна: «простота — це передумова надійності.» — Джон Остерхаут (парафразована ідея)

Правильне налаштування OpenVPN: базова конфігурація, що припиняє самозавдані проблеми

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

Використовуйте dev tun і маршрутизацію IP‑підмереж. Містіння (tap) додає L2‑широковещання в тунель, збільшує галас
і робить усунення несправностей схожим на полювання за єнотами в технічному стелі.

Використовуйте UDP для каналу даних

Якщо ваше середовище не блокує UDP категорично — обирайте його. Режим TCP — для «я застряг у готельному Wi‑Fi порталі з 2009 року».
Якщо ви контролюєте обидва кінці, не використовуйте TCP за умовчанням. Він підведе вас при втратах.

Використовуйте сучасну криптографію з апаратним прискоренням

На типовому x86‑сервері AES‑GCM з AES‑NI швидкий. ChaCha20‑Poly1305 також хороший, особливо на пристроях без прискорення AES.
Не намагайтесь «вписатися в хитромудрі шифри для безпеки». Безпека включає доступність, і VPN, що повзе, спонукає користувачів його оминати.

Тримайте конфіг нудним

«Нудний» означає: мінімум плагінів, мінімум скриптів, мінімум автоматично натиснутих опцій, мінімум перекриттів для клієнтів.
Кожна зайва ручка — новий режим відмови, і в OpenVPN їх достатньо, щоб стати органом.

Сплануйте MTU та MSS заздалегідь

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

Логування та спостережуваність — частина налаштування

Якщо ви не можете відповісти «це CPU, MTU, втрата чи затори?» за п’ять хвилин, ви не налаштували production VPN.
Ви налаштували детективний роман.

Жарт №1: Конфіги OpenVPN схожі на кухонні шухляди — все працює, поки не треба знайти одну річ швидко.

Чому OpenVPN часто повільніший за WireGuard (без релігії)

Userland проти ядрового datapath

WireGuard у Linux працює в ядрі, тому пакети заходять в ядро, шифруються/дешифруються і йдуть далі з меншою кількістю переходів.
Класичний OpenVPN зазвичай читає пакети з TUN‑пристрою в userland, шифрує/дешифрує, потім записує назад.
Це означає більше переключень контексту і копіювань пам’яті. При низькій пропускній здатності ви можете не помітити різниці. При високих швидкостях пакетів — помітите.

Кількість пакетів важить більше, ніж смуга пропускання для CPU. Багато дрібних пакетів (VoIP, ігри, RPC, «балакучі» мікросервіси)
можуть вичерпати CPU‑ядро задовго до насичення каналу. Накладні витрати OpenVPN проявляються саме тут.

Складність протоколу і контрольна площина

OpenVPN побудований на TLS, підтримує повторні переговори, кілька механізмів автентифікації та багатий набір розширень.
Це потужність. Але й більше рухомих частин: більше станів, більше шляхів у коді і більше способів впасти на повільний шлях.
Модель WireGuard навмисно вужча.

Вибір шифрів та деталі реалізації

OpenVPN може бути дуже швидким з правильним шифром, але може й повільно працювати з невідповідним.
AES‑CBC + HMAC може бути прийнятним, але AES‑GCM зазвичай краще, а застарілі значення за умовчанням ще можуть ховатися у старих розгортаннях.
WireGuard стандартизує сучасні примітиви; вам не треба «обирати» з меню і випадково взяти неправильне.

Мелтдаун TCP‑over‑TCP — реальність

Якщо ви запускаєте OpenVPN поверх TCP і несете TCP‑трафік всередині нього, ви створили дві петлі керування заторами.
Втрати запускають ретрансляції на обох рівнях; затримка зростає; вікна зменшуються; пропускна здатність падає.
WireGuard — лише UDP; він уникнув цієї категорії проблем за дизайном.

Обробка MTU і штрафи за фрагментацію

І OpenVPN, і WireGuard страждають, якщо MTU виставлено неправильно. Але розгортання OpenVPN частіше успадковують старі налаштування як
фіксований MTU, зайва компресія (не робіть цього) і «передані» скрипти. Конфіги WireGuard, як правило, коротші і новіші,
отже менше історичних мін.

DCO змінює порівняння

OpenVPN з Data Channel Offload (ovpn-dco) переміщує канал даних ближче до ядра, суттєво зменшуючи накладні витрати.
Якщо вам потрібні корпоративні фічі OpenVPN, але хочеться продуктивності типу WireGuard, DCO — перше, що варто оцінити.
Не всі платформи підтримують його однаково, і операційна зрілість залежить від дистрибутива.

Жарт №2: Запуск TCP поверх TCP заради «надійності» — наче вдягати два дощовики і скаржитися, що не можете рухати руками.

Швидка діагностика: знайдіть вузьке місце за хвилини

Коли хтось каже «OpenVPN повільний», потрібен повторюваний порядок триажу. Не починайте з зміни шифрів.
Почніть із доведення, де саме живе час і втрати.

Спочатку: підтвердьте очевидне (транспорт, шлях, MTU)

1. Перевірте, чи використовуєте UDP. Якщо TCP — підозрюйте миттєво мелтдаун TCP‑over‑TCP.
2. Перевірте симптоми MTU/MSS. Якщо «деякі сайти зависають» або «великі завантаження стопоряться», підозрюйте MTU.
3. Перевірте втрати і джиттер. Якщо є втрата, пропускна здатність впаде навіть при ідеальному крипто.

По‑друге: підтвердьте, чи сервер обмежений CPU або частотою пакетів

1. Шукайте зафіксоване одне ядро. OpenVPN часто обмежується одним потоком, що обробляє крипто або I/O.
2. Виміряйте навантаження softirq і пропуски NIC. Якщо пакети падають до того, як OpenVPN їх побачить, налаштування OpenVPN косметичні.
3. Перевірте шифр і опції апаратного оффлоаду. Якщо ви використовуєте повільний шифр або відсутній DCO, ви це відчуєте.

По‑третє: перевірте маршрутизацію/NAT і чергування

1. Перевірте qdisc і bufferbloat. Неправильна дисципліна черг може додати велику затримку під навантаженням.
2. Підтвердьте правильність маршрутизації. Якщо трафік робить hairpin через фаєрвол або непотрібно перетинає AZ, ваша «проблема VPN» — це топологія.
3. Виміряйте пропускну здатність з тунелем і без нього. Потрібен базовий рівень, щоб не ганятися за міражами.

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

Ці завдання передбачають Linux‑сервер OpenVPN. Підлаштуйте шляхи під ваш дистрибутив. Кожне завдання містить: команду, приклад виводу, значення та рішення.
Виконуйте їх приблизно в такому порядку, коли ви в режимі бойового розгортання.

Завдання 1: Підтвердити, що OpenVPN використовує UDP (не TCP)

cr0x@server:~$ sudo ss -lunpt | grep openvpn
udp   UNCONN 0      0            0.0.0.0:1194       0.0.0.0:*    users:(("openvpn",pid=1324,fd=6))

Що це означає: Сервер слухає на UDP/1194. Якщо ви бачите tcp натомість, очікуйте гіршої продуктивності при втратах.
Рішення: Якщо TCP з’явився випадково, переключіться на UDP, якщо немає суворих фаєрвол‑обмежень.

Завдання 2: Перевірити погоджений шифр і параметри каналу даних

cr0x@server:~$ sudo journalctl -u openvpn-server@server --since "1 hour ago" | egrep -i "Data Channel|Cipher|peer info" | tail -n 8
Dec 27 09:20:11 server openvpn[1324]: Control Channel: TLSv1.3, cipher TLS_AES_256_GCM_SHA384
Dec 27 09:20:11 server openvpn[1324]: [client1] Peer Connection Initiated with [AF_INET]203.0.113.10:51234
Dec 27 09:20:11 server openvpn[1324]: [client1] Data Channel: cipher 'AES-256-GCM', peer-id: 0

Що це означає: Канал даних використовує AES‑256‑GCM. Добрий стандарт для апаратного AES‑NI.
Рішення: Якщо бачите лише CBC‑шифри або дивні застарілі налаштування — модернізуйте. Якщо клієнти — слабкі ARM‑пристрої, розгляньте ChaCha20, якщо ваша стек‑підтримка це дозволяє.

Завдання 3: Перевірити, чи активний DCO (якщо ви його очікуєте)

cr0x@server:~$ sudo modprobe -n ovpn-dco && lsmod | grep ovpn
insmod /lib/modules/6.1.0-18-amd64/kernel/drivers/net/ovpn/ovpn-dco.ko
ovpn_dco               94208  0

Що це означає: Модуль DCO існує і завантажений.
Рішення: Якщо ви очікували DCO, але його немає — не починайте з тонкого налаштування userland. Виправте платформні можливості і вибір збірки/пакету OpenVPN.

Завдання 4: Виміряти насичення CPU сервера і фіксацію на одному потоці

cr0x@server:~$ top -b -n 1 | head -n 12
top - 09:31:02 up 32 days,  3:11,  2 users,  load average: 3.12, 2.98, 2.71
Tasks: 189 total,   1 running, 188 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.3 us,  2.1 sy,  0.0 ni, 85.2 id,  0.0 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem :  32118.5 total,  11234.7 free,   4231.9 used,  16651.9 buff/cache
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1324 nobody    20   0  143832  21572   9856 R  98.7   0.1  10:44.02 openvpn

Що це означає: OpenVPN вантажить одне CPU‑ядро (~99%). Це класична поведінка стелі пропускної здатності для userland OpenVPN.
Рішення: Якщо це корелює з «повільним VPN», ви обмежені CPU/частотою пакетів. Розгляньте DCO, масштабування горизонтально або перенос важких потоків на WireGuard.

Завдання 5: Підтвердити наявність AES‑NI / прискорення крипто

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

Що це означає: CPU має прапори AES і PCLMULQDQ — добрий знак для швидкого AES‑GCM.
Рішення: Якщо прапорів AES немає (часто на деяких малих VM або старому залізі), очікуйте, що AES‑GCM буде повільнішим. Розгляньте ChaCha20, якщо ваш стек OpenVPN підтримує його чисто.

Завдання 6: Перевірити помилки і пропуски NIC (не звинувачуйте OpenVPN за поганий NIC)

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  missed   mcast
    9876543210 8432190      0    1274       0  10233
    TX:  bytes packets errors dropped carrier collsns
    8765432109 7321987      0       9       0      0

Що це означає: Є RX‑пропуски. Це можуть бути сплески, обмеження кільця або upstream‑перегрузка.
Рішення: Якщо пропуски зростають під час скарг, досліджуйте черги NIC, драйвер і завантаження хоста перед редагуванням конфігів OpenVPN.

Завдання 7: Шукати натиск на буфер прийому UDP

cr0x@server:~$ netstat -su | egrep -i "receive errors|packet receive errors|RcvbufErrors|InErrors"
    204 packet receive errors
    198 RcvbufErrors

Що це означає: Ядро відкидає UDP‑пакети через обмеження буфера прийому.
Рішення: Збільште сокетні буфери і перегляньте налаштування sysctl; інакше ви будете ганятися за «повільністю VPN», яка насправді є відмовами ядра.

Завдання 8: Перевірити ключові sysctl для UDP‑буферів та пересилання

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

Що це означає: Буфери малі для зайнятого VPN‑сервера.
Рішення: Якщо ви бачили RcvbufErrors, обережно підніміть ці значення і моніторте. Якщо ip_forward вимкнено, маршрутизація не працюватиме і ви отримаєте «VPN підключається, але нічого не працює».

Завдання 9: Підтвердити маршрутизацію і наявність шляхів повернення

cr0x@server:~$ ip route show table main | head
default via 198.51.100.1 dev eth0
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
198.51.100.0/24 dev eth0 proto kernel scope link src 198.51.100.20

Що це означає: Підмережа VPN існує і прив’язана до tun0.
Рішення: Якщо маршрут відсутній, ваш OpenVPN не створює тунельний пристрій або некоректно налаштований. Виправте це перед роботою над продуктивністю.

Завдання 10: Перевірити правила NAT, якщо клієнтам потрібен доступ до інтернету

cr0x@server:~$ sudo iptables -t nat -S | egrep 'POSTROUTING|MASQUERADE'
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Що це означає: Трафік клієнтів VPN маскується через eth0.
Рішення: Якщо клієнти скаржаться «підключено, але немає інтернету», відсутній NAT — типова підозра (за умови, що ви робите full‑tunnel).

Завдання 11: Виявити MTU‑чорні діри за допомогою ping + DF (не фрагментувати)

cr0x@server:~$ ping -c 3 -M do -s 1472 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=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420

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

Що це означає: Ефективний MTU вздовж шляху (з цього інтерфейсу/контексту) близько 1420. Ваше припущення 1500‑байт не витримує.
Рішення: Встановіть відповідний MTU тунелю і/або обмежте MSS. Якщо ігнорувати це, ви отримаєте періодичні зупинки і «працює на Wi‑Fi, не працює на LTE».

Завдання 12: Перевірити, що MSS‑клапан встановлено (коли потрібна маршрутизація/NAT)

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

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

Завдання 13: Виміряти базову пропускну здатність поза VPN

cr0x@server:~$ iperf3 -c 198.51.100.50 -P 4 -t 10
[SUM]   0.00-10.00  sec  4.82 GBytes  4.14 Gbits/sec  0             sender
[SUM]   0.00-10.00  sec  4.78 GBytes  4.10 Gbits/sec  12            receiver

Що це означає: Сировий мережевий шлях може видавати ~4.1 Гбіт/с.
Рішення: Якщо пропускна здатність через VPN значно нижча, проблема не в каналі. Вона в обробці тунелю, MTU або обмеженнях кінцевих точок.

Завдання 14: Виміряти пропускну здатність через VPN (сервер→клієнт або навпаки)

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

Що це означає: Готові тестувати з підключеного VPN‑клієнта до VPN‑IP сервера.
Рішення: Порівняйте продуктивність VPN і без нього. Якщо розрив великий і CPU сервера зафіксовано, ви знайшли обмеження.

Завдання 15: Переглянути qdisc (дисципліну черги) на предмет затримок під навантаженням

cr0x@server:~$ tc -s qdisc show dev eth0
qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
 Sent 8765432109 bytes 7321987 pkt (dropped 9, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0

Що це означає: fq_codel активний, дропи низькі, backlog порожній. Зазвичай це добре для затримки.
Рішення: Якщо ви бачите простий FIFO qdisc і великий backlog — очікуйте bufferbloat. Виправляйте чергування перед тим, як звинувачувати VPN.

Завдання 16: Перевірити частоту пакетів та переключення контексту по процесах

cr0x@server:~$ pidstat -p $(pgrep -n openvpn) -w 1 3
Linux 6.1.0-18-amd64 (server)  12/27/2025  _x86_64_  (8 CPU)

09:44:01      UID       PID   cswch/s nvcswch/s  Command
09:44:02      65534    1324    120.00   8400.00  openvpn
09:44:02      65534    1324    115.00   8600.00  openvpn
09:44:03      65534    1324    118.00   8550.00  openvpn

Що це означає: Багато непрофільованих переключень контексту може вказувати на контенцію і тиск планувальника, що характерно, коли userland‑datapath зайнятий.
Рішення: Якщо це високо під час тестів пропускної здатності, вам допоможе DCO, зменшення кількості пакетів (MTU/агрегація) або перенесення важких потоків на ефективніший тунель.

Три корпоративні міні‑історії (реалістичні, анонімізовані, трохи болючі)

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

Середня компанія розгорнула OpenVPN для з’єднання роздрібних точок із штабом. Розгортання виглядало чисто: одна модель апаратури, один шаблон конфігу,
однаковий рівень ISP на папері. Вони перевірили один пілот і потім клонували його на сорок інших.

Через два тижні почали надходити звернення: «інструмент інвентаризації тайм‑аутиться», «партія карток не відправляється», «VPN нестабільний». VPN залишався підключеним.
Ping працював. Але великі передачі зависали непередбачувано. Інженери робили те, що інженери роблять під тиском: міняли шифри і піднімали keepalive.
Нічого не допомогло.

Хибне припущення було простим: «MTU скрізь 1500». Декілька провайдерів доставляли PPPoE або інші лінки з обмеженнями.
Всередині тунелю пакети збільшувалися, фрагментувалися, і деякі шляхи скидали фрагменти. Класичне PMTU‑чорне дно.
Зависання були найпомітніші на великих HTTPS‑відповідях і запитах до БД з великими наборами результатів.

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

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

Внутрішня платформа прагнула більшої пропускної здатності від їх концентратора OpenVPN. Вони знайшли старий блог, який радив збільшити сокетні буфери
і накрутили net.core.rmem_max та wmem_max значно. Також підняли внутрішні буфери OpenVPN.
Синтетичні тести покращилися в чистій лабораторній мережі. Вони це випустили.

Через місяць з’явилася інша скарга: «VPN лагує під час дзвінків». Не «повільні завантаження» — а лаг. Відеозустрічі підстрибають.
SSH відчувався липким. Графіки пропускної здатності виглядали нормально. Команда була збита з пантелику, що є популярним корпоративним емоційним станом.

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

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

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

Організація, що дбає про безпеку, запускала і WireGuard, і OpenVPN: WireGuard для керованих ноутбуків, OpenVPN для підрядників і «дивних пристроїв»,
які не могли запускати стандартний клієнт. Сервіс OpenVPN не був гламурним, тож його обробляли як будь‑який production‑сервіс:
закриті версії пакетів, вікно змін і канарка.

Одного дня потрібно було прокрутити сертифікати і відрегулювати пріоритети шифрів для відповідності. Зміни були заплановані і протестовані.
Канарка була невеликою, але різноманітною: macOS‑клієнт, Windows‑клієнт, Linux‑клієнт, мобільний клієнт.
Вони дивилися логи на предмет збоїв переговорів і вимірювали пропускну здатність і частоту перепідключень.

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

Нічого драматичного не сталося. У цьому й суть. Нудна практика — канарка плюс невелика матриця сумісності — запобігла відмові сумісності.
За це не дають трофеїв. За це дають можливість нормально пообідати.

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

1) «VPN підключено, але деякі сайти ніколи не закінчують завантаження»

Корінна причина: MTU/PMTU‑чорні діри; фрагментація скидалася на деяких шляхах; відсутній MSS‑клапан.
Виправлення: Виміряйте ефективний MTU за допомогою DF‑ping; обмежте MSS (TCPMSS --clamp-mss-to-pmtu); встановіть консервативний tun-mtu, якщо потрібно.

2) «Швидко в офісі по Wi‑Fi, але жахливо на LTE або в готелях»

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

3) «Пропускна здатність обмежується приблизно ~100–300 Мбіт/с на великому сервері»

Корінна причина: Userland OpenVPN обмежений CPU/частотою пакетів; одне ядро зафіксовано; повільний шифр або відсутнє апаратне прискорення.
Виправлення: Перейдіть на AES‑GCM з апаратною підтримкою; увімкніть DCO де можливо; масштабуйтесь горизонтально; розгляньте WireGuard для bulk‑трафіку.

4) «Затримка вибухає під час великих завантажень»

Корінна причина: Bufferbloat від надмірних буферів або поганого qdisc; перевантажений аплінк; черги живуть в неправильному місці.
Виправлення: Використовуйте fq_codel або CAKE; формуйте трохи нижче аплінку; не інфлатуйте сокетні буфери бездумно.

5) «Клієнти підключаються, але не дістаються внутрішніх підмереж»

Корінна причина: Відсутні маршрути на сервері або downstream‑роутерах; ip_forward вимкнено; конфлікти policy routing/NAT.
Виправлення: Підтвердьте наявність маршрутів, увімкніть пересилання, пуште коректні маршрути, забезпечте правильні шляхи повернення (не покладайтеся на випадковий NAT).

6) «Випадкові перепідключення або зависання під навантаженням»

Корінна причина: Втрати пакетів, UDP‑скиди, помилки прийому буфера або перевантажений сервер, що затримує keepalive.
Виправлення: Перевірте netstat -su на помилки, пропуски NIC, фіксацію CPU; зменшіть частоту пакетів; обережно підвищте буфери; масштабуйтесь.

7) «Він став повільнішим після ввімкнення компресії»

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

8) «Ми перейшли на TCP для надійності, а стало гірше»

Корінна причина: Мелтдаун TCP‑over‑TCP при втраті і перестановках.
Виправлення: Використовуйте UDP. Якщо заблоковано, пропонуйте TCP як профіль‑фолбек, і ставте очікування: це режим сумісності, а не продуктивності.

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

Покроково: коректна база OpenVPN для продакшну

1. Обирайте маршрутизований режим TUN, якщо вам справді не потрібен L2‑бриджинг.
2. За умовчанням використовуйте UDP для транспорту.
3. Вибирайте сучасні шифри (AES‑GCM на серверах з AES‑NI; уникайте старих CBC‑наборів).
4. Вимкніть компресію для каналу даних у сучасному середовищі.
5. Сплануйте MTU: тестуйте DF‑ping; обмежуйте MSS для TCP‑потоків.
6. Налаштуйте маршрути правильно: пуште маршрути свідомо; забезпечте шляхи повернення.
7. Визначте NAT проти маршрутизованого режиму для доступу клієнтів у інтернет і внутрішньої досяжності. Документуйте це.
8. Спостережуваність: логування переговорів, підключень клієнтів, причин відключення; збір CPU, дропів і лічильників UDP‑помилок.
9. Тестування ємності з iperf3 через тунель з реалістичною конкуренцією і розмірами пакетів.
10. Мати профіль‑фолбек (TCP або альтернативний порт) для ворожих мереж — чітко маркований як повільніший.
11. Автоматизувати розповсюдження клієнтських конфігів і тримати невелику матрицю сумісності.
12. Каденс патчів: ставте OpenVPN як будь‑який edge‑сервіс. Вікна змін і канарки.

Покроково: вирішити, залишати OpenVPN чи переносити трафік на WireGuard

1. Виміряйте поточну стелю: пропускна здатність VPN проти завантаження CPU і пропусків пакетів.
2. Якщо одне ядро зафіксовано, спершу оцініть DCO, якщо вам потрібні фічі OpenVPN.
3. Якщо вам потрібні site‑to‑site або «керовані клієнти», WireGuard часто простіший в експлуатації і швидший.
4. Залишайте OpenVPN для середовищ, що потребують зрілих корпоративних потоків автентифікації і широкої сумісності клієнтів.
5. Проведіть пілот: невелика група на WireGuard; порівняйте затримку під навантаженням, поведінку при перепідключеннях і підтримку.

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

Чи OpenVPN за своєю суттю повільний?

Ні. Часто він повільніший за WireGuard при високих швидкостях пакетів, бо класичний OpenVPN виконує datapath у userland і має додаткові накладні витрати.
З хорошими конфігами і підтримкою DCO OpenVPN може бути достатньо швидким для багатьох організацій.

Чому OpenVPN іноді максимально завантажує одне CPU‑ядро?

Шифрування/дешифрування і переміщення пакетів між ядром і userland можуть стати гарячою однопоточною ділянкою.
Дрібні пакети погіршують ситуацію, бо збільшується частота пакетів. Симптом — одне ядро завантажено, інші просто відпочивають.

Чи варто запускати OpenVPN поверх TCP заради надійності?

Не як стандарт. Мелтдаун TCP‑over‑TCP — класичний режим відмови при втратах. Використовуйте UDP, якщо мережі клієнтів не блокують його.
Якщо змушені пропонувати TCP — робіть це як фолбек і пояснюйте, що це режим сумісності, а не продуктивності.

Яка найпоширеніша помилка продуктивності OpenVPN?

MTU‑проблеми. Вони маскуються під «випадкова повільність» і «деякі сайти не працюють». Виміряйте MTU і обмежте MSS.
Це негламурно, тому повторюється з року в рік.

Чи AES‑256‑GCM робить OpenVPN повільнішим за AES‑128‑GCM?

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

Як зрозуміти, чи я обмежений втратою пакетів чи CPU?

Якщо сервер показує помилки прийому UDP, пропуски NIC або втрати по шляху (а CPU не завантажено) — швидше за все ви обмежені втратою/заповненням.
Якщо OpenVPN зафіксовано приблизно на 100% одного ядра під час тестів — швидше за все ви обмежені CPU/частотою пакетів.

Чи WireGuard завжди швидший?

Часто, але не завжди. Якщо ваше вузьке місце — провайдер, Wi‑Fi, LTE‑втрати або CPU на віддаленому клієнті, зміна VPN не створить додаткову пропускну здатність.
Перевага WireGuard найсильніша в Linux, де ядровий datapath і простий протокол зменшують накладні витрати.

Чи можна просто підвищити буфери, щоб зробити OpenVPN швидшим?

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

Що таке OpenVPN DCO і чи варто його використовувати?

DCO (Data Channel Offload) переміщує більше обробки пакетів в ядро, зменшуючи накладні витрати userland.
Якщо вам потрібні фічі OpenVPN, але ви хочете кращу пропускну здатність/затримку — варто оцінити DCO ретельно, з канарками і тестами сумісності клієнтів.

Коли варто залишити OpenVPN замість міграції?

Якщо ви покладаєтеся на зрілі корпоративні інтеграції автентифікації, складні пуш‑політики або широку сумісність сторонніх клієнтів — OpenVPN залишається практичним.
Можна також запускати обидва: WireGuard для керованих кінцевих точок, OpenVPN для «усіх інших».

Висновок: що робити далі

Якщо хочете, щоб OpenVPN поводився, зробіть його нудним: UDP, маршрутизований TUN, сучасні шифри, без компресії і явне опрацювання MTU.
Потім інструментуйте це так, ніби ви серйозно це маєте наглядати — CPU, дропи, помилки UDP‑буфера і чергування.

Якщо вам потрібна максимальна пропускна здатність і низька затримка у масштабі на Linux, WireGuard часто перемагає, бо спроектований, щоб уникати плату userland.
Якщо вам потрібна екосистема і контроль OpenVPN, розгляньте DCO і дизайн зі масштабуванням. В обох випадках: спочатку виміряйте, потім змінюйте, і запишіть висновки, щоб не переучуватися о 2‑й ночі.