Контрольний список маршрутизації VPN між сайтами для випадків «не можу дістатися іншого боку»

Практична ментальна модель: пакети, а не тунелі

«VPN між сайтами» звучить як магічний міст між місцями. У виробництві це менше поезії, більше сантехніки:
пакети покидають хост, проходять рішення маршрутизації, можливо NAT-яться, можливо фільтруються, можливо інкапсулюються, перетинають інтернет,
потім деккапсулюються, знову фільтруються, маршрутизуються і нарешті доставляються (або ні).

Коли хтось каже «VPN працює», перекладіть це як: «обмін ключами вдало пройшов, і можливо існують Phase 2 селектори».
Це твердження не гарантує, що плейн даних пропускає трафік наскрізь. Воно не гарантує наявність маршрутів,
не гарантує винятків NAT, не гарантує, що відповідний трафік повертається тим самим шляхом, і точно не гарантує, що MTU вас не саботує.

Два режими VPN, які не можна плутати

Більшість простоїв у цій категорії починається з прихованого розбіжності очікувань. Ключова різниця:

• IPsec на основі політик: шифрування відбувається, коли трафік відповідає селекторам «цікавого трафіку» (traffic selectors / proxy IDs).
  Маршрутизація часто «звичайна», але VPN-пристрій вирішує, що шифрувати, базуючись на парах підмереж джерела/призначення.
• IPsec на основі маршрутів: ви маєте віртуальний інтерфейс (VTI/тунельний інтерфейс). Ви маршрутизуєте до цього інтерфейсу.
  Шифрування відбувається тому, що пакет маршрутизується в тунельний інтерфейс, а не тому, що він відповідає списку селекторів (хоча селектори під капотом все одно є).

Якщо одна сторона вважає, що це policy-based, а інша — route-based, ви можете отримати тунель, що «піднявся»,
але плейн даних поводитиметься як мертва риба.

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

Цитата, яку варто тримати в рукописі запуску, належить John Allspaw і часто повторюється в колах надійності:
«перефразована ідея»: людська помилка — симптом глибших проблем у системі; виправляйте систему, а не людину.
Застосуйте це тут: «неправильний маршрут» рідко є просто «хтось неправильно набрав маршрут». Зазвичай це відсутність запобіжників, погана видимість або нечітка відповідальність.

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

Ви хочете швидко знайти вузьке місце. Не ідеально. Швидко. Ось порядок, який зазвичай дає відповідь за кілька хвилин.

Перший: доведіть, чи входить трафік до тунелю взагалі

• З хоста на Стороні A пінгуйте або виконайте TCP-тест до хоста на Стороні B.
• На шлюзі VPN Сторони A перевірте лічильники IPsec SA (байти/пакети). Якщо вони не рухаються, ви не відповідаєте селекторам або не маршрутизуєте в тунель.
• Захопіть трафік на внутрішньому інтерфейсі: чи бачите ви незашифрований пакет, що приходить на шлюз?

Другий: доведіть, чи виходить трафік з тунелю на іншому кінці

• На шлюзі VPN Сторони B перевірте лічильники SA. Якщо Сторона A інкрементує, а Сторона B — ні, ймовірно проблеми з ISP/ACL/NAT-T або неправильний peer/PSK/ID (менш ймовірно, коли тунель «up»).
• Захопіть трафік на внутрішньому інтерфейсі Сторони B: чи бачите ви деккапсульований пакет, що йде в бік підмережі призначення?

Третій: доведіть, що шлях повернення достатньо симетричний

• Більшість проблем «працює в один бік» — це маршрут повернення або проблеми з NAT.
• З Сторони B ініціюйте трафік назад на Сторону A. Не припускайте, що state допоможе вам.
• Перевірте таблиці маршрутів на хості призначення або його шлюзі за замовчуванням: чи знає він маршрут назад у віддалену підмережу через VPN-шлюз?

Жарт №1: Якщо тунель «працює», але нічого не проходить — вітаємо, ви побудували дуже безпечний шредер пакетів.

Цікаві факти та контекст (бо це допомагає)

• IPsec з’явився в 1990-х як частина історії безпеки IPv6, а потім став практичним доповненням для IPv4. Така історія пояснює, чому багато концепцій IPsec виглядають «пристикованими».
• IKEv1 проти IKEv2 — це не лише синтаксис. IKEv2 загалом краще поводиться при переконфігурації ключів і мобільності та зменшує деякі типи збоїв, але вендори все ще відрізняються дефолтами й нюансами сумісності.
• Селектори «Phase 2» прийшли з політичної VPN-логіки. Навіть route-based тунелі все одно узгоджують traffic selectors під капотом; деякі вендори використовують 0.0.0.0/0, щоб «ловити все», інші наполягають на явних списках.
• NAT-Traversal (NAT-T) існує тому, що NAT зламав ESP. ESP не є TCP/UDP, тож класичні NAT-пристрої не знали, що з ним робити; NAT-T інкапсулює ESP в UDP/4500, щоб це пережило.
• Path MTU Discovery крихкий при інкапсуляції. Додайте накладні витрати IPsec, і раніше безпечний шлях з MTU 1500 починає “пожирати” фрагменти.
• «Security associations» (SAs) мають час життя і поведінку ренеймінгу. Баги у ренеймінгу, проблеми з годинником або невідповідні терміни життя можуть спричиняти періодичні інциденти «кожну годину відмирає».
• Деякі вендори реалізують route-based тунелі як policy VPN під капотом. Вони висувають тунельний інтерфейс, але все одно покладаються на селектори та правила відповідності, що важливо при додаванні нових підмереж.
• BGP поверх IPsec став популярним у хмарних VPN, бо це перетворює статичне керування маршрутами на динамічне — поки ваші таймери BGP і стан брандмауера не почнуть суперечити.
• Трекінг стану брандмауера — часто невидима третя сторона. Недостатньо, щоб маршрути були правильні; stateful-інспекція може відкидати асиметричний трафік повернення навіть коли маршрути існують.

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

Контрольний список A: визначте проблему у термінах пакета

• IP джерела (хост, не шлюз)
• IP призначення
• Протокол/порт (ICMP проти TCP/443 має значення)
• Напрямок (A→B, B→A або обидва)
• Це «немає маршруту», «таймаут» чи «відмова у з’єднанні»?

Якщо ви не можете назвати цю 5-ку, ви відлагоджуєте за відчуттями.

Контрольний список B: підтвердіть домен шифрування / намір маршрутизації

• Які підмережі повинні проходити через VPN (локальні та віддалені)? Перелічіть їх.
• Це селектори на основі політик, чи маршрутний VTI?
• Чи є накладання адресного простору? (Якщо так, зупиніться і плануйте NAT або перейменування.)
• Очікується поділ тунелю (split tunneling) або весь трафік має йти через тунель?

Контрольний список C: підтвердіть три площини управління

• Крипто-площина управління: IKE встановлено, IPsec SAs інстальовано, ренеймінг стабільний.
• Площина маршрутів: маршрути на обох сторонах для віддалених підмереж, правильний next-hop, немає більш-специфічного маршруту, що витікає.
• Площина політик: правила брандмауера дозволяють трафік; є виняток NAT (або правильний NAT); security groups/NACLs узгоджені.

Контрольний список D: підтвердіть плейн даних наскрізь

• Пакет доходить до шлюзу на внутрішньому інтерфейсі (захоплення).
• Пакет інкрементує лічильники IPsec (байти SA).
• Пакет з’являється на внутрішньому інтерфейсі дальнього кінця (захоплення).
• Пакет повернення йде зворотним шляхом (маршрути + NAT + стан).

Контрольний список E: не дайте себе вбити MTU

• Тестуйте з DF встановленим і змінними розмірами корисного навантаження.
• Защемляйте MSS на вході тунелю, якщо не довіряєте PMTUD.
• Шукайте патерни «пінг працює, HTTPS падає».

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

Нижче практичні завдання, які можна виконати під час інциденту. Кожне має: команду, приклад виводу, що це означає і яке рішення прийняти.
Команди припускають Linux-ендпоїнти/шлюзи та strongSwan де релевантно, але логіка переноситься на фаєрволи й хмарні роутери.

Завдання 1: перевірте, що локальний хост маршрутизує до VPN-шлюзу (а не в інтернет)

cr0x@server:~$ ip route get 10.40.5.10
10.40.5.10 via 10.20.0.1 dev eth0 src 10.20.1.50 uid 1000
    cache

Значення: хост відправить трафік до 10.40.5.10 через 10.20.0.1.
Якщо 10.20.0.1 — не ваш VPN-шлюз (або роутер, що знає про VPN), ви ніколи не потрапите в тунель.

Рішення: якщо next hop неправильний — виправте маршрут на хості або на верхньому роутері (статичний маршрут або динамічна маршрутизація).

Завдання 2: перевірте, що VPN-шлюз має маршрут до віддаленої підмережі

cr0x@server:~$ ip route show 10.40.0.0/16
10.40.0.0/16 dev vti0 proto static scope link

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

Рішення: додайте/відновіть маршрут або виправте поширення маршрутів (BGP, хмарні таблиці маршрутів).

Завдання 3: перевірте наявність IKE/IPsec SAs (strongSwan)

cr0x@server:~$ sudo swanctl --list-sas
vpn-siteA-siteB: #12, ESTABLISHED, IKEv2, 3c2a9c1e0e3b1a2f_i* 6f1d2b7c8a9e0d1c_r
  local  'gw-siteA' @ 203.0.113.10[4500]
  remote 'gw-siteB' @ 198.51.100.20[4500]
  AES_GCM_16-256/PRF_HMAC_SHA2_256/ECP_256
  established 214s ago
  vpn-siteA-siteB{27}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c1a2b3c4_i c4b3a2c1_o
  vpn-siteA-siteB{27}:   10.20.0.0/16 === 10.40.0.0/16
  vpn-siteA-siteB{27}:   bytes_i 0, packets_i 0, bytes_o 8420, packets_o 71

Значення: SA інстальовано; селектори трафіку 10.20/16 до 10.40/16.
Вихідні лічильники інкрементують, вхідні — нулі: Сторона A відправляє зашифрований трафік, але не отримує відповідей (або вони не відповідають селекторам).

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

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

cr0x@server:~$ sudo tcpdump -ni eth1 host 10.40.5.10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:02:11.102334 IP 10.20.1.50.51124 > 10.40.5.10.443: Flags [S], seq 245112233, win 64240, options [mss 1460,sackOK,TS val 902211 ecr 0,nop,wscale 7], length 0

Значення: внутрішній пакет доходить до шлюзу. Добре. Якщо ви не бачите його, проблема вище по ланцюжку (хост-маршрут, VLAN, ACL, неправильний шлюз).

Рішення: якщо відсутній — не чіпайте IPsec; спочатку виправте маршрутизацію/L2/L3 до шлюзу.

Завдання 5: перевірте, чи зашифровані пакети виходять зі шлюзу до пірингу

cr0x@server:~$ sudo tcpdump -ni eth0 host 198.51.100.20 and udp port 4500
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:02:11.102901 IP 203.0.113.10.4500 > 198.51.100.20.4500: UDP, length 116
14:02:11.103122 IP 203.0.113.10.4500 > 198.51.100.20.4500: UDP, length 116

Значення: NAT-T інкапсульовані ESP-пакети виходять. Якщо ви бачите внутрішні пакети, але нема UDP/4500, ваша політика IPsec не співпадає або брандмауер блокує.

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

Завдання 6: підтвердіть, що пакети деккапсулюються на іншому кінці (захоплення на внутрішньому)

cr0x@server:~$ sudo tcpdump -ni eth1 host 10.20.1.50
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:02:11.145009 IP 10.20.1.50.51124 > 10.40.5.10.443: Flags [S], seq 245112233, win 64240, options [mss 1360,sackOK,TS val 902211 ecr 0,nop,wscale 7], length 0

Значення: на Стороні B ви бачите оригінальне джерело/призначення після деккапсуляції. Це доводить, що тунель переносить пакет.
Якщо ви не бачите цього, але бачите UDP/4500 на зовнішньому інтерфейсі, селектори можуть не співпадати, або VPN-пристрій відкидає через політику.

Рішення: виправте traffic selectors/proxy IDs або політико-орієнтовані правила, що визначають «цікавий трафік».

Завдання 7: перевірте політику і стан IPsec ядра Linux (xfrm)

cr0x@server:~$ sudo ip -s xfrm state
src 203.0.113.10 dst 198.51.100.20
    proto esp spi 0xc4b3a2c1 reqid 1 mode tunnel
    replay-window 32 flag af-unspec
    auth-trunc hmac(sha256) 0x0000000000000000000000000000000000000000000000000000000000000000 128
    enc cbc(aes) 0x0000000000000000000000000000000000000000000000000000000000000000
    anti-replay context: seq 0x0000002f, oseq 0x00000000, bitmap 0x00000000
    stats: replay-window 0 replay 0 failed 0 bytes 8452 packets 71
src 198.51.100.20 dst 203.0.113.10
    proto esp spi 0xc1a2b3c4 reqid 1 mode tunnel
    stats: replay-window 0 replay 0 failed 0 bytes 0 packets 0

Значення: вихідний ESP працює; вхідний — ні. Це підтверджує історію лічильників SA і штовхає вас у бік віддаленої маршрутизації/брандмауера або блокування на шляху.

Рішення: припиніть дискутувати «чи тунель вгорі». Він є. Тепер виправте, чому відповіді ніколи не повертаються.

Завдання 8: перевірте правила пересилання у фаєрволі (Linux nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iif "eth1" oif "vti0" ip saddr 10.20.0.0/16 ip daddr 10.40.0.0/16 accept
    iif "vti0" oif "eth1" ip saddr 10.40.0.0/16 ip daddr 10.20.0.0/16 accept
  }
}

Значення: політика forward — drop, але явні дозволи існують в обох напрямках. Якщо ви дозволяєте тільки в один бік, state tracking може не покрити всі потоки (особливо при асиметрії або UDP).

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

Завдання 9: виявіть NAT, який ламає домен шифрування

cr0x@server:~$ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.20.0.0/16 -o eth0 -j MASQUERADE

Значення: MASQUERADE буде NAT-ити весь трафік 10.20/16, що виходить eth0. Якщо ваш VPN-трафік виходить eth0 до застосування політики IPsec,
ви можете NAT-ити його і тоді він не співпаде з селекторами (або дальня сторона побачить невірний джерело й відкине).

Рішення: додайте виняток NAT для трафіку призначеного в 10.40/16 (або забезпечте, щоб політика застосовувалась перед NAT на вашій платформі).

Завдання 10: підтвердіть, що віддалена сторона знає, як повернутися до підмережі джерела

cr0x@server:~$ ip route get 10.20.1.50
10.20.1.50 via 10.40.0.1 dev eth0 src 10.40.5.10 uid 1000
    cache

Значення: цей хост (10.40.5.10) відправить трафік назад до 10.40.0.1 (його шлюз за замовчуванням), а не до VPN-шлюзу.
Якщо 10.40.0.1 не маршрутизує 10.20/16 через VPN, відповіді йдуть не туди і гинуть.

Рішення: додайте маршрути на кореневому роутері віддаленої мережі, або налаштуйте маршрутизацію так, щоб VPN-шлюз був на шляху повернення.

Завдання 11: виявлення асиметричної маршрутизації за допомогою traceroute (TCP під порт, який відповідає реальному трафіку)

cr0x@server:~$ traceroute -T -p 443 10.40.5.10
traceroute to 10.40.5.10 (10.40.5.10), 30 hops max, 60 byte packets
 1  10.20.0.1 (10.20.0.1)  0.324 ms  0.291 ms  0.276 ms
 2  * * *
 3  * * *
 4  10.40.5.10 (10.40.5.10)  9.812 ms  9.775 ms  9.741 ms

Значення: хоп 1 — ваш внутрішній шлюз, потім тиша (ймовірно тому, що хопи тунелю не посилають TTL exceeded), потім призначення.
Якщо ви бачите публічні хопи, ви не використовуєте VPN. Якщо ніколи не доходите до призначення — потрібні захоплення та лічильники.

Рішення: використовуйте traceroute як швидку перевірку здоров’я, а не як остаточний вердикт. Перейдіть до захоплень/лічильників наступним кроком.

Завдання 12: протестуйте MTU/PMTUD за допомогою ping з «do not fragment»

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

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

Значення: локальний інтерфейс MTU — 1400 (або шлях його обмежує), і ваше обране корисне навантаження не влазить з заголовками.
У світі VPN навіть LAN з MTU 1500 часто потребує меншого ефективного MTU через накладні витрати інкапсуляції.

Рішення: зменште MTU тунелю/інтерфейсу або защеміть TCP MSS. Якщо ICMP fragmentation-needed блокується, потрібно компенсувати явно.

Завдання 13: перевірте TCP MSS clamping (якщо ви його робите — переконайтеся, що він справжній)

cr0x@server:~$ sudo iptables -t mangle -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A FORWARD -o vti0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Значення: SYN-пакети, що пересилаються у vti0, отримують MSS, підлаштований під PMTU. Це зменшує проблеми «великі передавання зависають».

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

Завдання 14: підтвердіть, що пересилання увімкнено (класичний Linux-шлюз)

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

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

Рішення: увімкніть пересилання і зробіть це постійним, потім повторно протестуйте. Також переконайтеся, що forward chain брандмауера дозволяє це.

Завдання 15: підтвердіть, що піринг досяжний і порти не заблоковані (4500/500)

cr0x@server:~$ sudo nc -uvz 198.51.100.20 4500
Connection to 198.51.100.20 4500 port [udp/*] succeeded!

Значення: не остаточно для UDP (бо «succeeded» — best-effort), але якщо це жорстко падає через маршрутизацію або локальний брандмауер, це підказка.

Рішення: якщо ви навіть не можете спробувати UDP/4500 — виправте upstream ACLs або локальний egress-фільтр перед тим, як чіпати налаштування IKE.

Завдання 16: спостерігайте флапи ренеймінгу/DPD у логах (strongSwan)

cr0x@server:~$ sudo journalctl -u strongswan --since "10 minutes ago" | tail -n 12
Dec 27 14:01:22 gw strongswan[1123]: 15[IKE] peer supports MOBIKE
Dec 27 14:01:22 gw strongswan[1123]: 15[IKE] IKE_SA vpn-siteA-siteB[12] established between 203.0.113.10[gw-siteA]...198.51.100.20[gw-siteB]
Dec 27 14:01:22 gw strongswan[1123]: 15[CHD] CHILD_SA vpn-siteA-siteB{27} established with SPIs c1a2b3c4_i c4b3a2c1_o and TS 10.20.0.0/16 === 10.40.0.0/16
Dec 27 14:03:01 gw strongswan[1123]: 07[IKE] sending DPD request
Dec 27 14:03:31 gw strongswan[1123]: 07[IKE] DPD response received
Dec 27 14:05:22 gw strongswan[1123]: 15[CHD] CHILD_SA vpn-siteA-siteB{27} rekeyed

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

Рішення: якщо флапає — дивіться на таймаути NAT-пристроїв UDP-мапінгів, таймаути бездіяльності, агресивні DPD-настройки або невідповідні тайминги/алгоритми.

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

1) «Тунель вгорі, не можу нікого пінгнути»

• Симптом: IKE встановлено, але байтові лічильники SA залишаються нульовими.
• Причина: маршрути не відправляють трафік у тунель або селектори політики не відповідають фактичним IP джерела/призначення.
• Виправлення: перевірте ip route get і селектори VPN; додайте відсутні маршрути або оновіть proxy IDs/TS пари.

2) «Працює зі Сторони A до Сторони B, але не назад»

• Симптом: вихідні байти SA інкрементуються на одній стороні; вхідні лишаються плоскими. TCP SYN видно в один бік; немає SYN-ACK.
• Причина: відсутній маршрут повернення на шлюзі за замовчуванням віддаленої підмережі; асиметрична маршрутизація; stateful-брандмауер скидати відповіді поза станом.
• Виправлення: додайте віддалений маршрут для підмережі джерела через VPN-шлюз; переконайтесь, що брандмауер дозволяє обидва напрямки; уникайте «one-arm» конструкцій без ретельної обробки стану.

3) «Пінги працюють, HTTPS зависає або передавання файлів стопориться»

• Симптом: малі пакети проходять; більші — ні; TCP-сесії встановлюються, а потім заморожуються.
• Причина: MTU/PMTUD чорна діра через накладні витрати IPsec і блокування ICMP fragmentation-needed.
• Виправлення: защеміть TCP MSS на вході тунелю; зменшіть MTU інтерфейсу/тунелю; дозвольте потрібні типи ICMP там, де це безпечно.

4) «Працює лише одна підмережа; нова підмережа не дістається»

• Симптом: старі мережі передають трафік; новий CIDR мертвий.
• Причина: селектори/proxy IDs не оновлені на обох сторонах; хмарні таблиці маршрутів не оновлені; відсутній NAT-виняток для нової підмережі.
• Виправлення: оновіть селектори на обох пірінгах; поширіть маршрути (статично/BGP/хмара); віддзеркальте NAT-винятки та правила брандмауера.

5) «Перерви кожні N хвилин»

• Симптом: трафік працює, потім коротко помирає, потім повертається; логи показують ренеймінг.
• Причина: невідповідні таймери ренеймінгу, таймаути NAT-мапінгів, агресивні DPD-настройки або баги сумісності криптоалгоритмів.
• Виправлення: вирівняйте терміни життя; встановіть поміркований DPD; тримайте NAT-T живим; оновіть прошивки; розгляньте IKEv2 де можливо.

6) «Все працювало, поки ми не увімкнули NAT»

• Симптом: тунель вгорі, але віддалена сторона бачить трафік з несподіваною IP-адресою; політики не співпадають.
• Причина: NAT застосовано до трафіку, призначеного в VPN, до шифрування (або NAT змінив джерело на інший, ніж у селекторі/proxy ID).
• Виправлення: налаштуйте виняток NAT; або спеціально спроектуйте «NAT всередині тунелю» і оновіть селектори та віддалені маршрути відповідно.

Жарт №2: NAT — це як програма захисту свідків для пакетів — чудово, поки суд не попросить їх справжню особистість.

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

Міні-історія 1: відмова через хибне припущення

Компанія купує невеликого постачальника і потребує швидкого VPN між сайтами, щоб фінанси могли «просто отримати доступ до ERP».
Мережна команда з боку покупця налаштувала маршрутний тунель з VTI і додала маршрути для підмережі постачальника.
UI брандмауера показує зелений. Усі йдуть додому, відчуваючи себе компетентними.

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

Приховане припущення: «Якщо наша сторона маршрутизує в тунель, інша сторона природно відправить назад».
На стороні постачальника шлюз за замовчуванням — інший роутер, і той роутер не має уявлення, що 10.20.0.0/16 є за VPN.
Пакети повернення йдуть в інтернет, відкидаються системами анти-спуфінгу й зникають.

Виправлення було нудним: статичний маршрут на кореневому роутері постачальника, що вказує 10.20.0.0/16 на їх VPN-шлюз, плюс правила брандмауера для дозволу потоків.
Коли маршрут повернення став правильним, усе почало працювати миттєво. Ніхто не міняв криптовстановлення.

Урок: «Тунель вгорі» — це не контракт щодо маршрутизації. Зробіть шлях повернення явним, письмово, перед переключенням.

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

Інша організація хотіла «оптимізувати» пропускну здатність VPN для нічних реплік.
Хтось помітив, що MTU тунельного інтерфейсу була встановлена низько «для безпеки» і вирішив підняти її до 1500, бо «LAN — 1500 і джамбо-кадри — сучасність».
Вони також відключили MSS-clamping, бо «це зайва обробка».

Декілька годин було начебто добре. Пінги працювали. Малі API виклики працювали. Реплікація стартувала… і потім застопорилася.
Це не було чистим відмовленням. Гірший вид: напівпрацює, повний хаос.
TCP-сесії встановлювалися, а потім гальмували під навантаженням. Ретрансмісії зростали. Графіки затримок ставали пилкоподібними.

Справжня проблема була в PMTUD-чорній діри. Шлях через інтернет фактично не міг нести 1500-байтові внутрішні пакети після додавання IPsec-інкапсуляції.
ICMP fragmentation-needed блокувався десь вгору по ланцюгу (ніхто не міг довести, де саме, бо звісно).
Великі пакети зникали, і TCP продовжував крутитись, поки не здихався.

«Оптимізація» створила систему, яка падала саме за умов, які повинна була покращити.
Виправлення — повернути MTU, увімкнути MSS-clamping і додати моніторинг, що сигналізує про зростання ретрансмісій для реплікаційних потоків.
Пропускна здатність стабілізувалась, і всі робили вигляд, що експеримент був успішним, тому що він їх чомусь навчив.

Урок: зміни MTU — це зміни в продакшні. Ставтеся до них так само, як до миграції схеми бази даних — плануйте, тестуйте, швидко відкочуйте.

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

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

Одного вечора у вікні змін додали нову підмережу на Стороні A.
Передбачувано, нова підмережа не могла дістатися до Сторони B. Старі підмережі працювали.
Інженеру на зміні не потрібно було плекати племінні знання; він відкрив трафік-контракт і побачив список селекторів і потрібні шаблони винятків NAT.

Він виконав тестування з документа: лічильники SA не інкрементувалися для нової підмережі, але інкрементувалися для старої.
Це прямо вказало на селектори/proxy IDs. Він оновив обидві сторони, застосував конфіг і підтвердив, що лічильники пішли.
Усього за годину, без гадань і без «може це DNS».

Урок: нудна документація, що піддається операційному тестуванню, краща за винахідливість. Особливо о 2-й ранку, коли ваша винахідливість спить.

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

1) Якщо IKE встановлено, хіба це не доводить, що VPN працює?

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

2) Який найшвидший спосіб з’ясувати, чи мій трафік відповідає селекторам?

Дивіться лічильники CHILD_SA/SA під час генерації трафіку з реального джерела на реальне призначення.
Якщо лічильники не рухаються, ваш трафік не шифрується (неправильні селектори, неправильні маршрути або втручання NAT).

3) Policy-based чи route-based: що обрати?

Віддавайте перевагу route-based (VTI), коли можете. Воно узгоджується зі звичною маршрутизацією, краще масштабується при зміні підмереж і добре працює з динамічною маршрутизацією, як BGP.
Policy-based підходить для невеликих статичних середовищ, але кожна нова підмережа стає переговором з вашим майбутнім «я».

4) Чому пінг працює, а мій застосунок — ні?

ICMP echo малий і толерантний. Застосунки часто використовують TCP з більшими сегментами і чутливі до PMTUD-збоїв.
Це класична зона MTU/MSS: тестуйте з DF-пінгами і защеміть MSS, якщо потрібно.

5) Чи потрібно дозволяти ICMP через VPN?

Потрібно достатньо ICMP для здорової роботи, особливо fragmentation-needed (для PMTUD) і базові інструменти діагностики.
Якщо політика забороняє його, компенсуйте консервативним MTU і MSS-clamping і прийміть зменшену видимість.

6) Як накладання підмереж ламає site-to-site VPN?

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

7) Що таке «NAT-виняток» і чому він важливий?

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

8) Коли варто використовувати BGP через VPN?

Використовуйте, коли маєте багато підмереж, часті зміни або кілька тунелів/шляхів.
Це зменшує проблему статичних маршрутів. Але моніторьте його: піднятий BGP-сеанс не гарантує працездатності плейн даних, а налаштування таймерів може створити флапи.

9) Що означає «асиметрична маршрутизація» в цьому контексті?

Запит іде A→B через VPN, але відповідь іде B→A іншим шляхом (часто інтернетом або іншим тунелем).
Statefull-брандмауери цього не люблять, і навіть безстанні механізми можуть скидати через анти-спуфінг.

10) Що стандартизувати між тунелями, щоб зменшити інциденти?

Стандартизуйте: інвентар доменів шифрування/підмереж, метод маршрутизації (віддавайте перевагу VTI), політику MSS-clamping, таймери DPD/ренеймінгу та операційний тест-набір
(кілька пінгів/TCP-перевірок + перевірка байтових лічильників SA + точка захоплення).

Висновок: що зробити наступного разу до того, як зламалося

Коли «не можу дістатися іншого боку», стримайте спокусу перш за все чіпати криптонастройки. Більшість збоїв — це маршрутизація, NAT, політика брандмауера або MTU.
Розглядайте тунель як хоп; відлагоджуйте шлях пакета.

Практичні наступні кроки, які ви можете зробити цього тижня:

• Напишіть односторінковий трафік-контракт для кожного site-to-site VPN: підмережі, метод маршрутизації, очікування щодо NAT і команди для тестування.
• Додайте моніторинг, що сигналізує, якщо байтові лічильники SA не рухаються під час відомих вікон трафіку (або при сплеску ретрансмісій для ключових потоків).
• Уніфікуйте MSS-clamping (або перевірений MTU) між тунелями, щоб не переобчислювати ту саму чорну діру знову і знову.
• Під час змін тестуйте явно обидва напрямки. Успіх в один бік — це передвісник відмови, а не перемога.

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