VPN-логи, що мають значення: знайти причини «не підключається» в логах MikroTik/Linux

October 29, 2025 • February 3, 2026 • Читання: 6 хв • Views: 6

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

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

Коли ноутбук CEO не підключається з готельного Wi‑Fi, який блокує половину інтернету, вам не потрібні здогади. Потрібні правильні логи, правильні команди та швидкий спосіб вирішити, чи йдеться про автентифікацію, маршрутизацію, крипто-невідповідність, NAT, MTU чи звичайне блокування файрволом.

Зміст

Які логи справді важливі (і чому більшість ні)
Швидкий план діагностики (перші/другі/треті перевірки)
Побудуйте ментальну модель: де живе правда
MikroTik: логування, що фіксує збої без потопу
Linux: journalctl, ядро та логи VPN-демонів, що працюють
Практичні завдання (команди + виходи + рішення)
Шаблони в логах, які відповідають реальним кореневим причинам
Поширені помилки: симптом → корінь → виправлення
Чеклисти / покроковий план (робочий процес для продакшену)
Три міні-історії з корпоративного світу (реалістичні, анонімізовані)
Цікаві факти й коротка історія (що пояснює сучасні болі)
ЧаПи
Висновок: наступні кроки, що зменшують повторення

Які логи справді важливі (і чому більшість ні)

Діагностика VPN — це гра на латентність: чим довше ви витрачаєте час на перегляд нерелевантного лог-шуму, тим довше ваші користувачі без зв’язку. Ваше завдання — зібрати достатньо доказів, щоб вибрати правильну гілку: автентифікація vs крипто vs мережевий шлях vs політика/маршрути.

Є лише кілька категорій логів, які послідовно відповідають на питання «чому не підключається?»

Логи рукостискання: переговори IKE/IPsec, TLS-рукостискання, WireGuard-хендшейки. Вони кажуть «не змогли домовитись» або «взагалі не дістались до пірінга».
Логи автентифікації/авторизації: помилки username/password, перевірка сертифікатів, рішення EAP, відповіді RADIUS. Вони кажуть «дістались, але сказали ні».
Логи файрволу/NAT: дропи та трансляції навколо UDP 500/4500, ESP, TCP 443/1194 тощо. Вони кажуть «пакети загинули тут».
Логи маршрутизації та політик: які маршрути встановлено, які селектори спрацювали, які політики застосовано. Вони кажуть «підключено, але марно».
Логи ядра/драйверів: проблеми MTU, фрагментація, дивні офлоади, збої інтерфейсів. Вони кажуть «фізика не згодна з вашою конфігурацією».

Що менш важливо, ніж здається: випадкові PPP «підключився/відключився» без контексту, загальні «peer not responding» без кореляції з захопленням трафіку або мегадебаги, зібрані постфактум без вирівняних часових міток між системами. Ваш перший крок — синхронізувати час, потім відфільтрувати до хвилини збою.

Надійна евристика: коли VPN «не підключається», причина зазвичай видно в одному з цих місць:

логи VPN-демона на клієнті (що він намагався)
логи VPN-демона на сервері (що він відхилив або взагалі не побачив)
логи краю мережі (що було заблоковано або пошкоджено)

Отримайте ці три погляди, зіставте часові мітки, і історія напише себе.

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

Перше: підтвердьте шлях (чи щось взагалі доходить?)

На MikroTik: перевірте дропи файрволу на порті/протоколах VPN та ініціаційні спроби IKE.
На Linux: перевірте вхідні пакети на очікуваному інтерфейсі, потім подивіться, чи зафіксував VPN-демон нову спробу рукостискання.

Рішення: якщо ви не бачите жодного трафіку на сервері/роутері в інтервалі спроби, ви не діагностуєте крипто. Ви діагностуєте досяжність (маршрути, файрвол, ISP, політика готельного Wi‑Fi).

Друге: класифікуйте збій (автентифікація vs переговори vs політика)

Помилки автентифікації: «AUTH_FAILED», «no shared key found», «EAP failure», «bad username or password», «certificate verify failed».
Помилки переговорів: «no proposal chosen», «invalid KE payload», «TS_UNACCEPTABLE», «encryption algorithm not supported».
Політика/маршрутизація: тунель піднявся, але немає маршрутів, неправильні селектори, трафік не співпадає з політикою, неправильні налаштування split-tunnel.

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

Третє: усуньте тихі вбивці (час, MTU, NAT‑T)

Час: перевірка сертифікатів і тайминги IKE ламаються при дрейфі годинників.
MTU: «підключається», але зависає; веб працює, а SMB помирає; великі пакети зникають.
NAT traversal: UDP 500 працює, поки не з’явився NAT; UDP 4500 заблоковано; ESP пошкоджено.

Рішення: якщо симптоми непослідовні в різних мережах (дома працює, в готелі — ні), підозрюйте MTU/NAT/заблоковані порти до того, як переписувати VPN.

Парафразована ідея (приписано): «Надія — не стратегія.» — Едсгер В. Дейкстра (парафразована ідея)

Побудуйте ментальну модель: де живе правда

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

Для типової налаштування віддаленого доступу (клієнт ↔ інтернет ↔ MikroTik ↔ Linux VPN-ендпоінт або сервіси) ваші джерела даних:

Логи клієнта: кажуть, що клієнт запропонував, чого очікував і що вважав фатальним.
Логи MikroTik: розповідають про IKE, L2TP/PPP, рішення файрволу та поведінку NAT на краю.
Логи VPN-демона на Linux: strongSwan, OpenVPN, інструменти WireGuard; кажуть причини на рівні протоколу.
Ядро Linux + netfilter: дропи пакетів, дивності conntrack/NAT, підказки про MTU/фрагментацію.
Логи AAA: RADIUS/LDAP або локальна база користувачів.

Вирівнювання годинників важливіше, ніж вам здається. Якщо MikroTik відстає на 90 секунд, а ваш Linux-хост синхронізований через NTP, ви «доведете» не те. Виправте час спочатку, потім ганяйте примари.

MikroTik: логування, що фіксує збої без потопу

MikroTik може бути напрочуд прямолінійним. Він скаже вам «no proposal chosen», і ви підете додому раніше. Або скаже «peer not responding», і ви витратите дві години, якщо не корелюєте це з лічильниками файрволу та потоками пакетів.

Що ввімкнути (і що тримати вимкненим)

Увімкніть логи, які фіксують:

ipsec — деталі переговорів на рівні info (а тимчасово на debug для одного джерела)
l2tp, ppp — для автентифікації та встановлення сесій (якщо ви використовуєте L2TP/PPTP/PPPoE)
firewall — для дропів у релевантних ланцюгах (обмежено, з rate-limit та цільовими правилами)

Уникайте постійного увімкнення повного debug. Дебаг-логи як кофеїн: корисні в момент критики, потім ви дивуєтесь, чому серце калатає й диск забитий.

Як виглядає «добре» в логах MikroTik

Для IPsec/IKEv2 «добре» часто включає:

peer ініціює
пропозиція прийнята
SA встановлено
політики інсталювані

Для L2TP/IPsec бажано бачити:

спочатку IPsec встановлено
потім піднімається L2TP контрольний канал
потім PPP автентифікація успішна

Якщо ви бачите лише першу половину, ви знаєте, куди цілитись.

Linux: journalctl, ядро та логи VPN-демонів, що працюють

Linux дає вам більше видимості, ніж ви заслуговуєте. Фішка не в зборі логів; фішка в тому, щоб ставити вузькі питання.

Джерела логів, що важливі

systemd journal через journalctl (більшість дистрибутивів)
/var/log/auth.log або /var/log/secure (PAM, SSH, деякі VPN-хуки автентифікації)
strongSwan логи (демон charon)
OpenVPN логи (вивід сервісу або файл логів)
ядро для xfrm/IPsec, WireGuard, netfilter дропів

Якщо можливо, направляйте логи сервісів у journald і використовуйте структуровану фільтрацію по unit. Grep по плоских файлах працює, але це 2025; ми можемо краще.

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

Ось завдання, які я реально виконую, коли VPN не підключається. Кожне містить команду, типовий вихід і рішення, що випливає з нього.

Завдання 1: Підтвердити вирівнювання системного часу (Linux)

cr0x@server:~$ timedatectl
               Local time: Sun 2025-12-28 15:40:11 UTC
           Universal time: Sun 2025-12-28 15:40:11 UTC
                 RTC time: Sun 2025-12-28 15:40:11
                Time zone: UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Значення: «System clock synchronized: yes» — те, що вам потрібно. VPN на базі сертифікатів буде падати дурними способами, якщо час неправильний.

Рішення: якщо синхронізація відсутня, виправте NTP перед діагностикою VPN. Інакше ви неправильно інтерпретуєте помилки сертифікатів і вікна відтворення.

Завдання 2: Перевірити, чи пакети доходять до Linux-сервера під час спроби

cr0x@server:~$ sudo tcpdump -ni eth0 'udp port 500 or udp port 4500 or proto 50' -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
15:41:02.101234 IP 198.51.100.23.55231 > 203.0.113.10.500: isakmp: phase 1 I ident
15:41:02.105991 IP 203.0.113.10.500 > 198.51.100.23.55231: isakmp: phase 1 R ident
15:41:03.220110 IP 198.51.100.23.55231 > 203.0.113.10.4500: UDP-encap: ESP(spi=0xcafebabe,seq=0x1)

Значення: У вас є досяжність і активність NAT‑T. Якщо тут тиша, проблема вгорі: файрвол, маршрути, ISP або клієнт взагалі не відправив пакети.

Рішення: Якщо пакети не приходять, припиніть крутити шифри. Почніть перевірку ACL, NAT і чи потрапляє клієнт на правильну IP-адресу.

Завдання 3: Логи strongSwan IKEv2 для класифікації помилок рукостискання

cr0x@server:~$ sudo journalctl -u strongswan --since "15:40" --no-pager
Dec 28 15:41:02 server charon[1123]: 09[IKE] received IKE_SA_INIT request from 198.51.100.23[55231]
Dec 28 15:41:02 server charon[1123]: 09[IKE] no proposal chosen
Dec 28 15:41:02 server charon[1123]: 09[IKE] sending NO_PROPOSAL_CHOSEN notify to 198.51.100.23[55231]

Значення: Крипто-невідповідність. Пірінг запропонував алгоритми, які ви не приймаєте (або навпаки).

Рішення: Вирівняйте пропозиції. Не «відкривайте все» назавжди; додайте мінімальний сумісний набір і заплануйте чистку.

Завдання 4: strongSwan «authentication failed» vs «not found»

cr0x@server:~$ sudo journalctl -u strongswan --since "15:40" --no-pager | tail -n 6
Dec 28 15:41:22 server charon[1123]: 11[IKE] authentication of 'vpnuser' with EAP failed
Dec 28 15:41:22 server charon[1123]: 11[IKE] sending AUTHENTICATION_FAILED notify
Dec 28 15:41:22 server charon[1123]: 11[IKE] IKE_SA closed

Значення: Мережевий шлях ок; облікові дані або інтеграція AAA — ні.

Рішення: Припиніть дивитись на правила файрволу. Перевірте RADIUS/LDAP, секрети користувачів і сумісність методу EAP.

Завдання 5: Статус рукостискання WireGuard (Linux)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 7E8sN8ZQk0yqJfYHk2m2pX1G4vQn4w2XhQ0v0n0n0n0=
  listening port: 51820

peer: GkYp9q3yR1l4tD0Nw7xqzK9uJm9c0q0H0e0o0r0e0r0=
  endpoint: 198.51.100.23:60211
  allowed ips: 10.66.66.2/32
  latest handshake: 2 minutes, 11 seconds ago
  transfer: 18.32 MiB received, 22.10 MiB sent
  persistent keepalive: every 25 seconds

Значення: Якщо «latest handshake» = «never», ви маєте справу з досяжністю, блокуванням портів або невідповідністю ключів.

Рішення: Якщо рукостискання є, але трафік не тече — фокус на AllowedIPs, маршрути та файрвол. Якщо рукостискання немає — фокус на UDP-досяжності та правильності ключів.

Завдання 6: Підказки в логах ядра WireGuard (Linux)

cr0x@server:~$ sudo journalctl -k --since "15:00" --no-pager | grep -i wireguard | tail
Dec 28 15:12:01 server kernel: wireguard: wg0: Handshake for peer 1 (198.51.100.23:60211) did not complete after 5 seconds, retrying (try 2)
Dec 28 15:12:06 server kernel: wireguard: wg0: No response from peer 1 (198.51.100.23:60211), retrying (try 3)

Значення: Вихідні пакети йдуть; відповіді не повертаються. Класичний NAT/файрвол/порт-форвард проблем.

Рішення: Перевірте фільтрацію вгору по ланцюгу, NAT-мапінги та чи правильні IP/порт ендпоінта.

Завдання 7: Логи сервісу OpenVPN (Linux)

cr0x@server:~$ sudo journalctl -u openvpn-server@server --since "15:40" --no-pager
Dec 28 15:41:10 server openvpn[2210]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec 28 15:41:10 server openvpn[2210]: TLS Error: TLS handshake failed

Значення: Зазвичай не проблема сертифіката; це досяжність (заблокований TCP/UDP порт) або асиметрична маршрутизація. Інколи — MTU.

Рішення: Перевірте відкритість порту і чи пакети доходять до демона. Якщо доходять — дивіться на невідповідність шифрів і TLS-налаштувань клієнта/сервера.

Завдання 8: Підтвердити, що Linux слухає очікувані порти

cr0x@server:~$ sudo ss -lunpt | egrep ':(500|4500|1194|51820)\b'
udp   UNCONN 0      0            0.0.0.0:4500      0.0.0.0:*    users:(("charon",pid=1123,fd=14))
udp   UNCONN 0      0            0.0.0.0:500       0.0.0.0:*    users:(("charon",pid=1123,fd=13))
udp   UNCONN 0      0            0.0.0.0:51820     0.0.0.0:*    users:(("wg-quick",pid=1300,fd=6))
udp   UNCONN 0      0            0.0.0.0:1194      0.0.0.0:*    users:(("openvpn",pid=2210,fd=5))

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

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

Завдання 9: Перевірити політику netfilter (Linux) без гадання

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    udp dport { 500, 4500, 51820, 1194 } accept
    ip protocol icmp accept
    counter drop
  }
}

Значення: Політика drop ок якщо ви явно дозволяєте порти/протоколи VPN. Якщо ви забули udp/4500, IKEv2 за NAT зазнає найбільш дратівного краху.

Рішення: Якщо відсутні дозволи — додайте їх; якщо вони є, перестаньте звинувачувати Linux-файрвол і дивіться далі по мережі.

Завдання 10: Підтвердити пересилання IP та здоров’я XFRM для IPsec

cr0x@server:~$ sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 0

Значення: Для site-to-site або маршрутизованого віддаленого доступу пересилання важливе. Деякі налаштування «підключаються», але не пропускають трафік, якщо forwarding вимкнено.

Рішення: Якщо forwarding вимкнено і ви очікуєте маршрутизований трафік — ввімкніть його та перевірте правила у ланцюзі forward.

Завдання 11: Перевірити IPsec SA на Linux (strongSwan)

cr0x@server:~$ sudo swanctl --list-sas
vpn-ikev2: #12, ESTABLISHED, IKEv2, 3c1f0b1f2d3e4a5b_i* 2a1b3c4d5e6f7a8b_r
  local  '203.0.113.10' @ 203.0.113.10[4500]
  remote '198.51.100.23' @ 198.51.100.23[60211]
  AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_256
  established 98s ago
  vpn-ikev2{21}:  INSTALLED, TUNNEL, reqid 7, ESP in UDP SPIs: c1234567_i c89abcde_o
  vpn-ikev2{21}:   10.10.10.0/24 === 10.66.66.2/32

Значення: «ESTABLISHED» плюс «INSTALLED» означає, що Phase 1 і Phase 2 вгору. Якщо трафік все ще не прямує, дивіться на маршрути, файрвол або невідповідність селекторів.

Рішення: Якщо CHILD_SA не інсталювався — виправте селектори/пропозиції для трафіку. Якщо інсталювався — трасуйте пакети після розшифрування.

Завдання 12: MikroTik: подивитись IPsec peers і активні SA

cr0x@server:~$ ssh admin@mtk-edge 'ip ipsec active-peers print; ip ipsec installed-sa print'
 0  address=198.51.100.23 port=60211 state=established phase1-established=yes
 0  spi=0xcafebabe src-address=203.0.113.1 dst-address=198.51.100.23 state=mature
    auth-algorithm=sha256 enc-algorithm=aes-gcm enc-key-size=256

Значення: Peer established + installed SA означає, що край бачить реальний тунель, а не просто бажання його бачити.

Рішення: Якщо peer не встановлено — працюйте над переговорами/автентифікацією. Якщо встановлено, але немає трафіку — інспектуйте маршрути, винятки NAT і правила forward файрволу.

Завдання 13: MikroTik: тимчасово увімкнути таргетоване логування для IPsec і PPP

cr0x@server:~$ ssh admin@mtk-edge '/system logging add topics=ipsec,debug action=memory; /system logging add topics=ppp,info action=memory; /log print where topics~"ipsec|ppp"'
15:44:01 ipsec,debug initiate new phase 1 (Identity_Protection): 198.51.100.23[60211]<=>203.0.113.1[500]
15:44:02 ipsec,error no proposal chosen
15:44:03 ppp,info <l2tp-user> disconnected

Значення: «no proposal chosen» — негайна крипто-невідповідність. PPP-відключення після — побічний ефект.

Рішення: Вирішіть вирівнювання пропозицій IPsec насамперед. Не ганяйтеся за PPP, поки IPsec версія не стабільна.

Завдання 14: MikroTik: перевірити лічильники файрволу для портів VPN

cr0x@server:~$ ssh admin@mtk-edge '/ip firewall filter print stats where chain=input and (protocol=udp and (dst-port=500 or dst-port=4500))'
 0    chain=input action=accept protocol=udp dst-port=500,4500 in-interface=WAN packets=1823 bytes=219120
 1    chain=input action=drop in-interface=WAN packets=44 bytes=3520

Значення: У вас є accepts і якісь drops. Питання: чи ці дропи — саме ваш VPN, чи фоновий шум?

Рішення: Якщо accepts = 0 під час спроби — трафік не доходить або не співпадає з вашим правилом. Якщо drops стрибнули під час спроб — додайте специфічний accept перед drop.

Завдання 15: Підтвердити симптоми шляху MTU за допомогою ping DF (Linux)

cr0x@server:~$ ping -M do -s 1372 -c 3 10.66.66.2
PING 10.66.66.2 (10.66.66.2) 1372(1400) bytes of data.
From 10.10.10.1 icmp_seq=1 Frag needed and DF set (mtu = 1420)
From 10.10.10.1 icmp_seq=2 Frag needed and DF set (mtu = 1420)
From 10.10.10.1 icmp_seq=3 Frag needed and DF set (mtu = 1420)

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

Значення: Ви перевищуєте path MTU. Інкапсуляція VPN додає оверхед, і це часто виглядає як «підключається, але нічого не працює».

Рішення: Зменшіть MTU тунелю, зажміть TCP MSS або виправте блокування PMTUD. Не просто «вимикайте DF всюди» і закривайте справу.

Жарт #1: Проблеми з MTU — єдина мережева помилка, що може змусити VPN «працювати» і зіпсувати вам вихідні.

Шаблони в логах, які відповідають реальним кореневим причинам

Шаблон: «no proposal chosen» (IKE/IPsec)

Зазвичай означає: невідповідність шифрування/інтегритету/PRF/DH групи, або ви змішуєте припущення IKEv1 в конфігурації IKEv2.

Що робити: Порівняйте запропоновані пропозиції від клієнта з наборами, які приймає сервер. На MikroTik перевірте налаштування IPsec proposal; у strongSwan — перевірте ike= і esp= визначення. Тимчасово зробіть одну сторону більш дозволяючою, потім звужуйте.

Шаблон: «AUTHENTICATION_FAILED»

Зазвичай означає: неправильні облікові дані, невідповідний рядок ідентичності, несумісність сертифіката або політика RADIUS, що відхиляє користувача.

Що робити: Перевірте ID, який клієнт пред’являє (FQDN/email/DN), і що сервер очікує. У сертифікатних налаштуваннях перевірте EKU, SAN і довірчий ланцюг. В EAP — підтвердіть сумісність методу (EAP-MSCHAPv2 vs EAP-TLS).

Шаблон: «peer not responding» / таймаути

Зазвичай означає: пакети не повертаються. Блокування файрволом, поламані NAT, неправильна IP-адреса призначення, асиметричний маршрут або заблокований UDP 4500.

Що робити: Захоплення пакетів на обох кінцях. Якщо бачите вихідні, але немає вхідних — переходьте до мережі. Якщо бачите вхідні, а демон мовчить — ви б’єте по неправильному хосту/порту або місцевий файрвол/SELinux їх з’їдає.

Шаблон: тунель встановлено, але «немає трафіку»

Зазвичай означає: неправильні маршрути/AllowedIPs/селектори, відсутній виняток NAT або forward chain файрвол блокує після розшифрування.

Що робити: Для IPsec перевірте інсталовані політики/селектори. Для WireGuard перевірте AllowedIPs з обох боків і підтвердіть, що маршрути існують. Потім трасуйте з tcpdump на внутрішньому інтерфейсі, а не тільки на WAN.

Шаблон: переривчасте підключення залежно від мережі

Зазвичай означає: граничні випадки NAT traversal, MTU/PMTUD або каптивні портали, що блокують UDP.

Що робити: Примусьте NAT‑T (де доречно), тестуйте альтернативні порти/протоколи (наприклад, OpenVPN на TCP 443) і зажміть MSS. Логи покажуть таймаути і повторні передачі; ваше завдання — зв’язати їх з середовищем мережі.

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

1) Симптом: «працює вдома, падає в готелі»

Корінь: UDP заблоковано або пошкоджено; NAT‑T UDP 4500 заблоковано; каптивний портал; або суворі політики файрволу.

Виправлення: Запропонуйте TCP‑фолбек (часто TCP 443), переконайтеся, що NAT‑T увімкнено для IPsec, та логьте дропи файрволу на WAN для портів VPN.

2) Симптом: «IKE_SA встановлено, але немає внутрішнього доступу»

Корінь: відсутні маршрути, неправильні селектори трафіку, відсутній виняток NAT або drop у forward chain.

Виправлення: Перевірте інсталювані CHILD_SA селектори, додайте маршрути, додайте явні allow-правила після розшифрування і переконайтеся, що ви не NAT-уєте трафік, який має бути захищеним.

3) Симптом: «authentication failed» одразу після переговорів

Корінь: неправильна ідентичність (IDi/IDr), неправильний метод EAP, RADIUS відхиляє, неповний довірчий ланцюг сертифікатів.

Виправлення: Логьте пред’явлену ідентичність, вирівняйте ID-налаштування, перевірте довірчий ланцюг сертифікатів на сервері та перевірте логи AAA для причин відмови.

4) Симптом: OpenVPN «TLS handshake failed», але порт відкритий

Корінь: невідповідність TLS-налаштувань клієнта/сервера (tls-crypt/tls-auth), невідповідність шифрів або MTU, що викликає фрагментацію рукопотискання.

Виправлення: Порівняйте конфіги; тимчасово спростіть до відомого доброго набору шифрів/TLS-налаштувань, потім поступово закріпляйте. Перевірте MTU та налаштування фрагментації.

5) Симптом: WireGuard «latest handshake: never»

Корінь: неправильний endpoint, UDP заблоковано, неправильний публічний ключ або NAT вимагає persistent keepalive.

Виправлення: Перевірте ключі та endpoint; додайте keepalive для клієнтів за NAT; підтвердіть UDP‑досяжність з tcpdump.

6) Симптом: VPN підключається, веб працює, файлові шарінги зависають

Корінь: проблеми MTU/MSS. Малі пакети проходять; великі пакети гинуть.

Виправлення: Зажміть TCP MSS на тунельному інтерфейсі/краю, зменшіть MTU та переконайтеся, що ICMP «frag needed» не блокується.

7) Симптом: L2TP/IPsec підключається для деяких користувачів, інші падають

Корінь: індивідуальні PPP-секрети, невідповідності профілів, різниця атрибутів RADIUS або вичерпання пулу адрес.

Виправлення: Перевірте логи PPP автентифікації, підтвердіть доступність IP-пулу, стандартизуйте профілі і порівняйте відповіді AAA.

8) Симптом: site-to-site IPsec флапає що кілька хвилин

Корінь: невідповідність DPD, невідповідність таймінгів рекієків, таймаути NAT-мапінгів або нестабільне WAN-з’єднання.

Виправлення: Вирівняйте lifetimes і DPD; перевірте помилки WAN; розгляньте keepalive; логьте події рекієків і корелюйте з станом інтерфейсу.

Чеклисти / покроковий план (робочий процес для продакшену)

Чеклист A: тріаж за 10 хвилин (не будьте надто хитрі)

Отримайте точне вікно часу помилки і тип мережі клієнта (додому/мобільна/готель).
Підтвердіть, що DNS резолвить на очікувану публічну IP (уникайте «неправильного призначення»).
Перевірте, що час сервера/роутера і Linux вирівняні.
На Linux запустіть tcpdump для UDP 500/4500 (або релевантного порту) під час нової спроби.
На MikroTik перевірте лічильники файрволу та логи IPsec/PPP для тієї самої хвилини.
Класифікуйте: відсутній трафік, помилка переговорів, помилка автентифікації або «вгору але без даних».
Обирайте одну гіпотезу і перевірте її одним зміною або однією командою.

Чеклист B: глибоке дослідження переговорів/автентифікації (коли пакети доходять)

Витягніть точний рядок помилки з логів демона VPN (NO_PROPOSAL_CHOSEN, AUTHENTICATION_FAILED, TS_UNACCEPTABLE).
Перелічіть налаштовані пропозиції сервера і порівняйте з підтримуваним набором клієнта.
Перевірте ланцюг сертифікатів, терміни дії й поля ідентичності (SAN, CN тощо).
Перегляньте логи AAA (RADIUS/LDAP) на причини відхилення; не вгадуйте.
Повторно протестуйте. Якщо помилка змінилася — ви просунулись. Якщо ні — ви не просунулись.

Чеклист C: «підключено, але нічого не працює» (підступний випадок)

Підтвердіть, що SA встановлений і селектори відповідають очікуваним підмережам.
Підтвердіть наявність маршрутів з обох боків (та на клієнті для split-tunnel).
Підтвердіть, що файрвол дозволяє трафік після розшифрування (ланцюг forward, а не тільки input).
Підтвердіть виняток NAT для VPN-підмереж (не NAT-уйте внутрішній трафік, якщо не маєте на це наміру).
Тестуйте MTU за допомогою DF ping або зажимайте MSS і повторіть тест.

Жарт #2: VPN не «впав». Він просто практикує chaos engineering, не попередивши вас.

Три міні-історії з корпоративного світу (реалістичні, анонімізовані)

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

Хелпдеск ескалував «VPN-аут» о 8:17 ранку. Симптом був чистий: частина віддалених користувачів не могла підключитися, ті, хто могли — переважно з домашнього широкосмугового інтернету. Користувачі з мобільного були в порядку. Усі звинуватили сертифікати, бо хтось минулого тижня «оновив щось».

Перше неправильне припущення: «якщо деякі користувачі можуть підключитись, сервер VPN здоровий». Це емоційно заспокоює, іноді правда, але саме так ви пропускаєте залежні від шляху збої, як фільтрація UDP і NAT‑T. Друге неправильне припущення: «якщо IPsec, то це крипто». Ні. IPsec часто — мережева політика в крипто-одязі.

Ми підняли tcpdump на Linux-ендпоінті: нічого не надходило на UDP 4500 під час спроб. Лічильники MikroTik для UDP 4500 були плоскі, тоді як UDP 500 просів. Це підказка: клієнти за NAT починають на UDP 500, потім переходять на UDP 4500 для NAT traversal. Вони застрягли на вході.

Причина була марною: новий upstream шаблон файрволу дозволяв UDP 500, але не UDP 4500. У шаблоні було написано «IPsec», тож всі думали, що все ок. Ми додали UDP 4500, побачили, як логи strongSwan змінилися від таймаутів до встановлених SA, і інцидент закрився.

Постмортем висновок не був «пам’ятайте UDP 4500». Це: ніколи не діагностуйте «не підключається», не довівши, чи трафік доходить до пристрою на порт, який йому справді потрібен.

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

Мережева команда вирішила «зменшити шум логів» на MikroTik-краю, вимкнувши більшість VPN-пов’язаного логування і покладаючись на центральний Linux syslog з рівня застосунку. Мотив був зрозумілий: бюджет зберігання, втома від оповіщень і дашборд, що виглядав як сейсмограф.

Через два тижні розгортання IKEv2 почало падати для конкретної популяції клієнтів. Linux-ендпоінт показував спорадичні «received packet with unknown SPI» і випадкові AUTH помилки. Але послідовної картини не було, і у нас не було логів краю, щоб показати, чи трафік NAT-иться, дропиться або транслюється дивним чином.

Ми знову увімкнули таргетовані MikroTik IPsec-логи і додали одне правило файрволу з лічильниками для UDP 500/4500. За хвилину з’явилась історія: правило NAT перепроставляло певні діапазони джерел по-іншому, що призводило до зміни портів джерела посеред рукостискання. strongSwan сприймав це як підозрілу поведінку, і рукостискання ломалися періодично.

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

Після цього команда зменшила шум, але зберегла здатність відтворити інцидент. Ось різниця між спостережливістю і накопиченням даних.

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

Інша організація зробила небазарну річ: стандартизувала тріаж збоїв VPN у маленький рунбук. Кожний інцидент починався з тих самих трьох захоплень: час спроби клієнта, лічильники краю і логи демона сервера. Вони також примусово увімкнули NTP на кожному MikroTik і Linux-хості і тестували це щомісяця як дорослі.

Коли «VPN не підключається» трапився під час демонстрації вендора, вони не сперечалися про вину. Вирівняли часові мітки і подивилися вікно перекриття. Край показав вхідні UDP 500 пакети, потім нічого на UDP 4500. tcpdump сервера показав те саме. Це звузило коло до upstream-фільтрації або політики мережі клієнта.

Користувач був на гостьовому Wi‑Fi, що блокував UDP 4500. Наступний крок у рунбуку був задокументований фолбек: OpenVPN на TCP 443 з явним фільтром логів для підтвердження TLS рукостискання. Вони переключили профіль, побачили «TLS negotiation succeeded», і демо продовжилося з мінімальною нервозністю.

Рятівна практика не була модною. Це був фолбек і звичка підтверджувати досяжність пакетів перед переписуванням конфігів. Нудно, але виграє. Повісьте це над еспресо-машиною в офісі.

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

Початковий корпоративний поштовх IPsec був у 1990-х, коли «безпека на мережевому рівні» звучала як панацея. Вона не спростила все, але стандартизувала багато VPN-термінології.
IKEv2 (середина 2000-х) був створений, щоб виправити складність IKEv1 і покращити мобільність та NAT traversal, але він все ще сильно залежить від правильних пропозицій і ідентичностей.
NAT не проектувався з урахуванням IPsec. ESP (протокол 50) не має портів, що ускладнює класичні NAT-пристрої; NAT‑T загортає ESP в UDP 4500 як прагматичну латку.
VPN епохи PPP (L2TP/PPTP) лишилися через простоту розгортання, а не через якість. Логи досі показують PPP-помилки автентифікації, які не мають нічого спільного з крипто.
WireGuard став масовим завдяки мінімалізму: менше регуляторів, менше режимів сумісності, а отже менше «таємничих» помилок переговорів — коли він падає, то зазвичай це очевидно.
OpenVPN популяризував «VPN поверх TCP/443» як тактику виживання в обмежених мережах, хоча TCP-over-TCP може призвести до проблем з продуктивністю.
Біль MTU посилився з ростом шифрування: кожен шар інкапсуляції краде байти, а сучасні мережі часто блокують ICMP, потрібний для PMTUD.
Практики логування змінились із systemd: journald полегшив фільтрацію по unit і часовому вікну, що саме те, що потрібно для тріажу VPN.

ЧаПи

1) Якщо VPN «не підключається», куди дивитись першим: клієнт, MikroTik чи Linux?

Почніть там, де можна довести прибуття пакетів. Якщо ви контролюєте сервер, запустіть tcpdump і перевірте логи демона. Якщо пакети не бачите — переходьте до краю MikroTik і вищезгаданого шляху.

2) Чому я бачу UDP 500 пакети, але не UDP 4500?

Багато клієнтів починають IKE на UDP 500 і переходять на UDP 4500 при виявленні NAT. Відсутність UDP 4500 зазвичай означає політику файрвола або upstream‑фільтрацію, а не крипто.

3) Що насправді означає «no proposal chosen»?

Піри не змогли домовитись про алгоритми (шифрування/інтегритет/PRF/DH група) для IKE або ESP. Вирівняйте набори пропозицій; не вмикайте випадково застарілі набори без розуміння ризику.

4) Тунель встановлено, але внутрішні підмережі недосяжні. Чи це ще проблема VPN?

Так, але це вже не handshake-проблема. Це маршрути, правила forward файрволу, винятки NAT або селектори/AllowedIPs. Перевірте SAs і маршрути, потім трасуйте трафік після розшифрування.

5) Чому WireGuard показує рукостискання, але все одно немає трафіку?

Зазвичай це AllowedIPs або маршрути. Рукостискання доводить лише ключі і досяжність; воно не доводить, що ви маршрутизуєте правильні підмережі через тунель або дозволяєте їх у файрволі.

6) Який найшвидший спосіб підтвердити, що Linux-файрвол не блокує VPN?

Перегляньте правила (nft list ruleset) і підтвердіть явні дозволи для портів/протоколів VPN, плюс лічильники, якщо є. Не «флаште iptables» в продакшені, якщо вам не подобаються інцидент-репорти.

7) Чи варто назавжди увімкнути debug-логи на MikroTik і strongSwan?

Ні. Увімкніть таргетований debug на короткий час, бажано по часовому вікну і за IP-джерелом, якщо можна, потім вимкніть. Тримайте легкі info-логи і лічильники постійно.

8) Як зрозуміти, що це MTU?

Класична ознака: маленькі запити працюють, великі передачі зависають; деякі додатки підключаються, інші зависають. Підтвердьте DF ping тестами і зажиманням MSS. Логи часто показують повторні передачі/таймаути, а не «MTU» яскравими літерами.

9) Якщо OpenVPN по TCP 443 працює всюди, чи варто просто використовувати його?

Це корисний фолбек, але не завжди основний вибір. TCP-over-TCP може стати проблемою при втраті пакетів. Використовуйте його, коли треба пробити обмежені мережі, і вимірюйте перед тим, як стандартизувати.

10) Яка одна звичка найменше знижує інциденти VPN?

Дисципліна часових міток: NTP повсюди і звичка збирати час спроби клієнта, лічильники краю і логи демона сервера для тієї самої хвилини.

Висновок: наступні кроки, що зменшують повторення

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

Стандартизуйте швидкий план (прибуття трафіку → класифікація помилки → перевірка часу/MTU/NAT‑T) і зробіть його стандартною відповіддю.
Тримайте таргетоване логування завжди ввімкненим: MikroTik IPsec info-логи, лічильники файрволу для портів VPN і логи демона Linux у journald.
Відпрацьовуйте один фолбек для обмежених мереж (часто TCP 443) і тестуйте його періодично.
Зробіть MTU/MSS перевірку першокласною для інцидентів «підключається, але непридатний» — бо це трапляється постійно, і заперечення цього не допоможе.

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

Схожі статті

Ubuntu 24.04 «Connection reset by peer»: доведіть, хто винен — клієнт, проксі чи сервер (випадок №74)