Тести якості VPN в офісі: виміряйте затримку, джитер і втрати, щоб довести проблему з провайдером

Яким насправді має бути «хороша якість VPN»

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

Для офісного VPN до датацентру (або офісу в хмарі), який переносить інтерактивний трафік (VoIP, RDP, VDI, SSH), ось практичні цілі, які я використовую:

• Затримка (RTT): Стабільність важливіша за мінімум. Менше 50 ms RTT — чудово для того ж регіону; менше 100 ms — придатно; стрибки — ворог.
• Джитер: Зазвичай 5–10 ms достатньо; понад 20–30 ms — голос починає звучати як робот з болем у горлі.
• Втрата пакетів: Менше 0.1% зазвичай непомітно; 0.5% починає спричиняти реальний біль у додатках; 1% — податок на продуктивність; 2% — криза.
• Перемішування (reordering): Зазвичай близько нуля; коли з’являється, TCP може виглядати «повільним», навіть якщо пропускна здатність є.
• MTU-адекватність: Правильний кінцевий MTU запобігає фрагментації/чорним дірам; неправильний MTU може імітувати «випадкову повільність».
• Пропускна здатність: Для масових потоків важлива стійка пропускна здатність під навантаженням, а не пікові «speed test» числа.

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

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

• Факт 1: Класичний інструмент ping датований початком 1980-х і був натхненний сонаром; його створили для перевірки досяжності, а не для аналізу продуктивності.
• Факт 2: «Джитер» став повсякденною метрикою в основному через перехід реального часу голосу/відео з комутації каналів на пакетну комутацію.
• Факт 3: IPsec (поширена технологія site-to-site VPN) стандартизували в 1990-х, коли типові Інтернет-канали були значно повільніші і NAT не був повсюдним.
• Факт 4: WireGuard відносно новий (серединa–кінець 2010-х) і навмисно малий; менше налаштувань, менше «пасток» і загалом краща базова продуктивність.
• Факт 5: TCP-пропускна здатність обмежується RTT і втратою; тому канал з великою пропускною здатністю може «здаватися повільним» по шляху з втратами або джитером.
• Факт 6: Багато споживчих і навіть «бізнес» широкосмугових ліній покладаються на перенасичення; затори часто залежать від часу доби і не проявляються в одному тесті.
• Факт 7: Bufferbloat (надмірне буферування в мережевих пристроях) широко обговорювали з кінця 2000-х і воно може спричиняти величезні спайки затримки під завантаженням.
• Факт 8: ECMP (equal-cost multipath) у мережах провайдерів може спричиняти перемішування пакетів; інкапсуляція VPN іноді змінює хешування потоків по шляхах.
• Факт 9: Деякі мережі досі ставляться до ICMP інакше (лімітують, понижують пріоритет); саме тому треба підтверджувати ping іншими методами перед тим, як оголошувати перемогу.

Жарт 1: Приємна річ у «переривчастих втратах пакетів» — це навчання усіх уважності. Ви не можете чіплятися за очікування, коли ваші пакети не чіпляються за існування.

Метрики, що мають значення (і ті, що брешуть)

Затримка: вимірюйте розподіли, а не одне число

Середня затримка приховує біль. Користувачі відчувають стрибки. Захоплюйте min/avg/max і перцентили, якщо ваші інструменти це підтримують.
Коли хтось каже «VPN повільний», вони зазвичай описують змінність, а не стійку середню.

Джитер: метрика якості для трафіку реального часу

Джитер — це варіація затримки. VoIP і відеоконференції можуть трохи буферизувати; коли джитер перевищує буфер,
аудіо рветься, а відео зависає. VPN-тунелі можуть підсилювати джитер, коли крипто-пристрої завантажені по CPU або коли
черги провайдера заповнюються під навантаженням.

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

TCP трактує втрати як ознаку затору і зменшує швидкість. Невелика випадкова втрата може обрушити пропускну здатність на шляхах з великим RTT.
Для офісних VPN втрата також головний драйвер проблем типу «RDP відчувається важким», «Teams зависає» і «копіювання файлів зависло».

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

Один потік — не реальність. Багато VPN-шлюзів добре проходять один iperf-стрім і провалюються при десяти. Також тестуйте upload:
офіси часто насичують upstream під час резервних копій, сканувань або коли «хтось надіслав 2 GB всій компанії».

MTU/фрагментація: класична пастка VPN

Інкапсуляція VPN додає накладні витрати. Якщо ваш ефективний PMTU зменшується, а PMTUD заблоковано або зламано, великі пакети зникають.
Симптоми виглядають як «деякі сайти працюють, деякі — ні», або «SSH гарно, а передача файлів зависає».
Проблеми з MTU нудні, поширені і абсолютно варті перевірки з самого початку.

Що брешуть: speed tests, одиночні ping і «всьо зелено в дашборді»

Публічні speed tests часто потрапляють на сусідні CDN-вузли через добре спіровані шляхи, які ваш VPN-трафік ніколи не використовує. Одиночний ping
о 9:03 ранку практично нічого не доводить. І дашборди зеленіють, коли вимірюють досяжність, а не досвід.

Одна цитата (перефразована ідея): John Allspaw стверджував, що надійність походить з розуміння систем у реальних умовах, а не з пошуку винних між людьми.

План швидкої діагностики

Коли офісний VPN «погано себе веде», у вас немає часу на тижневе дослідження. Почніть з найшвидших дискримінаторів: вузьке місце на локальному LAN/Wi‑Fi, останній миль ISP,
VPN-шлюз чи upstream-мережа?

Перше: підтвердьте охоплення й оберіть два кінцеві точки

• Оберіть клієнта: провідна машина в офісному LAN (не Wi‑Fi, якщо скарга не про Wi‑Fi).
• Оберіть дві цілі: (1) публічна IP VPN-шлюзу офісу, (2) внутрішній хост за VPN (jump box або сервер).
• Визначте часові рамки: «зараз» і «повторити під час піку».

Друге: розділіть шлях на сегменти

• Клієнт → офісний роутер: перевіряє LAN/Wi‑Fi.
• Клієнт → публічна IP VPN-шлюзу: перевіряє шлях ISP до шлюзу.
• Клієнт → внутрішній хост через VPN: перевіряє тунель + віддалену сторону.
• VPN-шлюз → внутрішній хост: перевіряє віддалену мережу, якщо ви можете запускати тести там.

Третє: виконайте три швидкі тести

1. Ping з часовими мітками та інтервалами (базова затримка/джитер/втрати).
2. MTR (втрати/затримка по хопах; корисно для ескалації, але не є євангелієм).
3. Короткий запуск iperf3 в обох напрямках (пропускна здатність + втрата під навантаженням).

Четверте: провокуйте проблему (обережно)

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

П’яте: вирішіть, куди фокусуватися

• Погано до публічної IP шлюзу: ISP/локальний канал, піринг або останній мильний конгест.
• Добре до шлюзу, але погано через тунель: CPU VPN-шлюзу, MTU, налаштування шифрування або віддалена сторона.
• Добре з провідного, але погано з Wi‑Fi: перервіть винищувати ISP; виправляйте RF, роумінг або драйвери клієнта.

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

Ці завдання передбачають клієнти/сервери на Linux. Якщо ви на macOS або Windows, логіку можна застосувати; назви команд змінюються, фізика не змінюється.

Завдання 1: Визначте активний інтерфейс і шлюз (щоб уникнути тестування не того шляху)

cr0x@server:~$ ip route show
default via 192.0.2.1 dev eno1 proto dhcp src 192.0.2.50 metric 100
192.0.2.0/24 dev eno1 proto kernel scope link src 192.0.2.50

Що це означає: Ваш клієнт виходить через eno1 до 192.0.2.1.
Якщо хтось запускає тести по Wi‑Fi, а користувачі на провідному з’єднанні (або навпаки), ви дебагуєте вигадану проблему.

Рішення: Якщо маршрут неправильний, виправте його перед тестуванням. Інакше продовжуйте.

Завдання 2: Базова перевірка LAN: ping до шлюзу за замовчуванням

cr0x@server:~$ ping -c 20 -i 0.2 192.0.2.1
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=0.362 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.401 ms
...
20 packets transmitted, 20 received, 0% packet loss, time 3804ms
rtt min/avg/max/mdev = 0.331/0.389/0.471/0.038 ms

Що це означає: Це ваш базовий рівень. Якщо ви бачите втрати або багатомілісекундний джитер тут на провідній мережі,
ISP — не ваша перша проблема.

Рішення: Якщо LAN-ping нестабільний, перевірте порти комутаторів, дуплекс, помилки NIC, Wi‑Fi або локальне завантаження.

Завдання 3: Перевірте лічильники NIC на наявність дропів і помилок

cr0x@server:~$ ip -s link show dev eno1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    987654321  123456      0       2       0       123
    TX:  bytes packets errors dropped carrier collsns
    876543210  112233      0       0       0       0

Що це означає: Кілька дропів може бути прийнятним; зростання помилок/дропів під час скарг — це явний індикатор.

Рішення: Якщо помилки зростають, замініть кабель, виправте mismatch дуплексу, оновіть драйвери/прошивку або перемістіть порт.

Завдання 4: Підтвердіть вибір маршруту для VPN (split tunnel часто дивує)

cr0x@server:~$ ip route get 10.10.20.15
10.10.20.15 dev wg0 src 10.200.0.2 uid 1000
    cache

Що це означає: Трафік до 10.10.20.15 йде через wg0 (VPN).
Якщо він іде через маршрут за замовчуванням, ви взагалі не тестуєте тунель.

Рішення: Виправте маршрути/політи перед діагностикою «продуктивності VPN».

Завдання 5: Виміряйте RTT, джитер-проксі (mdev) та втрати до публічної IP VPN-шлюзу

cr0x@server:~$ ping -c 50 -i 0.2 203.0.113.10
PING 203.0.113.10 (203.0.113.10) 56(84) bytes of data.
64 bytes from 203.0.113.10: icmp_seq=1 ttl=52 time=18.9 ms
64 bytes from 203.0.113.10: icmp_seq=2 ttl=52 time=19.2 ms
...
50 packets transmitted, 50 received, 0% packet loss, time 10052ms
rtt min/avg/max/mdev = 18.5/19.4/28.7/1.8 ms

Що це означає: mdev не ідеальний як джитер, але це хороший швидкий індикатор.
Максимальний стрибок (28.7 ms) примітний; якщо під час скарг це перетворюється на 200+ ms, ймовірно, ви бачите конгестію.

Рішення: Якщо тут з’являється втрата, фокусуйтеся на шляху ISP перед тим, як звинувачувати налаштування крипто VPN.

Завдання 6: MTR до публічної IP VPN-шлюзу (докази, а не теологія)

cr0x@server:~$ mtr -rwzc 200 203.0.113.10
Start: 2025-12-28T09:15:02+0000
HOST: office-client                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.0.2.1                        0.0%   200    0.5   0.6   0.4   1.2   0.1
  2.|-- 198.51.100.1                     0.0%   200    7.8   8.1   6.9  20.3   1.5
  3.|-- 198.51.100.34                    1.5%   200   12.1  12.8  10.2  45.7   4.2
  4.|-- 203.0.113.10                     0.5%   200   19.6  21.4  18.4  80.2   6.9

Що це означає: Втрати на проміжних хопах можуть бути результатом rate-limiting ICMP. Ключ — чи зберігаються втрати до фінального хопу. Тут 0.5% на призначення досить реальні, щоб шкодити VPN-досвіду.

Рішення: Якщо втрата на призначенні корелює з часом скарг, починайте збирати пакет доказів для ескалації до ISP.

Завдання 7: Порівняйте з «контрольним» хостом поза VPN (доведіть, що проблема специфічна для шляху)

cr0x@server:~$ ping -c 50 -i 0.2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=9.7 ms
...
50 packets transmitted, 50 received, 0% packet loss, time 10043ms
rtt min/avg/max/mdev = 9.4/9.9/12.5/0.4 ms

Що це означає: Інтернет загалом може виглядати нормально, поки шлях до вашого VPN-шлюзу хворий.
Саме тому ви тестуєте фактичний VPN-ендпойнт.

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

Завдання 8: Перевірте MTU до внутрішнього хоста (знаходьте чорні діри рано)

cr0x@server:~$ ping -M do -s 1372 -c 3 10.10.20.15
PING 10.10.20.15 (10.10.20.15) 1372(1400) bytes of data.
1380 bytes from 10.10.20.15: icmp_seq=1 ttl=63 time=24.3 ms
1380 bytes from 10.10.20.15: icmp_seq=2 ttl=63 time=24.8 ms
1380 bytes from 10.10.20.15: icmp_seq=3 ttl=63 time=25.1 ms

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

Що це означає: -M do забороняє фрагментацію. Якщо це не проходить, ваш ефективний MTU менший, ніж ви вважаєте, і PMTUD може не працювати.

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

Завдання 9: Виявлення зламаного PMTUD (класичне «працює для малого, падає для великого»)

cr0x@server:~$ tracepath 10.10.20.15
 1?: [LOCALHOST]                      pmtu 1500
 1:  10.200.0.1                        4.123ms
 2:  10.10.20.15                      24.910ms reached
     Resume: pmtu 1420 hops 2 back 2

Що це означає: Виявлено Path MTU як 1420. Це правдоподібно для деяких сценаріїв з накладними витратами VPN.
Якщо інтерфейси встановлені на 1500 і ви покладаєтеся на PMTUD, але ICMP блокується десь, ви можете отримати чорні діри.

Рішення: Встановіть MTU VPN на або нижче виявленого PMTU (з запасом), або застосуйте TCP MSS clamping на крайовому пристрої.

Завдання 10: Запустіть iperf3 через VPN (один потік)

cr0x@server:~$ iperf3 -c 10.10.20.15 -t 15
Connecting to host 10.10.20.15, port 5201
[  5] local 10.200.0.2 port 45322 connected to 10.10.20.15 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  6.25 MBytes  52.4 Mbits/sec    0   1.12 MBytes
[  5]   1.00-2.00   sec  6.12 MBytes  51.3 Mbits/sec    2   0.96 MBytes
...
[  5]  14.00-15.00  sec  3.10 MBytes  26.0 Mbits/sec   18   0.42 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-15.00  sec  67.2 MBytes  37.6 Mbits/sec  61             sender
[  5]   0.00-15.00  sec  66.5 MBytes  37.2 Mbits/sec                  receiver

Що це означає: Ретрансмісії (Retr) і падіння бітрейту вказують на втрати, конгестію або шлях з обмеженим CPU.
Здоровий VPN-шлях не повинен показувати швидке зростання Retr в короткому чистому тесті.

Рішення: Якщо Retr різко зростають, зіставте з ping-втратою і досліджуйте ISP або MTU/черги тунелю.

Завдання 11: Запустіть iperf3 в зворотному напрямку (завантаження з офісу може бути ок, а відправка — катастрофа)

cr0x@server:~$ iperf3 -c 10.10.20.15 -R -t 15
Connecting to host 10.10.20.15, port 5201
Reverse mode, remote host 10.10.20.15 is sending
[  5] local 10.200.0.2 port 45330 connected to 10.10.20.15 port 5201
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-15.00  sec  120 MBytes  67.1 Mbits/sec   3             sender
[  5]   0.00-15.00  sec  119 MBytes  66.5 Mbits/sec                 receiver

Що це означає: Зворотній напрямок чистий; прямий був ні. Це сильна підказка, що upstream офісу насичений або погано шейпиться, або ваша egress-черга переповнена.

Рішення: Зосередьтеся на upstream-ом, QoS/SQM або на проблемі з upload у провайдера.

Завдання 12: Виміряйте затримку під навантаженням (перевірка bufferbloat)

cr0x@server:~$ (ping -i 0.2 -c 50 203.0.113.10 | tail -n 3) & iperf3 -c 10.10.20.15 -t 15 > /dev/null; wait
50 packets transmitted, 50 received, 0% packet loss, time 10041ms
rtt min/avg/max/mdev = 19.0/85.4/312.7/58.1 ms

Що це означає: Середній RTT зріс у чотири рази, а максимум досяг 312 ms під час навантаження. Це класичний bufferbloat або насичення черг.
Користувачі відчувають це як «VPN нормальний, доки ми щось не робимо».

Рішення: Впровадьте smart queue management (SQM) на краю, шейпте трохи нижче реальної швидкості ISP або збільшіть upstream-канал.

Завдання 13: Перевірте MTU і статистику інтерфейсу VPN (дропи на рівні тунелю)

cr0x@server:~$ ip -s link show dev wg0
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none
    RX:  bytes packets errors dropped  missed   mcast
    12345678   54321      0      45       0       0
    TX:  bytes packets errors dropped carrier collsns
    23456789   65432      0      12       0       0

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

Рішення: Якщо дропи зростають у пікові періоди, шейпте трафік, перегляньте QoS і перевірте завантаження CPU на VPN-ендпойнті.

Завдання 14: Спостерігайте runtime-статистику WireGuard (свіжість handshake і передача)

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

peer: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy=
  endpoint: 203.0.113.10:51820
  allowed ips: 10.10.0.0/16
  latest handshake: 28 seconds ago
  transfer: 1.23 GiB received, 2.10 GiB sent
  persistent keepalive: every 25 seconds

Що це означає: Handshake-и відбуваються; тунель живий. Якщо latest handshake стає застарілим або флапає, ви можете стикатися з timeouts NAT або фільтрацією upstream.

Рішення: Якщо handshakes зникають в режимі idle, увімкніть keepalive або виправте NAT/firewall state timeouts.

Завдання 15: Підтвердіть стан IPsec SA (якщо ви використовуєте IPsec)

cr0x@server:~$ sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.8, Linux 6.5.0, x86_64):
  uptime: 2 hours, since Dec 28 07:12:03 2025
Connections:
office-to-dc:  192.0.2.0/24 === 10.10.0.0/16
Security Associations (1 up, 0 connecting):
office-to-dc[1]: ESTABLISHED 12 minutes ago, 198.51.100.10[CN=office]...203.0.113.10[CN=dc]
office-to-dc{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c1a2b3c4_i c4b3a2c1_o
office-to-dc{1}:   192.0.2.0/24 === 10.10.0.0/16

Що це означає: SA встановлено. Це не доводить якості, але виключає бажання вважати, що проблема в численні перепідключень переговорів, які спричиняють періодичні зависання.

Рішення: Якщо SA часто перевстановлюються або флапають, виправте часи життя, NAT-T обробку або firewall pinholes.

Завдання 16: Захопіть короткий пакетний трейc для доказу фрагментації або ретрансмісій

cr0x@server:~$ sudo tcpdump -ni wg0 -c 20 -vv 'host 10.10.20.15 and (tcp or icmp)'
tcpdump: listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
09:18:41.120001 IP (tos 0x0, ttl 64, id 12345, offset 0, flags [DF], proto ICMP (1), length 1420)
    10.200.0.2 > 10.10.20.15: ICMP echo request, id 3011, seq 1, length 1400
09:18:41.144210 IP (tos 0x0, ttl 63, id 54321, offset 0, flags [DF], proto ICMP (1), length 1420)
    10.10.20.15 > 10.200.0.2: ICMP echo reply, id 3011, seq 1, length 1400
...

Що це означає: Ви бачите DF встановлений і успішні відповіді на розмірі 1400 — добре для MTU. Для TCP дивіться на ретрансмісії й звуження вікна.

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

Три корпоративні міні-історії (усі болісно правдоподібні)

Інцидент через помилкове припущення: «Ping чистий, отже ISP невинний»

Середня компанія мала site-to-site VPN від головного офісу до хмарного VPC. Хелпдеск повідомляв, що RDP-сесії
зависають, потім відновлюються ривками. Мережна команда виконала ping до VPN-шлюзу. 0% втрат, ~12 ms.
Вони оголосили ISP у порядку і перейшли до звинувачень у Windows updates.

Зависання продовжувалося. Тож хтось нарешті запустив тест, який відповідав робочому навантаженню: тривале завантаження через
VPN при одночасному вимірюванні затримки до шлюзу. RTT підскочив з ~12 ms до ~280 ms і тримався. VPN не був «падким».
Він просто застряг за океаном буферів в upstream-черзі офісного роутера.

Помилкове припущення було тонким: «Якщо ping зараз хороший, лінія в порядку». Насправді, idle-ping вимірює щасливий шлях.
Бізнес страждав під навантаженням. Одна камера, резервна копія або великий screen share могли наповнити чергу і додати секунди затримки.

Виправлення не було романтичним. Вони впровадили smart queue management на краї і шейпнули upload трохи нижче реального upstream ISP.
RDP знову став нудним. Провайдер нічого не змінював; офіс змінив.

Оптимізація, що відкотилася: «Увімкнули hardware offload і стало гірше»

Інша компанія розгорнула нові крайові апарати і вклала всі прискорювальні функції: checksum offload, GRO/LRO і деякий вендорський «VPN fast path».
Бенчмарки пропускної здатності в лабораторії виглядали чудово.
У продакшні VoIP-дзвінки через VPN почали втрачати слова. Тунель тримався, масові передачі швидкі,
тож проблему списували на «Teams».

Підказка прийшла з джитеру. При помірному навантаженні середня затримка не була високою, але була надзвичайно змінною — мікросплески й пакетні пачки.
Offload-и збирали пакети й доставляли їх пачками. Інтерактивні потоки ненавидять пачки.

«Оптимізація» покращила метрику, яка комусь важлива (пікова пропускна здатність) і погіршила метрику, яка важлива користувачам (послідовна затримка).
Вимкнення частини offload-ів на WAN/VPN інтерфейсах трохи знизило пропускну, але зробило джитер адекватним. VoIP стабілізувався миттєво.

Ніхто не любить висновок: іноді ви купуєте швидший автомобіль і розумієте, що їздите лише в пробках. Оптимізуйте для стабільності затримки першочергово. Ширина каналу рідко є гальмом для людського VPN-болю.

Нудна, але правильна практика, що врятувала ситуацію: «Часові серії вимірювань з журналом змін»

Глобальна команда мала повторювану скаргу: «Що вівторок вдень VPN жахливий». Люди висували теорії:
технічне обслуговування провайдера, проблеми хмари, сонячні бурі і одна пам’ятна пропозиція про «зачарований комутатор».

SRE на зміні зробив найменш захопливу річ. Він налаштував заплановані тести кожні п’ять хвилин з провідного офісного хоста: ping і MTR до VPN-шлюзу, плюс короткий iperf3 до внутрішнього тест-сервера.
Вони зберігали сирі виходи з часовими мітками і звіряли їх з простим журналом змін: зміни WAN-каналу, політики firewall, оновлення кінцевих точок і офісні події.

Через два тижні патерн став очевидним. Втрати й джитер різко зростали в один і той же час щотижня, але лише в upstream-напрямку.
Це корелювало з регулярною зовнішньою резервною копією, що «вбивала» upload. Робота не була новою; обсяг даних зріс, і вона нарешті перейшла поріг, де черги руйнувалися.

Вони перенесли вікно резервного копіювання, обмежили швидкість і впровадили базовий SQM. Вівторки знову стали тихими. Найкраще: не треба було героїки, лише чеки.
Докази також запобігли безглуздій ескалації до провайдера з відповіддю «no fault found».

Жарт 2: Найнадійніша мережева стратегія — «спочатку вимірюй». Друга найнадійніша — «не запускай резервні копії о 14:00».

Перевірочні списки / покроковий план

Покроково: встановіть повторюваний тест якості VPN

1. Оберіть стабільний тест-клієнт. Провідний, не на док-станції з ненадійним USB NIC.
   Якщо ви мусите тестувати Wi‑Fi, робіть це свідомо і документуйте, що це Wi‑Fi.
2. Оберіть стабільні цілі.
   Одна публічна мета: публічна IP VPN-шлюзу. Одна приватна: внутрішній хост, доступний тільки через VPN.
3. Визначте три вікна тестування.
   Ранкова тиша, пікові години і «година скарг», яку всі називають.
4. Запустіть базові тести.
   Ping до шлюзу (LAN), ping до публічної IP VPN-ендпойнта, ping до внутрішнього хоста через VPN, MTR до VPN-ендпойнта, перевірки MTU.
5. Запустіть навантажувальні тести короткими спалахами.
   iperf3 вперед і назад по 15–30 секунд. Не спалюйте продакшн-канали на хвилини.
6. Повторюйте і зберігайте сирі виходи.
   Скриншоти — не дані. Зберігайте текстові виходи з часовими мітками.
7. Корелюйте з метриками пристроїв.
   CPU VPN-шлюзу, дропи інтерфейсів, WAN-утилізація і будь-які лічильники shaping/policing.
8. Прийміть рішення.
   Якщо погіршення видно до тунелю (до публічної IP), ескалюйте до ISP. Якщо тільки через тунель — виправте конфігурацію VPN або віддалену сторону.

Чекліст: перед тим як дзвонити в ISP

• Підтвердьте, що проблема виникає з провідного клієнта (якщо лише Wi‑Fi не підозрюється).
• Покажіть втрати/джитер до публічної IP VPN-шлюзу у часі, а не один тест.
• Надайте MTR-виходи до того ж ендпойнта під час хороших і поганих періодів.
• Надайте доказ затримки під навантаженням, якщо підозрюється конгестія/bufferbloat.
• Підтвердіть, що MTU працює (або задокументуйте, що ви його підкоригували), щоб ISP не звинуватив вашу інкапсуляцію.
• Документуйте хто, де, коли: ідентифікатор каналу, місце офісу, часові мітки з часовим поясом та чи була перевірка через VPN.

Чекліст: зміни, що зазвичай покращують якість VPN

• Увімкніть або виправте SQM на крайовому офісному пристрої (або шейпте трохи нижче швидкості ISP).
• Виправте MTU/MSS для шляху VPN.
• Віддавайте перевагу проводу для критичних VPN-користувачів; виправте роумінг Wi‑Fi для інших.
• Слідкуйте за CPU і навантаженням переривань на VPN-шлюзі в піки; масштабування або офлоад потрібні при необхідності.
• Відокремте масовий трафік (резервні копії, великі синки) від інтерактивного за допомогою QoS.

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

• Симптом: «VPN повільний, але speed tests відмінні.»
  Корінна причина: Speed tests потрапляють на сусідній CDN; VPN-трафік иде іншим, перевантаженим шляхом або страждає від втрат/джитера.
  Виправлення: Тестуйте до публічної IP VPN-шлюзу і до внутрішнього хоста через тунель; запускайте тести в пікові години і під навантаженням.
• Симптом: «SSH працює, але передача файлів зависає; деякі додатки таймаутяться.»
  Корінна причина: MTU/PMTUD чорна діра всередині шляху VPN.
  Виправлення: Використайте ping -M do з більшими payload, застосуйте tracepath, зменшіть MTU тунелю або clamp TCP MSS на краї.
• Симптом: «Teams/VoIP рве звук тільки коли йде завантаження.»
  Корінна причина: Bufferbloat або насичення upstream в офісі.
  Виправлення: Застосуйте SQM/shaping для upstream; перенесіть масові завдання в інший час; встановіть ліміти для резервних копій.
• Симптом: «MTR показує втрати на хопі 3; ISP каже, що все нормально.»
  Корінна причина: Проміжні роутери лімітують ICMP; це не обов’язково означає втрати в data-plane.
  Виправлення: Фокусуйтеся на втраті/затримці до фінального призначення; підтвердіть iperf3 ретрансмісіями і симптомами додатків.
• Симптом: «Пропускна здатність VPN жахлива на одному сайті; інші сайти нормальні.»
  Корінна причина: Асиметрична маршрутизація, відмінності пірингу або локальний last-mile дефект.
  Виправлення: Порівняйте MTR і ping з кількох сайтів до того ж VPN-ендпойнту; пред’явіть дельту провайдеру.
• Симптом: «Продуктивність погіршилася після оновлення firewall.»
  Корінна причина: Обмеження крипто-пропускної здатності, малий CPU, невідповідний MTU або offload-функції, що спричиняють джитер.
  Виправлення: Виміряйте CPU і дропи інтерфейсів під навантаженням; запустіть iperf3 з кількома потоками; відключіть проблемні offload-и; масштабуйтесь.
• Симптом: «VPN відключається кожні кілька хвилин, особливо в idle.»
  Корінна причина: NAT timeouts, агресивне очищення станів або некоректна обробка UDP.
  Виправлення: Увімкніть keepalive для тунелю; налаштуйте UDP timeouts на firewall/NAT; перевірте, чи ISP не фільтрує UDP.
• Симптом: «RDP лагає, а масове копіювання файлів нормальне.»
  Корінна причина: Джитер і мікросплески; пакетна коалесценція; чергування, що не руйнує пропускну здатність.
  Виправлення: Виміряйте затримку під навантаженням; налаштуйте SQM; вимкніть offload-и, що пакують пакети; пріоритетизуйте інтерактивний трафік.
• Симптом: «Все погано тільки на Wi‑Fi.»
  Корінна причина: RF-інтерференція, проблеми роумінгу, поведінка power save або погане розташування AP.
  Виправлення: Відтворіть на проводі; якщо провід чистий, виправляйте Wi‑Fi — план каналів, мінімальний RSSI, band steering і оновлення драйверів.
• Симптом: «Ми бачимо втрати, але тільки маленькі ping-и проходять стабільно.»
  Корінна причина: Фрагментація/MTU або поліси, що відкидають більші пакети під навантаженням.
  Виправлення: Виконайте DF-ping-и з ростучими розмірами; налаштуйте MTU/MSS; перевірте, чи поліси не неправильно сконфігуровані на WAN/VPN інтерфейсах.

Пакет доказів для провайдера, який не можна ігнорувати

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

Що збирати (мінімальний набір квитанцій)

• Два тижні періодичного ping до публічної IP VPN-шлюзу (або хоча б кілька днів, включно з «поганими» вікнами).
• MTR-запуски під час хороших і поганих періодів до публічної IP VPN-шлюзу.
• Latenty-under-load тест, що демонструє bufferbloat (ping під час iperf3), якщо підозрюється конгестія.
• Результати iperf3 вперед і назад через VPN, щоб показати напрямок проблеми.
• MTU-тести, що показують, що ваш тунель налаштований адекватно (щоб вас не звинуватили у фрагментаційних чорних дірах).
• Метрики крайового офісу: WAN-утилізація, дропи інтерфейсів, CPU VPN-пристрою, часові мітки, зіставлені зі скаргами користувачів.

Як подати, щоб отримати дію

Тримайте коротко. Зробіть легко для перегляду. Провайдери — люди з чергами. Надайте:
ідентифікатор каналу, публічну IP, IP вашого VPN-шлюзу, IP клієнта для тестування, часові мітки з часовим поясом і однопараграфний
опис впливу («інтерактивний VPN-трафік непридатний 10:00–12:00 щодня; втрата до 1% і RTT-стрибки до 300 ms»).

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

Практична позиція щодо звинувачень

Не починайте зі звинувачень. Почніть з сегментації. «Втрати присутні від офісу до публічної IP VPN-шлюзу; LAN чистий;
тести у зворотному напрямку показують upstream-проблему.» Так ви примусите провайдера припинити пропонувати вам перезавантажити модем.

FAQ

1) У чому різниця між затримкою і джитером простими словами?

Затримка — це скільки часу пакет іде в обидва боки. Джитер — наскільки цей час варіюється. Люди більше ненавидять джитер, ніж помірну стабільну затримку.

2) Яка кількість втрат пакетів «прийнятна» для VPN?

Для інтерактивної роботи прагніть фактично до нуля. На практиці менше 0.1% зазвичай нормально; стійкі 0.5% помітні;
понад 1% спричиняють регулярні проблеми і звернення в підтримку.

3) Чи може ICMP ping вводити в оману?

Так. Деякі мережі лімітують ICMP або ставляться до нього інакше. Ось чому ви підкріплюєте його end-to-end тестами, як iperf3 ретрансмісіями,
затримкою під навантаженням і поведінкою додатків. Тим не менш, ping корисний, якщо його використовувати обережно.

4) Чому VPN стає гіршим під час відеодзвінків або резервних копій?

Тому що ви заповнюєте черги. На багатьох офісних лініях upstream обмежений, а буфери глибокі. Як тільки upstream-черга наповнюється, затримка стрибкоподібно зростає.
Тунель залишається, а користувацький досвід руйнується.

5) Який MTU слід встановити для WireGuard або IPsec?

Чарівного числа немає. Почніть з типового значення WireGuard близько 1420, потім перевірте DF-ping і tracepath. Для IPsec накладні витрати варіюються (NAT-T, алгоритми).
Вимірюйте, не вгадуйте.

6) Чи слід запускати iperf3 по продакшн-лінках у робочий час?

Так, але короткими контрольованими спалахами і з попередженням. 15-секундний тест зазвичай достатній, щоб виявити напрямок проблеми,
ретрансмісії і джитер під навантаженням. Не запускайте п’ятихвилинний saturation-тест і не дивуйтеся, що люди скаржаться.

7) Як довести, що VPN-пристрій — це вузьке місце, а не ISP?

Покажіть чисту продуктивність до публічної IP VPN-шлюзу, але погану продуктивність тільки через тунель. Потім зіставте з CPU VPN-пристрою, дропами інтерфейсів або лічильниками offload під той же час.

8) Наш провайдер каже «no problem found». Що далі?

Надайте часові серії доказів і сегментуйте шлях. Включіть хороші й погані MTR/ping, напрямність (iperf3 вперед vs назад) і результати затримки під навантаженням.
Якщо і після цього відмовляються, попросіть ескалацію до backbone/peering або просіть перенести канал — ввічливо, з квитанціями.

9) Чому я бачу втрати в MTR на проміжному хопі, але не на призначенні?

Той хоп може лімітувати ICMP-відповіді. Це може виглядати як «втрати» в звіті, тоді як фактична передача працює нормально.
Довіряйте end-to-end результатам більше, ніж hop-level ICMP-поведінці.

10) Чи правда, що Wi‑Fi дійсно так впливає на якість VPN?

Так. VPN підсилює проблеми Wi‑Fi: ретрансляції, переривання роумінгу та змінну затримку. Завжди відтворюйте на проводі перед ескалацією до ISP — якщо тільки скарга не про «Wi‑Fi + VPN».

Висновок: наступні кроки, що справді працюють

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

1. Визначіть цілі для затримки, джитера і втрат і зафіксуйте їх.
2. Інструментуйте шлях: запланований ping/MTR до публічного VPN-ендпойнта і до приватної внутрішньої цілі.
3. Перевірте MTU рано; виправте один раз і припиніть кожного кварталу знову знаходити ту саму проблему.
4. Вимірюйте під навантаженням, щоб виявити bufferbloat і напрямність проблем.
5. Зберіть пакет доказів з часовими мітками і сирими виходами; ескалуйте з сегментацією, а не відчуттями.
6. Виправляйте нудні речі: SQM, шейпінг, перенесення масових задач в неіші години і адекватний розмір VPN-шлюзу.

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