WireGuard проти IPsec для офісів: що простіше в обслуговуванні та типові пастки

Приймайте рішення як оператор

І WireGuard, і IPsec можуть добре забезпечити з’єднання офіс-до-офісу. Різниця не в абстрактній “безпеці”.
Різниця в тому, скільки часу ви витратите на доведення того, що пакет коли-небудь існував, і як часто дрібна невідповідність перетворюється на чорну діру.

Моя упереджена, орієнтована на продакшн рекомендація

• За замовчуванням обирайте WireGuard для нових офісних site-to-site VPN, коли ви контролюєте обидва кінці (маршрутизатори на Linux, сучасні фаєрволи або пристрої, які чисто реалізують WireGuard).
  Він простіший для розуміння, легший для відлагодження і передбачуваний при змінах.
• Використовуйте IPsec/IKEv2, коли треба взаємодіяти з наявним корпоративним обладнанням, вимогами відповідності або там, де “IPsec — єдине, що постачальник підтримує без перекладання вини”.
  Також: якщо вам потрібно зрелізоване hub-and-spoke у великому масштабі з існуючими інструментами IPsec в команді, не воюйте з організацією.
• Не обирайте на основі криптографічних модних слів. Обирайте на підставі спостережуваності, режимів відмов і того, хто буде на виклику о 03:00.

Що насправді означає “простіше в обслуговуванні”

Обслуговування — це не початкове налаштування. Це другий офіс, який ви додаєте, зміна провайдера, оновлення фаєрвола та “швидка” зміна підмережі, яка не була записана.
Це також оберт ключів, моніторинг і відновлення після часткової відмови (односторонній трафік — король “виглядає вгору, фактично вниз”).

WireGuard зазвичай перемагає в питаннях ясності конфігурації та відлагоджуваності.
IPsec виграє в інституційній сумісності та широті функцій — за рахунок більшої кількості рухомих частин і поверхонь невдач при погодженні параметрів.

Одна операційна істина: якщо ваш VPN вимагає наради, щоб змінити набір шифрів, у вас не VPN — у вас щотижний ритуал.

Цитата (переказ ідеї) від Werner Vogels: You build it, you run it — маючи на увазі, що вартість експлуатації є частиною дизайну, а не постскриптумом.

Цікаві факти та історичний контекст (те, що пояснює сучасний безлад)

1. IPsec почався в 1990‑х як частина початкової концепції IPv6, потім був притягнутий у реальність IPv4. Результат: десятиліття розширень, профілів і “інтерпретацій” від постачальників.
2. IKE (Internet Key Exchange) еволюціонував через біль ручних ключів. IKEv1 був гнучким, але складним; IKEv2 спростив протокол і покращив надійність при змінних IP.
3. NAT зламав чисту модель IPsec. ESP не любить NAT; NAT-T (UDP-инкапсуляція) стало скотчем, що зробив IPsec працездатним в сучасному Інтернеті.
4. WireGuard навмисно малий. Його кодова база відома своєю компактністю порівняно зі звичайними стеками IPsec. Маленький не означає автоматично ідеальний, але зменшує площу “невідомих невідомих”.
5. WireGuard використовує сучасні примітиви (handshake на базі Noise). Він зробив однозначні вибори, щоб уникнути розростання матриці узгоджень алгоритмів.
6. Включення WireGuard у mainline Linux змінило гру. Коли він опинився в ядрі Linux, продуктивність і пакування спростилися, і він перестав відчуватися як побічний проект.
7. IPsec часто здається “становим” для людей, бо таким є. Він підтримує Security Associations (SAs) з часом життя, перегенерацією ключів та потенційно кількома дочірніми SA.
8. WireGuard виглядає “безстанним”, поки ви не дізнаєтеся, що це не так. У нього є handshakes і поведінка роумінгу, але він уникає довгих послідовностей переговорів і більшості драм про невідповідність пропозицій.
9. Багато виробників фаєрволів трактують IPsec як первинну функцію продукту. Це має значення в офісах, бо контракти підтримки та операції через UI — реальні обмеження.

Реальність обслуговування: чого ваш майбутній я буде ненавидіти

WireGuard: менше ручок, менше шляхів помилитися

Конфіг WireGuard по суті: ключі, endpoint, allowed IPs та keepalive, якщо ви за NAT. І все.
Операційний трюк у тому, що AllowedIPs одночасно є маршрутизацією та контролем доступу. Це елегантно, поки хтось не подумав, що це лише маршрутизація і випадково не надав доступу на цілу RFC1918 діапазон.

Робота з обслуговування WireGuard зазвичай виглядає так:

• Ротація ключів без руйнування пірів.
• Утримання AllowedIPs чистими, неперекривними та задокументованими.
• Запобігання “працює з ноутбука Боба, але не з маршрутизатора офісу” через стандартизацію NAT і правил фаєрвола.
• Моніторинг handshakes і пропускної здатності, щоб виявити безшумну відмову на ранньому етапі.

IPsec: земля “має працювати” і “все ще узгоджується”

Обслуговування IPsec зазвичай домінують питання сумісності та поверхні переговорів:
IKE/ESP пропозиції, DH групи, часи життя, таймери перегенерації, ідентичності, PSK vs сертифікати, політика на основі політик vs тунелі на основі маршрутів, DPD/keepalive, NAT-T, фрагментація та специфічні значення за замовчуванням у постачальників.

Ви можете експлуатувати IPsec роками без проблем, але тільки якщо дисципліновано:
стандартизуйте профілі, документуйте точні ручки і контролюйте поведінку перегенерації ключів. Якщо ви “просто клікаєте, поки зелено”, потім за це заплатите.

Що фактично визначає операційну рутину (незалежно від протоколу)

• NAT і асиметрична маршрутизація: VPN звинувачують, а таблиця маршрутів винна.
• Проблеми MTU/PMTUD: маленькі ping-и працюють; великі пакети вмирають; служба підтримки губить тиждень.
• Очікування DNS: люди хочуть, щоб “офісний DNS” магічно працював через тунелі без планування split-horizon.
• Дріфт ідентичностей: IP або хостнейм піра змінюється; конфіг залишається старим.
• Життєвий цикл ключів: ніхто не планує його, і тоді це стає відмовою при спробі.

Жарт №1: VPN — як кавомашини в офісі: ніхто не знає, як вони працюють, але всі помічають, коли немає кави.

WireGuard в офісах: операційна поведінка та пастки

У чому WireGuard відмінний

• Проста маршрутизація site-to-site, коли в кожного офісу стабільні підмережі і ви хочете передбачуваного з’єднання.
• Роумінг і ненадійні лінки: якщо публічний IP кінцевої точки змінюється, WireGuard може швидко відновитися, поки пір досяжний і відбуваються handshakes.
• Низький наклад для відлагодження: команди “покажи стан” зазвичай прямі: останній handshake, лічильники трафіку, endpoint.
• Продуктивність на CPU: часто відмінна на сучасному обладнанні, з меншим накладом, ніж у багатьох реалізаціях IPsec.

Пастки, що спричиняють реальні відмови

Пастка: перекриття AllowedIPs та перехоплення маршрутів

В WireGuard AllowedIPs на приймаючому кінці вирішує, який трафік приймається від піра. На відправляючому — які адреси маршрутизуються в тунель.
Якщо вони перекриваються, можна створити маршрутний хаос: трафік зникає у неправильного піра, бо ядро обирає найконкретніший маршрут, або, гірше, ваше “тимчасове” 0.0.0.0/0 стає постійним.

Практичне правило: ставтеся до AllowedIPs як до правил фаєрвола плюс записів таблиці маршрутів. Переглядайте їх як політику безпеки, а не як “якісь IP, що потрібні”.

Пастка: NAT і таймаути без persistent keepalive

Багато офісних лінків знаходяться за NAT — маршрутизатори провайдера, LTE як резерв, “бізнес” шлюзи з загадковою прошивкою.
Якщо жодна зі сторін не надсилає трафік деякий час, стан видаляється, і наступний пакет не доходить. Це виглядає як переривчаста відмова — найгірший вид.
Для NATed пірів встановіть PersistentKeepalive (зазвичай 25 секунд) на сторонах за NAT.

Пастка: невідповідний MTU і TCP-чорні діри

WireGuard додає наклад. Якщо ви пропускаєте його через PPPoE, VLAN-теги або іншу інкапсуляцію, ефективний MTU може швидко зменшитись.
Симптом: SSH працює, дрібні HTTP запити працюють, але “CRM таймаутить” або передачі файлів зависають.
Зазвичай виправлення — зменшити MTU інтерфейсу WireGuard і/або затиснути MSS на фаєрволі.

Пастка: забуваючи, що це не фаєрвол

WireGuard охоче пересилає пакети. Він не проєктує вашу сегментацію.
Вам все ще потрібні правила nftables/iptables, і ви маєте думати про боковий рух між офісними мережами.
Багато команд помилково вважають, що “VPN — це межа”. Ні. Це кабель.

Пастка: керування ключами в таблиці

Ключі WireGuard статичні. Це нормально, але їх треба тримати як облікові дані: власність, ротація та відкликання.
Класичний режим відмови: “хто має приватний ключ старого маршрутизатора філії?” і відповідь — “колишній MSP”.
Зберігайте ключі в системі секретів, а не в чиємусь домашньому каталозі.

IPsec/IKEv2 в офісах: операційна поведінка та пастки

У чому IPsec відмінний

• Сумісність між постачальниками: кожен фаєрвол говорить якоюсь своєю діалектикою, і багато хто має зрілі UI-процеси для цього.
• Інтеграція сертифікатів і PKI: масштабоване управління ідентичностями при правильному впровадженні.
• Маршрутні тунелі з VTI (на здатних платформах): ближче до “звичної маршрутизації”, яку розуміють оператори.
• Відповідність політикам: деякі організації мають політику, що явно називає IPsec.

Пастки, що спричиняють реальні відмови

Пастка: невідповідність пропозицій і “чорна діра переговорів”

Узгодження IPsec залежить від згоди щодо параметрів: шифрування, цілісності, PRF, DH груп, часів життя тощо.
Одна невідповідність може спричинити, що тунель тріпає, ніколи не піднімається або піднімається, але не пропускає трафік через невідповідність дочірніх SA.
Логи часто виглядають як ввічлива незгода. Бізнес-наслідок — не такий ввічливий.

Пастка: NAT-T і проблеми з UDP-фрагментацією

У NAT-середовищі IPsec часто працює через UDP/4500. На деяких шляхах великі UDP-пакети відкидаються.
Це може ламати перегенерацію ключів, руйнувати дані або створювати патерн “працює деякий час, потім вмирає”.
Вам доведеться налаштовувати MTU, включати підтримку фрагментації або затискати MSS. Ласкаво просимо до клубу.

Пастка: плутанина policy-based vs route-based

IPsec на основі політик (селектори локальних/віддалених підмереж) виглядає просто, поки не знадобляться перекриваючі підмережі, кілька мереж або динамічна маршрутизація.
Route-based (VTI) зазвичай більш придатний для офісів, бо поводиться як звичний інтерфейс і проблема маршрутизації.
Але не всі платформи реалізують його послідовно, і деякі UI ховають складність, поки вона не зламається.

Пастка: таймери перегенерації, які не відповідають реальності

Перегенерація ключів — нормальна річ. Штори перегенерацій — ні.
Якщо часи життя занадто короткі, або одна сторона перегенеровує агресивно, а інша не встигає, ви отримаєте періодичні втрати пакетів, що виглядають як “випадкова латентність провайдера”.
Моніторте частоту перегенерацій. Зробіть часи життя нудними.

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

Багато офісних розгортань IPsec прив’язують ідентичність до IP-адрес або припускають статичні публічні IP назавжди.
Потім провайдер змінює CPE, або філія переходить на LTE, і IKE-ідентичність більше не збігається.
Використовуйте стабільні ідентифікатори: FQDN-ідентичності та сертифікати, або принаймні документуйте залежність і плануйте зміни.

Жарт №2: IPsec багато в чому нагадує підхід до назв у офісах, розроблений комітетом — технічно всебічно, емоційно виснажливо.

Швидкий посібник діагностики (знайдіть вузьке місце перед тим, як “щось змінювати”)

Коли тунель “впав”, зазвичай це одна з чотирьох речей: доступність підлягаючого шляху, переговори/handshake, маршрутизація або MTU/становість.
Трюк — перевіряти в правильному порядку, щоб не витратити годину на доведення неправильного шару.

Перше: чи досяжний підлягаючий шар?

• Підтвердіть досяжність публічної IP/порту (UDP 51820 для WireGuard, UDP 500/4500 для IPsec).
• Перевірте, чи не змінилися правила NAT або фаєрволу.
• Підтвердіть, що обидві сторони погоджуються щодо адреси піра (або налаштовані для динамічних endpoint-ів відповідно).

Друге: чи вдається контрольна площина?

• WireGuard: перевірте час останнього handshake, endpoint і лічильники переданих байтів.
• IPsec: перевірте встановлення IKE SA, установку child SA і частоту перегенерацій.

Третє: чи правильно маршрутизований дата-план?

• Перевірте маршрути на обох сторонах (і чи збігається зворотний шлях).
• Шукайте перекриваючі підмережі та неправильні “AllowedIPs” або селектори трафіку.
• Підтвердіть, що пересилання і політики фаєрволу дозволяють трафік.

Четверте: чи не вбиває вас MTU/фрагментація безшумно?

• Тестуйте “do not fragment” ping-ами з наростаючими розмірами.
• Затискайте MSS для TCP, якщо бачите зависання.
• Слідкуйте за збоями перегенерації, корельованими з великими пакетами.

П’яте: чи це проблема ресурсів?

• Перегрівання CPU при криптоопераціях.
• Втрата пакетів у чергах на WAN-інтерфейсі.
• Нерівномірність IRQ на дешевих маршрутизаторах з маркетинговим “апаратним прискоренням VPN”.

Практичні завдання з командами (і що робити з виводом)

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

1) WireGuard: перевірте стан піра і час останнього handshake

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

peer: 7bq1oYVxRjv0y9u8mS5o2k1m8K9p0t7x6w5v4u3y2x1=
  endpoint: 203.0.113.44:53122
  allowed ips: 10.20.0.0/16
  latest handshake: 1 minute, 12 seconds ago
  transfer: 1.21 GiB received, 980.33 MiB sent
  persistent keepalive: 25 seconds

Значення: “Latest handshake” недавній; endpoint відомий; лічильники рухаються.
Рішення: Якщо трафік досі не проходить — перестаньте звинувачувати тунель і перевірте маршрути/фаєрвол/MTU всередині. Якщо handshake “ніколи” або кілька годин — фокусуйтеся на досяжності підлягаючого шару або ключах.

2) WireGuard: перевірте маршрути ядра, створені AllowedIPs

cr0x@server:~$ ip route show table main | grep wg0
10.20.0.0/16 dev wg0 scope link

Значення: Система маршрутизує 10.20.0.0/16 у wg0.
Рішення: Якщо ви очікували лише 10.20.30.0/24, а бачите /16 — ви знайшли, чому трафік зникає в тунелі. Виправте AllowedIPs і політику маршрутів.

3) WireGuard: перевірте MTU інтерфейсу і відрегулюйте за потреби

cr0x@server:~$ ip link show dev wg0
7: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Значення: MTU 1420 — типовий для WireGuard над Ethernet. Через PPPoE або додаткову інкапсуляцію це може бути ще завелике.
Рішення: Якщо бачите TCP-чорну діру, знижуйте MTU (наприклад, до 1380) і/або затискайте MSS на краю.

4) Тест Path MTU з DF ping (знайдіть чорні діри)

cr0x@server:~$ ping -M do -s 1372 -c 3 10.20.30.10
PING 10.20.30.10 (10.20.30.10) 1372(1400) bytes of data.
1372 bytes from 10.20.30.10: icmp_seq=1 ttl=63 time=18.7 ms
1372 bytes from 10.20.30.10: icmp_seq=2 ttl=63 time=18.5 ms
1372 bytes from 10.20.30.10: icmp_seq=3 ttl=63 time=18.6 ms

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

Значення: Пейлоад 1372 з DF проходить, отже приблизно ~1400-байтові пакети проходять по цьому шляху.
Рішення: Якщо це повертає “Frag needed”, налаштуйте MTU/MSS. Якщо просто таймаут — підозрюйте фільтрацію ICMP або реальну чорну діру — затисніть MSS і зменшіть MTU проактивно.

5) WireGuard: підтвердіть, що процес слухає очікуваний порт

cr0x@server:~$ sudo ss -lunp | grep 51820
UNCONN 0      0          0.0.0.0:51820      0.0.0.0:*    users:(("wg-quick",pid=1324,fd=6))

Значення: UDP/51820 відкрито локально.
Рішення: Якщо не слухає — сервіс не стартував або прив’язався неправильно. Виправте systemd/wg-quick, а потім перевірте фаєрвол/NAT.

6) WireGuard: захопіть спроби handshake (доведіть існування пакетів)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 51820 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:10:01.123456 IP 198.51.100.22.51820 > 203.0.113.44.53122: UDP, length 148
12:10:01.223901 IP 203.0.113.44.53122 > 198.51.100.22.51820: UDP, length 92

Значення: Двосторонній UDP рух; підлягаючий шар і фаєрвол, ймовірно, в порядку.
Рішення: Якщо бачите лише вихідні і немає відповіді — це фаєрвол/NAT/ISP. Якщо бачите двосторонні, але немає handshake в wg show — підозрюйте невідповідність ключів або неправильну конфігурацію піра.

7) IPsec (strongSwan): показати стан IKE і child SA

cr0x@server:~$ sudo swanctl --list-sas
vpn-office: #12, ESTABLISHED, IKEv2, 3c2f2e8d1d0a9c1f_i* 9a8b7c6d5e4f3210_r
  local  'office-a' @ 198.51.100.10[4500]
  remote 'office-b' @ 203.0.113.44[4500]
  AES_GCM_16-256/PRF_HMAC_SHA2_256/ECP_256
  established 42 minutes ago, rekeying in 2 hours
  office-a-office-b: #14, INSTALLED, TUNNEL, reqid 1
    local  10.10.0.0/16
    remote 10.20.0.0/16
    AES_GCM_16-256, 51023 bytes_i, 48890 bytes_o, rekeying in 46 minutes

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

8) IPsec: перевірте логи charon на помилки переговорів

cr0x@server:~$ sudo journalctl -u strongswan --since "10 min ago" | tail -n 12
Dec 28 12:02:11 gw-a charon-systemd[998]: 14[IKE] received NO_PROPOSAL_CHOSEN notify error
Dec 28 12:02:11 gw-a charon-systemd[998]: 14[IKE] failed to establish CHILD_SA, keeping IKE_SA
Dec 28 12:02:11 gw-a charon-systemd[998]: 14[IKE] peer supports MOBIKE

Значення: Пір відхилив пропозицію для child SA (ESP трансформи, DH група тощо).
Рішення: Узгодьте набори шифрів/пропозицій по обох сторонах. Не “відкривайте все”. Стандартизуйтесь на відомому робочому профілі і застосуйте його скрізь.

9) IPsec: перевірте, що слухачі UDP 500/4500 присутні

cr0x@server:~$ sudo ss -lunp | egrep ':500|:4500'
UNCONN 0      0          0.0.0.0:500        0.0.0.0:*    users:(("charon",pid=998,fd=12))
UNCONN 0      0          0.0.0.0:4500       0.0.0.0:*    users:(("charon",pid=998,fd=13))

Значення: Демон слухає потрібні порти IKE/NAT-T.
Рішення: Якщо відсутні — сервіс впав або прив’язався неправильно. Виправте це спочатку; не чіпайте ще пропозиції.

10) IPsec: підтвердіть, що NAT-T застосовується (або ні)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 4500 -c 3
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:06:44.001122 IP 198.51.100.10.4500 > 203.0.113.44.4500: UDP, length 244
12:06:44.101455 IP 203.0.113.44.4500 > 198.51.100.10.4500: UDP, length 276

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

11) Маршрутна санітарність: підтвердіть зворотний шлях (асиметрія вбиває VPNи)

cr0x@server:~$ ip route get 10.20.30.10
10.20.30.10 dev wg0 src 10.10.0.1 uid 0
    cache

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

12) Санітарність фаєрволу: підтвердіть, що пересилання не відкидається без повідомлення

cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    iifname "wg0" oifname "lan0" accept
    iifname "lan0" oifname "wg0" accept
    ct state established,related accept
  }
}

Значення: Політика forward за замовчуванням drop; існують явні дозволи між wg0 і lan0.
Рішення: Якщо цих правил нема, тунель може бути піднятий, але трафік не проходитиме. Додайте мінімальні явні правила пересилання і логування відкидань під час rollout.

13) Подивіться живі відкидання і помилки на інтерфейсах (помітите затори/MTU)

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    9876543210  8123456      0    1203       0  12345
    TX:  bytes packets errors dropped carrier collsns
    8765432109  7345678      0     987       0       0

Значення: Відкидань не нуль. Це може бути тиск черги, поліси або проблема драйвера.
Рішення: Якщо відкидання під час використання VPN стрибають — досліджуйте WAN shaping/QoS, CPU і MTU. Не міняйте крипто випадково спочатку.

14) Підтвердіть, що IP forwarding увімкнено (класика “тунель up, трафік ні”)

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

Значення: Хост буде маршрутизувати пакети.
Рішення: Якщо це 0 на Linux‑маршрутизаторі — ви знайшли причину відмови. Увімкніть його постійно і підтвердіть правила forward фаєрволу.

15) Доведіть, що DNS — це проблема, а не тунель

cr0x@server:~$ dig +short app.internal.example @10.20.0.53
10.20.30.45

Значення: Резолюція імен працює через тунель до віддаленого DNS-сервера.
Рішення: Якщо IP резольвиться, але додаток все ще відмовляє — дивіться маршрути/ACL додатку. Якщо не резольвиться — ваш “VPN впав” насправді питання доступності DNS або split-horizon дизайну.

16) Прослідкуйте шлях до віддаленої підмережі (знайдіть шалений дефолтний маршрут)

cr0x@server:~$ traceroute -n 10.20.30.10
traceroute to 10.20.30.10 (10.20.30.10), 30 hops max, 60 byte packets
 1  10.10.0.1  0.334 ms  0.291 ms  0.271 ms
 2  10.20.30.10  18.821 ms  18.654 ms  18.590 ms

Значення: Трафік доходить до віддаленого хоста за дві стрибки — ймовірно правильна маршрутизація через шлюз тунелю.
Рішення: Якщо бачите хопи, що виходять в ISP, — ви протікаєте маршрути. Виправте маршрути і розгляньте policy-based routing або більш специфічні префікси.

17) Для IPsec перевірте xfrm state/policy (вид ядра Linux)

cr0x@server:~$ sudo ip xfrm state | sed -n '1,60p'
src 198.51.100.10 dst 203.0.113.44
  proto esp spi 0xc0ffee12 reqid 1 mode tunnel
  replay-window 32 flag af-unspec
  auth-trunc hmac(sha256) 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 128
  enc cbc(aes) 0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
  lifetime config: soft 0 hard 0
  lifetime current: soft 0 hard 0

Значення: Ядро має встановлений ESP SA. Якщо політик нема, трафік не співпаде і піде відкритим (або буде відкинутий фаєрволом).
Рішення: Якщо демон каже “up”, але xfrm порожній — контрольно-план не інсталював стан — перевірте привілеї, підтримку ядра або помилки демона.

18) Виміряйте пропускну здатність і втрати пакетів через тунель

cr0x@server:~$ iperf3 -c 10.20.30.10 -t 10
Connecting to host 10.20.30.10, port 5201
[  5] local 10.10.0.50 port 58312 connected to 10.20.30.10 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-10.00  sec   412 MBytes   346 Mbits/sec   92   1.12 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   0.00-10.00  sec   412 MBytes   346 Mbits/sec   92             sender
[  5]   0.00-10.00  sec   409 MBytes   343 Mbits/sec                  receiver

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

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

1) “Тунель піднятий, але нічого не говорить”

Симптоми: Handshake/SA встановлено, ping-и до endpoint працюють, але трафік між підмережами не проходить.

Корінь: Відсутнє IP forwarding, відсутні правила forward фаєрволу або немає маршруту до віддалених підмереж.

Виправлення: Увімкніть forwarding (sysctl net.ipv4.ip_forward=1), додайте явні правила forward, перевірте маршрути з ip route get на обох сторонах.

2) “Працює декілька хвилин, потім вмирає поки ми не ‘перезапустимо VPN'”

Симптоми: Переривчасте підключення, часто після періоду бездіяльності.

Корінь: NAT idle timeout. WireGuard без keepalive або стан NAT-T IPsec закінчився.

Виправлення: WireGuard: встановіть PersistentKeepalive = 25 на NATed пір. IPsec: забезпечте налаштування DPD/keepalive; перевірте стабільність UDP/4500.

3) “Малі ping-и працюють, додатки зависають, передачі файлів підвішуються”

Симптоми: SSH ок, веб-інтерфейс частково, SMB/HTTPS зависає, великі завантаження таймаутяться.

Корінь: MTU/PMTUD збій або втрата UDP-фрагментів.

Виправлення: Зменшіть MTU тунелю, затисніть TCP MSS і проведіть DF ping тести, щоб знайти безпечні розміри пакетів.

4) “Після додавання нового офісу інший офіс зламався”

Симптоми: Додавши пір C, пир B став недосяжний; маршрути змінюються місцями.

Корінь: Перекриття AllowedIPs (WireGuard) або перекриття селекторів трафіку (policy-based IPsec). Зміна пріоритету маршрутів.

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

5) “IPsec не піднімається, але обидві сторони клянуться, що налаштовано правильно”

Симптоми: Повторні спроби переговорів, NO_PROPOSAL_CHOSEN, AUTH failed або немає matching CHILD_SA.

Корінь: Невідповідність пропозицій, невідповідність ідентичностей (ID/сертифікати), PSK mismatch або зсув часу, що впливає на валідацію сертифікатів.

Виправлення: Стандартизуйте пропозиції; перевірте ідентичності; підтвердіть синхронізацію часу; інспектуйте логи на обох кінцях і вирівняйте точні трансформи та селектори.

6) “WireGuard handshakes є, але лічильники трафіку не рухаються”

Симптоми: wg show показує свіжий handshake, але transfer залишається 0; або збільшується лише в одному напрямку.

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

Виправлення: Перевірте AllowedIPs на обох пірях; перевірте таблиці маршрутів; підтвердіть правила forward; запустіть tcpdump на wg0 і LAN-інтерфейсі.

7) “Все зламалося після того, як провайдер змінив публічний IP філії”

Симптоми: Тунель ніколи не повертається; логи показують невідповідність ідентичності або пір недосяжний.

Корінь: Жорстко заданий endpoint/ідентичність прив’язана до старого IP; upstream NAT змінився; відсутні фаєрвол‑пінхоли.

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

8) “Продуктивність VPN жахлива в робочі години”

Симптоми: Висока латентність, низька пропускна здатність, піки втрат пакетів, проблеми з голосом.

Корінь: Перевантаження CPU через крипто, завантаження WAN, bufferbloat або неправильно налаштований QoS.

Виправлення: Заміряйте iperf3, перевірте відкидання на інтерфейсах і CPU; застосуйте правильне формування/QoS; апгрейдьте обладнання за потреби.

Три корпоративні історії (анонімізовані, правдоподібні та болісно знайомі)

Інцидент через хибне припущення: “VPN — це мережа”

Середня компанія відкрила новий офіс. Вони вже використовували WireGuard для віддалених користувачів, тож повторили ту саму практику для site-to-site.
Розгортання пройшло швидко: тунель піднято, маршрути додано, базові ping-и в порядку. Усі потисли руки і повернулися до роботи.

Через два тижні хтось помітив, що новий офіс може дістатися до застарілої підмережі, яка мала бути ізольована. Не “ой, один сервер”. Уся підмережа.
Припущення було таке: “якщо це в тунелі, воно довірене як внутрішня LAN”. Це припущення ніколи не було правдою — але тепер воно було закодоване в AllowedIPs і дозволах пересилання.

Корінь проблеми був тонким: AllowedIPs включав широкий 10.0.0.0/8, бо “можливо додамо ще підмережі пізніше”.
На фаєрволі пересилання між wg0 і lan0 було дозволено без обмежень.
Ніхто не записав вимоги сегментації, бо “це просто офісний тунель”.

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

Урок: найшвидший спосіб створити несподівану досяжність — “планувати зростання”, маршрутизуючи всю всесвітність з першого дня.

Оптимізація, що відкотилася: крипто‑тонінг замість планування ємності

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

Вони змінили пропозиції IPsec на “легші” налаштування і скоротили часи життя, сподіваючись поліпшити продуктивність і стабільність.
Це трохи зменшило навантаження на CPU — але також збільшило частоту перегенерацій ключів і спричинило піки втрат пакетів щоразу, коли тунелі міняли ключі.
Досвід користувачів погіршився, і тепер він був періодичним і важкодосяжним для пояснення.

Налагодження зайняло час, бо кожна філія поводилася по‑різному. Хтось був за агресивним NAT; хтось мав PPPoE; хтось мав провайдерське обладнання, яке ненавиділо фрагментований UDP.
Коротші часи життя означали частіші великі обміни контрольної площини. Це були саме ті пакети, яких шлях ненавидів.

Остаточне вирішення було нудним: повернулися до розумних часів життя, затиснули MSS і правильно налаштували shaping на WAN.
Потім оновили два перевантажені пристрої, які просто не мали CPU‑запасу для пікових навантажень.
“Оптимізація” в теорії була не неправильна; вона була неправильною у контексті.

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

Скучно, але правильно, що врятувало день: стандартні профілі + перевірка перед змінами

Компанія з 15 офісами мала мікс WireGuard і IPsec через злиття компаній. Їхня SRE-команда більше ненавиділа відмови, ніж паперову роботу, тому вони ввели звичку:
кожна зміна мала pre-flight чекліст, а кожен тунель — стандартний “відомо‑робочий” профіль.

Одного п’ятничного пополудня (всім завжди в п’ятницю) у філії провайдер провів технічні роботи і несповіщено замінив публічний IP.
Тунель упав. Але замість гадання, відповідальний запустив ті самі три команди, які вони завжди запускали: перевірити досяжність підлягаючого шару, перевірити стан контрольної площини, перевірити маршрути.
Моніторинг уже мав алерти на “handshake старший за N хвилин” і “SA flapping”.

У них вже була модель хабу, де філії ініціювали з’єднання назовні, плюс задокументована процедура оновлення endpoint-ів філії.
Вони оновили endpoint, спостерігали відновлення handshake і перевірили ключові додатки невеликою батареєю ping-ів і TCP‑перевірок.
Загальний вплив: помітний, але локалізований.

Те, що їх врятувало, не був модний протокол. Це була послідовність:
стандартні конфіги, хороша спостережуваність і культура “перевіряти до і після”.

Чеклісти / покроковий план (впровадьте без ненависті до себе)

Спочатку оберіть модель: mesh vs hub-and-spoke

• Mesh (кожен офіс з кожним офісом): проста концепція, операційно складна при зростанні. Ключі/профілі множаться; налагодження стає комбінаторним.
• Hub-and-spoke (офіси до HQ/хаба в хмарі): зазвичай найкраще для офісів. Централізований моніторинг, менше тунелів, легший контроль політик.

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

План впровадження WireGuard (офіс‑до‑офісу)

1. Визначте адресацію: виділіть неперекривні префікси для кожного сайту; задокументуйте їх.
2. Виберіть порт прослуховування і стандартизуйте його (не “творіть” для кожного сайту).
3. Згенеруйте ключі для кожного маршрутизатора сайту; зберігайте приватні ключі в системі секретів.
4. Пишіть AllowedIPs вузько: лише префікси віддаленого сайту; уникайте catch-all діапазонів.
5. Встановіть PersistentKeepalive для сайтів за NAT.
6. Реалізуйте політику фаєрволу: явні allowlist-и між підмережами; default deny для бокового руху між сайтами.
7. Налаштуйте MTU і/або затиск MSS на основі вашого WAN (PPPoE/LTE майже завжди потребують уваги).
8. Моніторинг: алерти на вік handshake, застій лічильників трафіку і втрати/латентність до ключових сервісів.
9. Запустіть пост‑зміну тест: ping, TCP connect до ключових портів, DNS-запит і невеликий тест пропускної здатності.

План впровадження IPsec (IKEv2, офіс‑до‑офісу)

1. За можливості оберіть route-based (VTI). Якщо застрягли на policy-based — тримайте селектори простими й явними.
2. Стандартизуйте один набір пропозицій по всій організації. Один. Не п’ять. Уникайте vendor “auto” режимів, якщо вам не подобається археологія.
3. Визначте PSK vs сертифікати: PSK швидкий, але погано масштабується; сертифікати вимагають гігієни PKI, але окуповуються з часом.
4. Встановіть часи життя на розумні значення і тримайте їх узгодженими, щоб уникнути хаосу.
5. Увімкніть NAT‑T (за потреби) і перевірте досяжність UDP/4500.
6. Плануйте MTU: ранній clamp MSS; підтвердіть, чи працює PMTUD, або припустіть, що ні.
7. Логування і моніторинг: відстежуйте події up/down SA, частоту перегенерацій і нотифіки помилок типу NO_PROPOSAL_CHOSEN.
8. Документуйте ідентичності: який ID використовує кожна сторона; що змінюється при зміні IP провайдера; де зберігаються сертифікати.
9. Після зміни перевірка: те саме, що для WireGuard, плюс перевірка, що селектори child SA відповідають задумуваним мережам.

Чистота операцій (застосовується до обох)

• Кожен сайт має: власника, призначення, підмережі, endpoints пірів і план відкату.
• Моніторинг наявний для: стану контрольної площини тунелю та доступності додатків.
• Стратегія MTU записана (включаючи виключення для PPPoE/LTE).
• Вікна змін включають пре/пост перевірки з збереженим виводом.
• Ключі/PSK/сертифікати мають процедури ротації і відкликання.
• Правила фаєрволу переглядаються як код, а не редагуються “той, хто мав доступ”.

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

1) Чи WireGuard “безпечніший” за IPsec?

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

2) Що легше відлагоджувати при виклику на місце?

Зазвичай WireGuard. wg show вказує вік handshake, endpoint і лічильники байтів одним поглядом.
Відлагодження IPsec часто вимагає читання логів переговорів і розуміння, яка SA випала і чому.

3) Яка найпоширеніша помилка WireGuard в офісі?

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

4) Яка найпоширеніша помилка IPsec в офісі?

“Auto” налаштування пропозицій і невідповідні профілі між постачальниками. Працює, поки не перестане працювати, і тоді ніхто не може пояснити чому.
Стандартизуйте один IKEv2/ESP профіль і застосуйте його всюди.

5) Чи потрібна динамічна маршрутизація (OSPF/BGP) поверх VPN?

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

6) Як уникнути проблем MTU без того, щоб стати митцем пакетів?

Будьте консервативні: знижуйте MTU тунелю і затискайте MSS на краю.
Перевіряйте DF ping-ами і реальним TCP‑переносом. Припускайте, що PMTUD на щонайменше одному шляху провайдера не працюватиме.

7) Чи філії мають ініціювати тунель, чи HQ має ініціювати?

Краще, щоб філії ініціювали з’єднання назовні до стабільного хаба. Це уникає вхідних пінхолів у філіях і краще витримує зміну IP філії.
Це також спрощує інцидент‑реакцію: один хаб для моніторингу.

8) Чи можна змішувати WireGuard і IPsec в одній організації?

Так, багато хто так робить через злиття або обмеження постачальників. Ризик — операційна неконсистентність.
Зменшіть ризики стандартними рукописами, моніторингом, який говорить про результати (латентність, досяжність), і планом поступової конвергенції.

9) Чи потрібні сертифікати для IPsec, чи PSK достатньо?

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

10) Що “тунель піднятий, але односторонній трафік” зазвичай означає?

Асиметрична маршрутизація, дивна поведінка NAT або правила фаєрволу, які дозволяють лише один напрямок.
Доведіть це лічильниками (wg show або байти SA) і захопленнями на обох кінцях; потім виправляйте симетрію маршрутів і політику пересилання.

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

Якщо ви починаєте з нуля і контролюєте обидва кінці, розгорніть WireGuard у схемі hub-and-spoke.
Тримайте AllowedIPs вузькими, встановлюйте keepalive для NATed сайтів і затискайте MSS рано. Додайте моніторинг віку handshake і перевірки додатків, а не лише “тунель up”.

Якщо ви вже в IPsec‑ландії, не викорчовуйте все лише тому, що це дратує. Зробіть його нудним:
стандартизуйте один IKEv2 профіль, перейдіть на route-based тунелі де можна, вирівняйте часи життя і інструментуйте перегенерації та помилки.
Більшість “таємниць” IPsec зникають, коли ви перестаєте дозволяти кожному винаходити свій набір пропозицій.

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