Маршрутний чи політико-базований VPN: що краще для офісів і чому

Що таке маршрутні й політико-базовані VPN насправді

Політико-базований VPN: «порахуй трафік, потім зашифруй»

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

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

Саме тому політико-базовані VPN поширені на старому обладнанні та «SMB-рівні» фаєрволів: їх легко пояснити й швидко розгорнути
для однієї підмережі до однієї підмережі. Плату доводиться сплачувати пізніше — з відсотками.

Маршрутний VPN: «створи інтерфейс, потім маршрутизуй через нього»

Маршрутні VPN створюють логічний тунельний інтерфейс (часто VTI: Virtual Tunnel Interface) і дозволяють таблиці маршрутів вирішувати,
що має піти через тунель. Шифрується будь-що, що прокладено через цей інтерфейс (плюс те, що дозволяє ваша IPsec-політика, але суть у тому:
його проектують як мережу, а не як купу винятків).

Ментальна модель: маршрутизація керує пересиланням; політика безпеки контролює дозволи. Таке розділення — золото в операціях.
Це означає, що ви можете робити звичні речі: динамічну маршрутизацію (BGP/OSPF), резервування маршрутів, багато підмереж без комбінаційного вибуху
й адекватну діагностику («який маршрут ми обрали?» — краще питання, ніж «який із 37 селекторів співпав?»).

Що люди мають на увазі (і де плутаються)

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

• Чи є реальний тунельний інтерфейс з IP-адресою? (Зазвичай так для маршрутного, ні для чисто політико-базованого.)
• Чи можна встановлювати маршрути (статичні або динамічні), що вказують на тунель?
• Чи потрібно перераховувати кожну пару локальна/віддалена підмережа? (Зазвичай так для політико-базованого.)
• Чи можна запускати BGP через нього? (Маршрутний зазвичай полегшує це.)
• Як веде себе відмовостійкість? (Маршрутний може бути чистішим; політико-базований — «збиваючим з пантелику».)

Одна цитата, яку варто мати на видному місці, бо вона описує всю роботу в реченні:
«Надія — не стратегія.» — Gene Kranz

Політико-базовані VPN тримаються на надії частіше, ніж команди готові визнати. Вони працюють, поки не з’явиться нова підмережа, або хтось
не попросить active/active, або команда хмари не захоче BGP. Тоді селектори стають крихким нагромадженням припущень.

Реальність офісу: що змінює все

Офіси — це безлад. Вони ростуть у ширину. Вони успадковують VLAN принтерів із 2014 року, гостьовий Wi‑Fi із 2017 року і «тимчасову» підмережу,
додану для підрядника, який так і не пішов. Дизайн VPN, що переживе офісне середовище, має вміти:

• Багато підмереж на сайт (користувачі, голос, камери, IoT, сервери, гість, OT).
• Часті зміни (нові SaaS-з’єднання, новий DNS, винятки для split-tunnel).
• Поглинання компаній (накладання простору RFC1918 — не теоретична проблема; це подія в календарі).
• Кілька провайдерів (dual ISP, LTE резерв, підкладки SD-WAN).
• Змішані вендори (бо звісно ж на одному кінці Forti, на іншому Palo, з «корисним» NAT посередині).
• Тиск політики безпеки (сегментація з нульовою довірою, аудит, MFA для адміністрування та «заборонити все за замовчуванням»).

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

Що краще для офісів (і винятки)

Стандартна рекомендація: маршрутний для майже всіх офіс‑до‑офісу і офіс‑до‑датацентру VPN

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

Маршрутні VPN також краще працюють з реальними потребами:

• Динамічна маршрутизація (особливо BGP) для багатьох сайтів, хмарних підключень і логіки резервування.
• Багато підмереж без вибуху селекторів (один тунель, багато маршрутів).
• Чистіше HA (відстежуйте тунельний інтерфейс, BGP-сесію, відкликайте маршрути).
• Менш крихке управління змінами (додавання підмережі = «додати маршрут + правило фаєрволу», а не «додати N селекторів»).

Коли політико-базований все ще підходить

Політико-базований VPN прийнятний, коли:

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

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

Де команди отримують опік: «тунель вгору» ≠ «трафік працює»

Політико-базовані VPN люблять показувати зелені лампочки: IKE встановлено, IPsec встановлено, байти рухаються. Тим часом новий VLAN не може дістатися кудись,
бо його селектори ніколи не додали, або NAT підкрався й змінив вихідну IP, або віддалений кінець суворий і мовчки відкидає трафік, що не відповідає.

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

Жарт №1: Політико-базований VPN — як список запрошених VIP. Працює чудово, доки ваша компанія продовжує наймати людей.

Що означає «краще» операційно

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

• Спостережуваність: таблиці маршрутів, статистика інтерфейсів, стан BGP, стандартні інструменти.
• Безпека змін: менші diff-и, менше зв’язаних умов.
• Масштабованість: додавання сайтів/підмереж не множить конфігураційні об’єкти по обох кінцях.
• Сумісність: хаби хмари й сучасні фаєрволи дедалі частіше очікують маршрутних патернів.

Матриця рішень: оберіть за 5 хвилин

Оберіть маршрутний, якщо правда будь‑яке з цього

• У вас більше ніж дві підмережі на будь‑якому з кінців, або очікуєте це протягом року.
• Вам потрібне резервування, яке не ляже монетою (dual ISP, dual hub, active/active).
• Ви хочете BGP (або можете захотіти його пізніше).
• У вас є хмарні VPN у тій чи іншій формі (більшість хмарних шлюзів орієнтовані на маршрути).
• Потрібно підсумовувати маршрути або мати справу з накладаннями підмереж через NAT.
• Ви хочете відлагоджувати звичними інструментами: маршрути, ping, tcpdump, лічильники.

Оберіть політико-базований, якщо всі ці пункти істинні

• Це невелике, стабільне, статичне з’єднання підмережа‑до‑підмережі.
• Ніякої динамічної маршрутизації. Ніякої складної HA. Ніякого очікуваного зростання.
• Реалізація маршрутного на платформі слабка або відсутня.
• Ви можете документувати селектори і тримати їх синхронізованими на обох кінцях.

Оберіть «маршрутний, але з запобіжниками» для більшості офісів

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

Цікаві факти й контекст для нарад

1. IPsec починався як рівень безпеки для IPv6 у 1990-х, потім широко застосувався для IPv4, бо реальність завжди перемагає.
2. «Proxy IDs» походять від ранніх ідей селекторів IPsec: визначати точно, який трафік слід захищати — підходить для епохи підмереж‑до‑підмережі.
3. Virtual Tunnel Interfaces (VTI) стали популярними, коли вендори зрозуміли, що операторам потрібен IPsec, який поводиться як GRE: інтерфейс, через який можна маршрутувати.
4. IKEv2 (стандартизація близько 2005) виправив багато недоліків IKEv1, особливо щодо переговорів і стійкості.
5. NAT-Traversal існує, бо інтернет — брудний: UDP-інкапсуляція (зазвичай 4500) була прагматичним рішенням для пристроїв NAT, що ламали IPsec.
6. Хмарні VPN продукти підштовхнули до маршрутної практики, бо хмари хочуть таблиці маршрутів і динамічну маршрутизацію, а не таблиці селекторів.
7. SD-WAN прискорив мислення «тунель як інтерфейс»: підкладки змінюються, оверлеї маршрутизують; селектори політики погано адаптуються.
8. Маршрутний не означає «будь‑з‑ким» за замовчуванням: вам все ще потрібна політика фаєрволу і фільтри маршрутів. Різниця в тому, що їх можна керувати окремо.

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

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

Середня компанія мала політико-базований site-to-site VPN між HQ і філією. Він працював роками: одна /24 на філії,
кілька /24 в HQ. Зелені лампочки всюди. Ніхто не чіпав.

Потім філія додала другий VLAN для VoIP-телефонів. Інженер на філії додав VLAN, DHCP
і припустив: «VPN все перенесе, бо це той самий тунель». Із таких припущень народжуються відмови.

Телефони зареєструвалися на локальний PBX? Добре. Телефони, що зверталися до централізованого кол-менеджера в HQ? Мертві. Тим часом VPN усе ще показував «up»,
бо існуючі підмережі все ще співпадали з селекторами і підтримували трафік. Моніторинг цього не виявив, бо перевірка була ping із
старої підмережі.

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

Після цього компанія перейшла на маршрутні тунелі для філій. Сьогодні те саме змінення — додати VLAN, додати анонс маршруту,
додати правило фаєрволу. Моніторинг пінгує кілька VLAN, а не одну «спадщину, що працює».

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

Інша організація хотіла «оптимізувати» свій VPN, звузивши селектори, щоб зменшити «зайве шифрування».
Вони мали політико-базований тунель з багатьма парами підмереж, і хтось вирішив прибрати широкі селектори та залишити тільки «активні».
На папері це зменшило конфігураційний безлад.

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

Аварія тривала довше, бо люди ганялися за неправильним рівнем: логи застосунків, DNS, потім правила фаєрволу, потім ISP.
Лише пізніше хтось порівняв захоплення пакетів і помітив, що трафік зовсім не заходив у IPsec.

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

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

Компанія з понад 40 офісами працювала на маршрутному IPsec з BGP до двох регіональних хабів. Нічого особливого. «Нудною» практикою була їхня дисципліна змін:
у кожного офісу стандартна план-префіксів, фільтри маршрутів і передзмінний список тестів, що включав перевірку MTU і досяжністі для кожного VLAN.

Одного дня оновлення фаєрволу на хабі внесло іншу поведінку за замовчуванням щодо TCP MSS clamp. Раптом передачі файлів з деяких офісів уповільнились.
Затримка в нормі; ping працював; маленькі HTTP-запити — теж. Великі SMB-копії — жах.

У їхньому рунабу було швидке перевірення PMTU і лічильників інтерфейсу IPsec. За хвилини вони побачили фрагментацію та повторні пересилки.
Вони підкоригували MSS clamp на тунельних інтерфейсах хаба і підтвердили поліпшення. Жодних ескалацій до вендора. Жодних звинувачень ISP.

Практика, що врятувала їх, була не хитрим трюком. Це була стандартизація + повторювані тести + видимість маршрутизації.
Коли ваш VPN поводиться як інтерфейс з маршрутами, легше визначити, де щось пішло не так.

Жарт №2: Найшвидший спосіб навчитись налагоджувати VPN — запланувати «швидку» зміну фаєрволу перед довгими вихідними.

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

Це перевірки для операторів, які можна виконати з Linux-хостів, фаєрволів з shell-доступом або з jumphost поруч з кінцевими станціями.
Суть не в команді; а в тому, яке рішення ви приймаєте за результатом.

1) Підтвердить очікуваний маршрут (перевірка маршрутної логіки)

cr0x@server:~$ ip route get 10.40.12.20
10.40.12.20 via 169.254.21.2 dev vti0 src 169.254.21.1 uid 1000
    cache

Значення: Трафік до 10.40.12.20 піде через vti0 до next hop тунелю. Добре.
Рішення: Якщо показує ваш дефолтний шлюз, виправте маршрутизацію (статичний маршрут, BGP, route-map) перед тим, як чіпати IPsec.

2) Перевірте наявність IPsec SA і їх перебіг (приклад strongSwan)

cr0x@server:~$ sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.8, Linux 6.8.0, x86_64):
  uptime: 2 hours, since Dec 28 09:11:02 2025
Connections:
 office-hub:  169.254.21.1...203.0.113.10  IKEv2
Security Associations (1 up, 0 connecting):
 office-hub[12]: ESTABLISHED 37 minutes ago, 198.51.100.20[198.51.100.20]...203.0.113.10[203.0.113.10]
 office-hub{7}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c2f4a1d2_i c8a19f10_o
 office-hub{7}:   169.254.21.1/32 === 169.254.21.2/32

Значення: IKEv2 встановлено; ESP встановлено; селектори — host/32 на кінцях VTI (типово для маршрутного патерну).
Рішення: Якщо немає SA, зосередьтеся на IKE-непереговорах, PSK/сертифікатах, NAT-T і UDP-доступності.

3) Переконайтесь, що трафік справді шифрується (перегляньте XFRM stats)

cr0x@server:~$ ip -s xfrm state
src 198.51.100.20 dst 203.0.113.10
    proto esp spi 0xc8a19f10 reqid 1 mode tunnel
    replay-window 32 flag af-unspec
    auth-trunc hmac(sha256) 0x... 128
    enc cbc(aes) 0x...
    anti-replay context: seq 0x0000007b, oseq 0x0000007b, bitmap 0xffffffff
    stats: replay-window 0 replay 0 failed 0 bytes 981234 packets 812 add 2025-12-28 09:15:01 use 2025-12-28 10:02:31

Значення: Лічильники пакетів/байтів, що зростають, означають, що трафік іде через IPsec.
Рішення: Якщо лічильники стоять на місці, а застосунки падають — ваша маршрутизація/політика не спрямовує трафік у тунель
(або селектори не співпадають у політико-базованому випадку).

4) Виявлення проблем MTU/PMTU (класичний біль офісних VPN)

cr0x@server:~$ ping -M do -s 1372 10.40.12.20 -c 3
PING 10.40.12.20 (10.40.12.20) 1372(1400) bytes of data.
1380 bytes from 10.40.12.20: icmp_seq=1 ttl=61 time=21.3 ms
1380 bytes from 10.40.12.20: icmp_seq=2 ttl=61 time=21.1 ms
1380 bytes from 10.40.12.20: icmp_seq=3 ttl=61 time=21.2 ms

--- 10.40.12.20 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms

Значення: PMTU щонайменше ~1400 байт енд‑ту‑енд. Добре для багатьох IPsec-шляхів.
Рішення: Якщо бачите «Frag needed», встановіть TCP MSS clamp на тунельному інтерфейсі або зменшіть MTU. Якщо таймаути тільки для великих пакетів — підозрюйте PMTU-фільтрацію.

5) Розгляньте PMTU за допомогою tracepath (знайдіть, де падає)

cr0x@server:~$ tracepath 10.40.12.20
 1?: [LOCALHOST]                      pmtu 1500
 1:  169.254.21.2                                           2.123ms
 2:  10.40.12.20                                           21.004ms reached
     Resume: pmtu 1400 hops 2 back 2

Значення: Виявлений PMTU — 1400. Це нормально з врахуванням накладних витрат ESP.
Рішення: Якщо показує pmtu 1500, але великі TCP пригальмовують — підозрюйте, що десь блокується ICMP, і поставте MSS clamp.

6) Переконайтесь, що DNS не є «відмовою VPN»

cr0x@server:~$ resolvectl query fileserver.corp.example
fileserver.corp.example: 10.40.12.20                         -- link: vti0

-- Information acquired via protocol DNS in 19.9ms.
-- Data is authenticated: no

Значення: Ім’я резолвиться в віддалений IP і резольвер асоціює його з тунельним інтерфейсом.
Рішення: Якщо DNS вказує на публічні IP або неправильні внутрішні діапазони — виправте split-DNS або умовну передачу перед тим, як звинувачувати IPsec.

7) Доведіть, що TCP‑handshake працює (або ні)

cr0x@server:~$ nc -vz 10.40.12.20 445
Connection to 10.40.12.20 445 port [tcp/microsoft-ds] succeeded!

Значення: VPN і політика фаєрволу дозволяють SMB до цього хоста.
Рішення: Якщо встановлення з’єднання таймаутиться, вирішіть, чи це маршрутизація (немає шляху для відповіді), політика фаєрволу (заборонено) або селектори IPsec (політико-базований невідповідний).

8) Перегляньте лічильники інтерфейсу на тунелі на предмет дропів

cr0x@server:~$ ip -s link show dev vti0
6: vti0@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1436 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
    RX:  bytes  packets  errors  dropped  missed  mcast
      18922310   152233       0       12       0       0
    TX:  bytes  packets  errors  dropped  carrier collsns
      20100291   160112       0        0       0       0

Значення: Дропи на RX можуть вказувати на чергу/MTU/політику або проблеми з обробкою в ядрі/xfrm.
Рішення: Якщо дропи ростуть під час передач — зосередьтеся на MTU/MSS і CPU; якщо дропів немає, а застосунок не працює — дивіться політику фаєрволу або віддалений хост.

9) Підтвердьте BGP‑сусідство через тунель (сила маршрутного)

cr0x@server:~$ sudo vtysh -c "show ip bgp summary"
BGP router identifier 169.254.21.1, local AS number 65010
Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd
169.254.21.2    4      65000    8123    7991      144    0    0 03:12:44        37

Значення: BGP вгору кілька годин і отримує 37 префіксів. Ось як виглядає «маршрутизаційно-керований VPN».
Рішення: Якщо BGP флапає — поводьтеся з тунелем як з WAN: перевірте втраченість у підкладці, MTU, DPD-таймери і CPU перед тим, як чіпати route-фільтри.

10) Знайдіть витоки маршрутів або відсутні маршрути (те, що ви анонсуєте, має значення)

cr0x@server:~$ sudo vtysh -c "show ip route 10.40.12.0/24"
Routing entry for 10.40.12.0/24
  Known via "bgp", distance 20, metric 0, best
  Last update 00:02:11 ago
  * 169.254.21.2, via vti0

Значення: Префікс існує і досяжний через тунель.
Рішення: Якщо маршрут відсутній — зупиніться. Не дебажте IPsec. Спочатку виправте анонс/імпорт маршруту.

11) Підтвердьте, що селектори політики збігаються (загальна діагностика через захоплення пакетів)

cr0x@server:~$ sudo tcpdump -ni eth0 host 203.0.113.10 and udp port 4500 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:04:11.201122 IP 198.51.100.20.4500 > 203.0.113.10.4500: UDP-encap: ESP(spi=0xc8a19f10,seq=0x0000007c), length 148
10:04:11.221009 IP 203.0.113.10.4500 > 198.51.100.20.4500: UDP-encap: ESP(spi=0xc2f4a1d2,seq=0x00000080), length 148

Значення: Ви бачите ESP-in-UDP. Якщо генеруєте тестовий трафік і не бачите пакети ESP — він не заходить в IPsec.
Рішення: У політико-базованих налаштуваннях це зазвичай означає невідповідність селекторів або те, що NAT змінив внутрішні адреси.

12) Перевірте conntrack на предмет асиметричних симптомів

cr0x@server:~$ sudo conntrack -L -p tcp --dport 445 | head
tcp      6 431999 ESTABLISHED src=10.20.5.44 dst=10.40.12.20 sport=51234 dport=445 src=10.40.12.20 dst=10.20.5.44 sport=445 dport=51234 [ASSURED] mark=0 use=1

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

13) Переконайтесь, що NAT не саботує ваші селектори

cr0x@server:~$ sudo iptables -t nat -S | sed -n '1,20p'
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -o eth0 -j MASQUERADE

Значення: Широке правило MASQUERADE може перезаписувати вихідні IP, ламати селектори політики та ускладнювати дебаг маршрутного підходу.
Рішення: Додайте винятки NAT для VPN-цілей або звузьте область NAT до «тільки інтернету».

14) Спостерігайте CPU і softirqs під час скарг на пропускну здатність (шифрування коштує ресурсів)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0 (vpn-gw1) 	12/28/2025 	_x86_64_	(8 CPU)

10:06:31 AM  CPU   %usr   %nice %sys %iowait  %irq %soft  %steal  %idle
10:06:32 AM  all   12.10   0.00  9.88   0.00  0.00  21.44    0.00  56.58
10:06:33 AM  all   10.34   0.00  8.91   0.00  0.00  24.10    0.00  56.65
10:06:34 AM  all   11.02   0.00  9.33   0.00  0.00  25.89    0.00  53.76

Значення: Високий %soft може свідчити про навантаження на обробку пакетів (часто VPN + NAT + фільтрація).
Рішення: Якщо CPU зашкалює в робочі години — вам потрібна апаратна крипто‑акселерація, кращий розмір пристрою або оптимізація трафіку.

15) Виміряйте пропускну здатність iperf3 (припиніть здогади)

cr0x@server:~$ iperf3 -c 10.40.12.20 -t 10 -P 4
Connecting to host 10.40.12.20, port 5201
[SUM]   0.00-10.00  sec   842 MBytes   707 Mbits/sec  sender
[SUM]   0.00-10.00  sec   839 MBytes   704 Mbits/sec  receiver

Значення: Маєте ~700 Mbps реальної пропускної здатності через тунель у тестових умовах.
Рішення: Якщо пропускна низька, але затримка нормальна — дивіться MTU/MSS, CPU крипто або обмеження/шейпінг на підкладці.

16) Перевірте DPD/keepalive у логах (стабільність тунелю)

cr0x@server:~$ sudo journalctl -u strongswan --since "10 minutes ago" | tail -n 8
Dec 28 10:00:01 vpn-gw1 charon[1123]: 12[IKE] sending DPD request
Dec 28 10:00:01 vpn-gw1 charon[1123]: 12[IKE] received DPD response, peer alive
Dec 28 10:05:01 vpn-gw1 charon[1123]: 12[IKE] sending DPD request
Dec 28 10:05:01 vpn-gw1 charon[1123]: 12[IKE] received DPD response, peer alive

Значення: Пір відповідає. Підкладка не померла, стан підтримується.
Рішення: Якщо DPD періодично падає — підозрюйте втрати у провайдера, таймаути NAT або агресивні таймаути UDP у фаєрволах.

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

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

Спочатку: це маршрутизація, шифрування чи політика?

1. Перевірте маршрут з хоста поблизу джерела:
   ip route get <remote_ip>.
   Якщо він не вказує на тунель/VTI — зупиніться і виправте маршрути.
2. Перевірте стан SA і лічильники:
   IKE встановлено? ESP встановлено? Зростають байти/пакети при генерації трафіку?
   Якщо SA вниз — виправляйте IKE/підкладку. Якщо SA вгору, але лічильники стоять — це проблема зі спрямуванням/селекторами.
3. Перевірте політику фаєрволу на шляху даних:
   чи можна виконати nc -vz до порту? Якщо ні — перевірте правила і маршрути повернення.

Друге: відокремте «ping працює» від «працює для реального трафіку»

1. Тест PMTU з ping -M do і tracepath. Якщо великі пакети падають — встановіть MSS clamp або зменшіть MTU.
2. Тест пропускної здатності з iperf3. Якщо він значно нижчий за пропускну здатність лінії — перевірте CPU, softirqs і шейпінг.
3. Захоплення пакетів на публічному інтерфейсі: чи бачите ESP/UDP 4500 при генерації трафіку?

Третє: перевірте симетрію і шлях повернення

1. Conntrack або таблиця станів: чи потоки доходять до ESTABLISHED або застрягають в SYN_SENT?
2. Таблиця маршрутів на віддаленій стороні: чи знає вона, як дістатися до вашого вихідного префіксу через тунель?
3. Фільтри маршрутів (якщо використовується динамічна маршрутизація): чи випадково ви не заблокували новий префікс?

Швидка ідентифікація вузьких місць

• Висока затримка + втрати: підкладка ISP, NAT-пристрій, LTE‑резерв або перевантаження провайдера.
• Низька пропускна здатність, затримка нормальна: MTU/MSS, обмеження CPU на крипто, QoS політика або обмеження одиночного потоку.
• Одна підмережа працює, інша — ні: невідповідність селекторів політики або відсутній маршрут/анонс.
• Працює лише в одному напрямку: відсутній маршрут повернення, асиметрична маршрутизація або stateful фаєрвол відкидає трафік.

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

1) «Тунель вгору, але новий VLAN не дістається до HQ»

Симптоми: Існуючі підмережі працюють; нова підмережа падає; сторінка статусу VPN зелена.
Корінь: У політико-базованому — селектори не оновлені на обох кінцях; у маршрутному — не оновлено анонс маршрутів.
Виправлення: Для політико-базованого: додайте співпадаючі локальні/віддалені селектори (proxy IDs) в обох напрямках і забезпечте виняток NAT.
Для маршрутного: анонсуйте або додайте статичні маршрути, потім дозвольте у політиці фаєрволу.

2) «Малі веб-запити працюють, копії файлів зависають»

Симптоми: Ping працює; RDP працює; SMB/великі HTTPS зависають; у захопленнях — повторні пересилки.
Корінь: MTU/PMTU чорна діра через накладні ESP + заблокований ICMP необхідний для фрагментації.
Виправлення: Встановіть TCP MSS clamp на тунельних інтерфейсах; зменшіть MTU; дозвольте необхідні типи ICMP в підкладці за потреби.

3) «Трафік працює кілька годин, потім рандомно помирає до рекієї/рестарту»

Симптоми: Періодичні відмови; у логах — DPD-помилки; часто за NAT.
Корінь: Таймаут мапінгу NAT для UDP 4500/500 або невідповідність життєвостей, що призводить до дивних рекієїв.
Виправлення: Увімкніть NAT-T keepalive; вирівняйте IKE/ESP lifetimes; налаштуйте DPD; переконайтесь, що upstream фаєрволи тримають UDP-мапінги достатньо довго.

4) «Увімкнули active/active, тепер деякі сесії ламаються»

Симптоми: Половина користувачів в порядку; інші бачать скидання; таблиці станів неконсистентні.
Корінь: Асиметрична маршрутизація через два тунелі без синхронізації стану, або ECMP без консистентності за потоком.
Виправлення: Використовуйте хешування за потоком із консистентним шляхом повернення, або active/passive для stateful сервісів; віддавайте перевагу BGP з правильними атрибутами і health checks.

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

Симптоми: До партнера доходить тільки один внутрішній префікс; розширення повільне і політичне.
Корінь: Партнер використовує суворі політико-базовані селектори, і процес змін болючий.
Виправлення: Домовтеся про маршрутний з VTI, якщо можливо; інакше використовуйте NAT (обережно), щоб змепити кілька внутрішніх префіксів в один дозволений селектор, і документуйте це як небезпечну практику.

6) «Після того як ми посилили NAT‑правила, VPN зламався»

Симптоми: IKE вгору, але трафік не йде; селектори виглядають коректно.
Корінь: Видалено виняток NAT; вихідна IP змінилася; політико-базований співпад не проходить або віддалений кінець відкидає несподівані внутрішні адреси.
Виправлення: Додайте явні правила обходу NAT для віддалених префіксів; перевірте захоплення пакетів, що внутрішні вихідні адреси відповідають очікуваним.

7) «VPN хмари‑в‑офіс флапає, on‑prem в‑on‑prem стабільний»

Симптоми: Періодичні рекієї/скидання BGP; підкладка виглядає нормально.
Корінь: Очікування таймерів хмарного шлюзу і таймаути простоїв; іноді агресивний DPD; іноді кілька шляхів з непослідовним NAT.
Виправлення: Підлаштуйте таймери під рекомендації хмари; увімкніть keepalive; уникайте подвійного NAT; перевірте стабільність UDP 4500; розгляньте подвійні тунелі з маршрутичною перевіркою.

8) «VPN повільний лише в години пік»

Симптоми: Скарги 9–11 ранку; CPU стрибає; дропи зростають; jitter для VoIP.
Корінь: Гейтвей обмежений CPU для крипто або обробки пакетів, або перевантаження підкладки без QoS.
Виправлення: Змініть розмір гейтвеїв, увімкніть апаратне прискорення, впровадьте QoS на підкладці і розгляньте розподіл трафіку між тунелями/регіонами.

Чеклісти / покроковий план

Покроково: проєктування нового офісного VPN (рекомендований шлях)

1. Виберіть маршрутний (VTI), якщо немає конкретної причини не робити так.
2. Визначте володіння префіксами: блочні підмережі на офіс, якщо можливо (спрощує маршрути та фільтри).
3. Вирішіть питання маршрутизації:
   • Малий обсяг: статичні маршрути підходять, але документуйте і тримайте симетрію.
   • Багато офісів або сильна хмарна інтеграція: запускайте BGP через тунель. Маршрутний робить це чистим.
4. Установіть MTU/MSS навмисно: не чекайте, поки SMB навчить вас про PMTU в продакшені.
5. Правила фаєрволу: найменший привілей, але не селекторний спагетті: дозволяйте потрібні порти між зонами, логуючи відмови на корисному рівні.
6. Моніторинг: перевіряйте стан IKE/IPsec, присутність маршрутів і реальну досяжність застосунків з кількох VLAN.
7. Дизайн відмовостійкості:
   • Віддавайте перевагу подвійним тунелям із маршрутичною перевіркою (BGP або відстежені статичні маршрути).
   • Робіть відмову явною: відкликайте маршрути, коли тунель нездоровий.
8. Управління змінами: визначте процес підключення нового VLAN: «додати префікс + анонсувати + політика». Зробіть це пунктом чекліста, а не героїчним вчинком.

Покроково: міграція з політико‑базованого на маршрутний без драм

1. Інвентаризація селекторів: перелічіть усі локальні/віддалені пари підмереж, що використовуються сьогодні.
2. Змоделюйте намір маршрутизації: які префікси дійсно мають бути доступні? Які — застарілі і мають померти?
3. Підніміть паралельний маршрутний тунель (інша IP пір або інший ID тунелю), зберігаючи старий.
4. Переміщайте по одному префіксу через маршрути: встановіть маршрут через VTI і видаліть селектор для цього префіксу зі старого тунелю лише після валідації.
5. Заздалегідь перевірте MTU/MSS; міграція часто виявляє старі гріхи PMTU.
6. Закріпіть фільтри маршрутів: не створюйте випадково any-to-any між офісами, бо «тепер маршрути є».
7. Переключіть моніторинг на новий тунель, а потім виведіть з експлуатації старі політики.

Операційний чекліст: що перевірити після будь‑якої зміни VPN

• IKE встановлено й стабільно (немає постійних рекієв або DPD‑помилок).
• Лічильники ESP зростають при генерації тестового трафіку.
• Маршрути встановлені для всіх потрібних префіксів (і тільки для них).
• Правила фаєрволу дозволяють потрібні порти; відмови логуються у корисному обсязі.
• PMTU тест пройшов на репрезентативних хостах; MSS clamp встановлено при необхідності.
• Хоча б один тест для критичного VLAN: користувачі, голос і «дивний» IoT.
• Тест відмовостійкості: відключіть лінк ISP або один тунель; підтвердіть відклик маршрутів і відновлення сесій згідно дизайну.
• Оновіть моніторинг/алерти: не залишайте «тунель вгору» як поверхневу метрику без перевірок трафіку.

FAQ

1) Чи маршрутний VPN безпечніший за політико-базований?

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

2) Чому політико-базовані VPN спричиняють «працює для деяких підмереж» відмови?

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

3) Чи можуть маршрутні VPN все ще використовувати селектори трафіку?

Так, багато реалізацій все ще узгоджують селектори, але в маршрутних дизайнах вони часто вузькі (host-to-host для VTI кінців) і
маршрути вирішують, які внутрішні префікси проходять тунелем. Операційна поведінка — ключова відмінність.

4) Чи потрібен мені BGP, щоб виправдати маршрутний підхід?

Ні. Статичні маршрути через VTI все ще простіші для розуміння, ніж матриця селекторів, особливо коли в офісах кілька VLAN.
BGP робить це просто масштабнішим і більш плавним при відмові.

5) Що робити з накладенням RFC1918 між офісами?

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

6) Яка модель краща для резервування через двох провайдерів?

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

7) Чому моніторинг «тунель вгору» не ловить реальні відмови?

Тому що здоров’я контрольної площини IKE/IPsec не гарантує коректність площини даних. Можуть бути SA вгору з неправильними маршрутами,
невідповідними селекторами, заблокованими портами, PMTU‑чорною дірою або відсутніми шляхами повернення. Моніторте і контрольну, і плоскость даних.

8) Чи означає маршрутний, що я випадково створив повносуміжний доступ між офісами?

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

9) Який найпоширеніший фактор, що вбиває пропускну здатність офісних VPN?

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

10) Якщо мій фаєрвол підтримує лише політико-базований режим, що робити?

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

Наступні кроки, які ви реально можете зробити

Якщо ви керуєте офісами і хочете менше сюрпризів з VPN, зробіть це:

1. Уніфікуйтеся на маршрутному VPN для офісних лінків, якщо на то немає обмежень з боку партнерського обладнання чи спадщини.
2. Зробіть маршрути явними: статичні маршрути для малих розгортань; BGP для багатьох сайтів або інтеграції з хмарою.
3. Пропрацюйте MTU/MSS з першого дня. Не чекайте, поки SMB зіпсує ваш день.
4. Моніторте площину даних: проби на рівні VLAN, а не тільки «IKE вгору».
5. Задокументуйте режими відмов, які ви реально бачите: невідповідності селекторів, винятки NAT, асиметрична маршрутизація, PMTU‑чорні діри.
6. Потренуйтеся на відмові — свідомо зламайте це в робочий віконечко. Дизайн, який ви не тестували, — це чутка.

Маршрутні VPN не зроблять вашу мережу ідеальною. Вони зроблять її діагностованою, масштабованою і менш залежною від племінних знань.
Для офісів це різниця між «безпечним WAN» і «повторною темою інцидентів».