VPN між офісами: з’єднати два офіси в одну мережу (простий план, що працює)

Що вам насправді потрібно (і що, ймовірно, ні)

Коли кажуть «з’єднати два офіси в одну мережу», зазвичай мають на увазі одне або більше з наступного:

• Користувачі в Офісі B можуть дістатися внутрішніх додатків, розміщених в Офісі A (і навпаки).
• Обидві локації мають доступ до спільної інфраструктури: AD/LDAP, файлові шаринги, Git, моніторинг, VoIP, принтери (так, ще).
• Послідовні політики доступу: «HR може дістатися HR-систем» — незалежно від того, у якій будівлі краща кава.
• Стабільна продуктивність і прогнозовані режими відмов.

Те, що вони думають, що потрібно — «зробіть як ніби ми протягнули комутатор між будівлями». Не робіть так. L2-розширення через інтернет — це шлях до дебагу широкомовних штормів із CFO у кімнаті.

Ваша мета проста: маршрутизувати трафік між двома (або більше) чітко визначеними IP-мережами через зашифрований тунель, з чіткими межами, зрозумілим DNS та достатньою спостережливістю, щоб відповісти «що зламалося?» менше ніж за п’ять хвилин.

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

Короткий жарт №1: VPN не «робить мережі швидшими», але допомагає провині долатися зі швидкістю дроту.

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

Трохи контексту не завадить, бо половина проблем походить від застарілих ідей, які пережили свій час.

1. IPsec з’явився до сучасного «хмарного мислення». Основні стандарти з’явилися в середині — кінці 1990-х; багато вендорів досі постачають припущення з тієї епохи.
2. IKEv1 проти IKEv2 має значення. IKEv2 (середина 2000-х) вирішив реальні проблеми: складність переговорів, мобільність та стабільність. Якщо є вибір — обирайте IKEv2.
3. NAT traversal (NAT-T) існує, бо інтернет став NAT-ований. IPsec ESP не дружить із NAT; UDP-инкапсуляція (зазвичай порт 4500) була практичним рішенням.
4. «VPN поверх UDP» — це не новинка. L2TP/IPsec і пізніше WireGuard звернулися до UDP, бо він краще поводиться через middlebox’и, ніж сирий ESP у багатьох середовищах.
5. WireGuard навмисно компактний. Його спроектували як аудитований і мінімалістичний у порівнянні з традиційними стек-реалізаціями IPsec. Це реальна операційна перевага.
6. BGP поверх тунелів старший за ваш сучасний фаєрвол. Перевізники десятиліттями запускали динамічну маршрутизацію через інкапсульовані лінки; це не надмірно, коли потрібно чисте перемикання.
7. Біль із MTU історичний, а не персональний провал. Інкапсуляція додає накладні байти; Path MTU Discovery часто блокується або псується; «пінгується на моєму» брехав завжди.
8. Корпоративні мережі колись були довіреними за замовчуванням. Епоха «плоскої LAN» залишила багато організацій із широким внутрішнім доступом. Site-to-site VPN може ненавмисно відтворити це в інтернет-мащтабі.

Виберіть топологію, яка добре відмовляє

The default: routed site-to-site (hub-and-spoke or point-to-point)

Для двох офісів простий маршрутизований тунель зазвичай достатній: Офіс A має шлюз, Офіс B має шлюз, і ви маршрутизуєте підмережі A → підмережі B через тунель.

Якщо ви плануєте додавати більше сайтів пізніше, оберіть hub-and-spoke з раннього етапу: один або два хаби (датасентр або хмара), спіки в офісах. Це спрощує політики та моніторинг і уникає «мережі повної сітки суму» де кожен офіс повинен окремо з’єднуватися з кожним.

IPsec vs WireGuard (думка)

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

Якщо хочете простоти й контролюєте обидва кінці: WireGuard практично неперевершений. Менше переговорів. Менше рухомих частин. Дебаг більше «пакети входять/виходять», менше «Фаза 1 піднята, а Фаза 2 проклята».

У будь-якому випадку не обирайте за єдиним бенчмарком. Обирайте те, що ви зможете експлуатувати о 3-й ранку і що можна чисто замінити.

Layer 2 bridging: the trap

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

Чеклісти / покроковий план (простий план, що працює)

Фаза 0: передумови, які потрібно зробити до налаштування тунелю

• Оберіть неперекриваються підмережі. Якщо Офіс A використовує 192.168.1.0/24, Офіс B не може. Це не обговорюється.
• Визначте, які підмережі мають спілкуватися. «Усе з усім» — лінь і небезпечно.
• Оберіть модель маршрутизації. Статичні маршрути для невеликих, стабільних мереж. BGP — якщо потрібен фейловер або плануєте зростання.
• Оберіть метод автентифікації. Pre-shared key (PSK) підходить для малих установок; сертифікати краще масштабуються і чистіше ротають.
• Інвентар NAT і фаєрволів. Знайте, хто володіє публічними IP, які порти дозволені, і чи хтось стоїть за carrier-grade NAT.

Фаза 1: IP-план і політика трафіку

Спочатку на папері:

• LAN Офіс A: наприклад, 10.10.0.0/16
• LAN Офіс B: наприклад, 10.20.0.0/16
• Зарезервовані діапазони інфраструктури (сервери, VoIP, принтери) з меншими підмережами для порядку
• Виріште, чи клієнти мають виходити в інтернет локально (split tunnel) або через центральний егрегес (full tunnel)

Думка: Для двох офісів за замовчуванням вибирайте split tunnel, якщо немає вимог комплаєнсу для централізації егрегесу. Full tunnel через site-to-site — чудовий спосіб перетворити проблему одного ISP в інцидент для всієї компанії.

Фаза 2: конфігурація тунелю (мінімально життєздатна, дружня до продакшену)

• Шифрування: використовуйте сучасні набори. Уникайте застарілих алгоритмів і «бо сумісно». Якщо застрягли через сумісність — ізолюйте й плануйте апгрейд.
• Perfect Forward Secrecy: увімкніть.
• Інтервали переключення ключів: дотримуйтесь значень за замовчуванням, якщо немає причини; надто агресивні переключення можуть створювати періодичні перебої.
• DPD/keepalives: увімкніть детекцію «мертвого пірінга», щоб швидко фіксувати відмови.
• Фаєрвол-правила: дозволяйте лише необхідний трафік через тунель (за підмережею і портом), потім розширюйте свідомо.

Фаза 3: маршрутизація і DNS

• Маршрутизація: встановіть маршрути на шлюзах (або через BGP). Підтвердіть за допомогою traceroute, що шлях іде через тунель.
• DNS: забезпечте роботу резолюції імен між сайтами. Тут народжуються ситуації «тунель піднятий, але додаток упав».
• Синхронізація часу: переконайтеся, що обидва сайти мають надійні NTP. Перевірка сертифікатів і Kerberos не люблять «машин часу».

Фаза 4: загартування і спостережливість

• Логуйте зміни стану тунелю і події переключення ключів.
• Моніторьте втрати пакетів і затримки між репрезентативними хостами, а не тільки «тунель піднятий».
• Запишіть налаштування MTU/MSS і перевіряйте реальними передаваннями.
• Документуйте: підмережі, маршрути, дозволені порти, власність і план відкату.

Фаза 5: тестуйте як песиміст

• Симулюйте відмову ISP на одному сайті (відключіть WAN, перевірте резервну лінію, якщо є).
• Перевірте DNS-резолюцію з обох сайтів для спільних сервісів.
• Перевірте великі файлові передачі та довгоживучі з’єднання (VoIP, RDP/SSH, бази даних).
• Перевірте після переключення ключів (почекайте хоча б один інтервал переключення).

Маршрутизація: статична проти динамічної і одне правило, якого не можна порушувати

Одне правило: ніякого перекриття IP-просторів

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

Перенумерація болюча. Але все одно легша за постійні NAT-пяточки.

Статична маршрутизація: підходить для малих, стабільних мереж

Якщо кожен офіс має один WAN-лінк і ваші підмережі рідко змінюються — статичні маршрути нормальні. Вони прості, відлагоджувані і не потребують демонів маршрутизації.

Статична маршрутизація провалюється, коли:

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

BGP: не обов’язково, але часто найчистіший інструмент для фейловера

Якщо у вас два тунелі (або два ISP) і ви хочете, щоб трафік швидко зміщувався — BGP того варта. Ви можете запускати BGP поверх IPsec або WireGuard, обмінюватися лише префіксами, які потрібні, і дозволити протоколу керувати фейловером.

Тримайте налаштування поміркованими:

• Використовуйте prefix-list’и.
• Використовуйте ліміти max-prefix.
• Використовуйте route-map для запобігання «ой, я оголосив 0.0.0.0/0».

Короткий жарт №2: BGP — як офісні плітки: потужний, швидкий, і обов’язково розповсюджує не те, якщо не виставити межі.

DNS та ідентичність: тихий вбивця

Більшість «VPN-проблем» — фактично DNS-проблеми в маскараді VPN. Тунель піднятий. Маршрут існує. Але користувачі не можуть дістатися intranet, автентифікація падає або клієнт БД зависає.

Визначте модель іменування

• Одиний внутрішній домен (поширено в AD): обидва офіси резолвлять ті самі внутрішні зони.
• Split-horizon DNS: імена резолвляться по-різному залежно від джерела запиту.
• Явне іменування сервісів: додатки використовують FQDN, що вказують на site-local VIP або глобальні балансери; менше «офіс як концепт».

Зробіть DNS стійким через тунель

Як мінімум:

• Кожен офіс повинен мати локальні DNS-резолвери.
• Резолвери повинні переадресовувати або реплікати зони за потреби.
• Клієнти не повинні покладатися на «DNS іншого офісу» як на первинний. Так WAN-глюк перетворюється на шторм автентифікації.

Системи ідентичності ненавидять часткову доступність

Kerberos, LDAP і автентифікація на сертифікатах можуть падати так, що здається «випадковою повільністю». Якщо DNS перекидається між сайтом A і B, отримаємо інтермітентні таймаути автентифікації. Тримайте локальні служби ідентичності локально де можливо або проєктуйте явний фейловер з health-check’ами.

MTU, MSS і чому «пінгується» — не доказ

Інкапсуляція додає байти. IPsec додає оверхед (заголовки ESP, можлива UDP-инкапсуляція). WireGuard теж додає. Якщо ви це не врахували, з’являється особливий вид відмови: маленькі пакети працюють, великі — зависають. Користувачі повідомляють «деякі сайти завантажуються, файлові шари зависають, відеодзвінки заморожуються». Ви починаєте звинувачувати додатки. Це MTU.

Практичні поради

• Припускайте, що ефективний MTU через тунель менший за 1500.
• Clamp TCP MSS на краю тунелю, якщо можете (поширено на фаєрволах і маршрутизаторах). Це грубий, але ефективний інструмент, який запобігає проблемам фрагментації.
• Тестуйте за допомогою ping з опцією «do not fragment» і реалістичними розмірами корисного навантаження.

До чого прагнути

Вам потрібен шлях, де TCP може встановлювати сесії і передавати великі дані без «чорних дір». Якщо PMTUD блокується на шляху (поширено), MSS-clamping часто рятує від тижня марних зустрічей.

Позиція щодо безпеки: шифрування — це не контроль доступу

Site-to-site VPN шифрує трафік між шлюзами. Він не вирішує, хто має до чого доступ. Це ваша задача.

Не робіть «інший офіс» зоною довіри

Багато мереж трактують віддалену підмережу як ще один VLAN. Тоді скомпрометований ноутбук в Офісі B може сканувати сервери в Офісі A. Шифрування сумлінно захищає трафік нападника. Це не та перемога, яка вам потрібна.

Мінімальна сегментація

• Дозволяйте лише необхідні підмережні потоки (наприклад, клієнти → app-підмережі, app → DB-підмережі).
• За замовчуванням блокуйте east-west між клієнтськими VLAN.
• Логируйте відхилені потоки під час rollout, щоб коригувати без вгадувань.

Управління ключами та ротація

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

Перефразована ідея (Werner Vogels, операції/надійність): «Будуйте системи, припускаючи, що речі ламаються; стійкість приходить через проєктування під цю реальність.»

Висока доступність: що насправді означає «резервування»

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

Шаблони HA, що працюють

• Дуальний WAN на кожному сайті (бажано різні оператори, різні фізичні шляхи).
• Два VPN-шлюзи (active/standby або active/active) з синхронізацією стану, якщо підтримується.
• Два тунелі (по одному на кожен WAN) з маршрутизованим фейловером (краще BGP або трекінговані статичні маршрути).

Обережно з «HA, що ламається під час фейловеру»

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

Будьте чесні щодо обіцянок:

• «Переключення за 30 секунд, існуючі TCP-сесії можуть скинутися.» (чесно)
• «Без помітного впливу.» (рідко, дорого і вимагає більше, ніж VPN)

Моніторинг і SLO для тунелю (так, серйозно)

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

Що вимірювати

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

Встановіть очікування (легкий SLO)

Приклад: «Міжофісна коннективність: 99.9% щомісячної доступності; RTT p95 нижче 40 мс у робочий час; втрата пакетів нижче 0.5%». Підлаштуйте під реальність. Потім сповіщайте, коли порушення, а не коли хтось жаліється.

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

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

Завдання 1: Підтвердьте ваш локальний IP і маршрут до віддаленої підмережі

cr0x@server:~$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 10.10.12.34/24 brd 10.10.12.255 scope global eth0
       valid_lft forever preferred_lft forever

cr0x@server:~$ ip route get 10.20.8.50
10.20.8.50 via 10.10.12.1 dev eth0 src 10.10.12.34 uid 1000
    cache

Що це означає: Ваш хост думає, що трафік до 10.20.8.50 йде на локальний шлюз (10.10.12.1). Добре. Якщо він замість цього маршрутизується через інтерфейс або дефолтний маршрут, якого ви не чекали — ви дебагуєте не той пристрій.

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

Завдання 2: Перевірте, що віддалена підмережа дійсно маршрутується назад

cr0x@server:~$ traceroute -n 10.20.8.50
traceroute to 10.20.8.50 (10.20.8.50), 30 hops max, 60 byte packets
 1  10.10.12.1  0.407 ms  0.352 ms  0.331 ms
 2  172.16.100.1  10.982 ms  11.104 ms  11.015 ms
 3  10.20.8.50  12.201 ms  12.144 ms  12.087 ms

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

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

Завдання 3: Переконайтесь, що у вас немає перекриваючихся підмереж (на хості)

cr0x@server:~$ ip route | egrep '10\.10\.|10\.20\.|192\.168\.'
10.10.12.0/24 dev eth0 proto kernel scope link src 10.10.12.34
10.20.0.0/16 via 10.10.12.1 dev eth0

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

Рішення: Якщо ви бачите віддалений префікс як «підключений» локально — у вас є перекриття або зловісний DHCP. Зупиніться і виправте адресацію.

Завдання 4: Тест базової досяжності і відрізнити «немає маршруту» від «фільтрується»

cr0x@server:~$ ping -c 3 10.20.8.50
PING 10.20.8.50 (10.20.8.50) 56(84) bytes of data.
64 bytes from 10.20.8.50: icmp_seq=1 ttl=62 time=12.4 ms
64 bytes from 10.20.8.50: icmp_seq=2 ttl=62 time=12.2 ms
64 bytes from 10.20.8.50: icmp_seq=3 ttl=62 time=12.5 ms

--- 10.20.8.50 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 12.210/12.378/12.512/0.121 ms

Що це означає: ICMP працює і затримка розумна. Це не доводить, що TCP працює в масштабі, але це початок.

Рішення: Якщо ping не проходить, але traceroute доходить до хоста — ICMP може бути заблокований; тестуйте TCP наступним кроком замість того, щоб оголосити VPN мертвим.

Завдання 5: Перевірте досяжність TCP-порту (перевірка на рівні сервісу)

cr0x@server:~$ nc -vz -w 2 10.20.8.50 443
Connection to 10.20.8.50 443 port [tcp/https] succeeded!

Що це означає: Маршрут і політика фаєрволу дозволяють TCP/443. Це ближче до того, що відчувають користувачі, ніж ping.

Рішення: Якщо це не вдається, але ping працює — підозрюйте фаєрвол-правила, security groups або хостовий фаєрвол на сервері.

Завдання 6: Перевірте резолюцію DNS між сайтами

cr0x@server:~$ resolvectl status | sed -n '1,25p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.20.0.53

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

Що це означає: У вас є резолвери з обох сайтів, і ім’я резолвиться в очікувану віддалену IP.

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

Завдання 7: Виловіть проблеми MTU за допомогою ping з «do not fragment»

cr0x@server:~$ ping -M do -s 1472 -c 2 10.20.8.50
PING 10.20.8.50 (10.20.8.50) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1420

cr0x@server:~$ ping -M do -s 1392 -c 2 10.20.8.50
PING 10.20.8.50 (10.20.8.50) 1392(1420) bytes of data.
1400 bytes from 10.20.8.50: icmp_seq=1 ttl=62 time=13.1 ms
1400 bytes from 10.20.8.50: icmp_seq=2 ttl=62 time=13.0 ms

Що це означає: Path MTU близько 1420 байт. Якщо кінці намагаються надсилати 1500-байтові пакети без MSS-clamping або PMTUD — отримаєте зависання.

Рішення: Clamp MSS (наприклад, 1360–1380) або налаштуйте MTU інтерфейсу, щоб уникнути фрагментації/чорних дір.

Завдання 8: Перевірте поточний TCP MSS (spot clamping)

cr0x@server:~$ ss -ti dst 10.20.8.50:443 | sed -n '1,20p'
ESTAB  0  0  10.10.12.34:52514  10.20.8.50:443
	 cubic wscale:7,7 rto:204 rtt:13.1/1.2 mss:1360 pmtu:1420 rcvmss:1360 advmss:1360 cwnd:10 bytes_sent:2145 bytes_acked:2145 segs_out:17 segs_in:14 data_segs_out:10 data_segs_in:9

Що це означає: MSS 1360 і PMTU 1420; виглядає узгоджено з оверхедом тунелю.

Рішення: Якщо MSS показує 1460 при PMTU ~1420 — ви наражаєтеся на проблеми. Впровадьте MSS-clamping на шлюзі.

Завдання 9: Виміряйте затримку і втрати за допомогою mtr (не тільки ping)

cr0x@server:~$ mtr -n -r -c 50 10.20.8.50
Start: 2025-12-27T11:12:41+0000
HOST: server                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.10.12.1                0.0%    50   0.4   0.4   0.3   0.9   0.1
  2.|-- 172.16.100.1              0.0%    50  11.2  11.0  10.7  13.9   0.6
  3.|-- 10.20.8.50                1.0%    50  12.5  12.7  12.0  18.4   1.2

Що це означає: 1% втрат на дестінації достатньо, щоб певні додатки відчували «повільність», особливо чутливі.

Рішення: Якщо втрата з’являється на хопах 2 і 3 — підозрюйте WAN або транспорт тунелю. Якщо тільки на хопі 3 — підозрюйте хост або його локальну мережу.

Завдання 10: Перевірте стан IPsec SA на Linux-шлюзі (strongSwan)

cr0x@server:~$ sudo ipsec statusall | sed -n '1,40p'
Status of IKE charon daemon (strongSwan 5.9.8, Linux 6.8.0, x86_64):
  uptime: 2 hours, since Dec 27 09:11:02 2025
  worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
Connections:
 office-a-office-b:  10.0.0.1...203.0.113.20  IKEv2, dpddelay=30s
 office-a-office-b:   local:  [gw-a] uses pre-shared key authentication
 office-a-office-b:   remote: [gw-b] uses pre-shared key authentication
Security Associations (1 up, 0 connecting):
 office-a-office-b[12]: ESTABLISHED 15 minutes ago, 10.0.0.1[gw-a]...203.0.113.20[gw-b]
 office-a-office-b{8}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c9f2a1d1_i c6f8b02f_o
 office-a-office-b{8}:   10.10.0.0/16 === 10.20.0.0/16

Що це означає: IKEv2 встановлено, і child SA (ESP) інстальовано для очікуваних підмереж.

Рішення: Якщо IKE піднятий, але child SA відсутній — ймовірно, несумісні traffic selectors/підмережі або політика.

Завдання 11: Перевірте логи на предмет флапів переключення ключів і помилок переговорів

cr0x@server:~$ sudo journalctl -u strongswan --since "2 hours ago" | egrep -i "rekey|established|failed|proposal" | tail -n 20
Dec 27 10:55:03 gw-a charon[1124]: 12[IKE] initiating IKE_SA office-a-office-b[12] to 203.0.113.20
Dec 27 10:55:03 gw-a charon[1124]: 12[IKE] IKE_SA office-a-office-b[12] established between 10.0.0.1[gw-a]...203.0.113.20[gw-b]
Dec 27 10:55:03 gw-a charon[1124]: 12[CHD] CHILD_SA office-a-office-b{8} established with SPIs c9f2a1d1_i c6f8b02f_o and TS 10.10.0.0/16 === 10.20.0.0/16

Що це означає: Чисте встановлення. Якщо бачите повторювані відмови — ймовірно, нестабільний WAN, невідповідні пропозиції або проблеми з NAT.

Рішення: Часті переключення ключів у робочий час: перевірте завантаження CPU, втрати пакетів або надто агресивні lifetime.

Завдання 12: Перевірте стан peer у WireGuard (якщо ви використовуєте WireGuard)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 0u9z4x2m3u9l4t...
  listening port: 51820

peer: 2q8m9n0b1v2c3x...
  endpoint: 203.0.113.20:51820
  allowed ips: 10.20.0.0/16
  latest handshake: 52 seconds ago
  transfer: 1.32 GiB received, 1.08 GiB sent
  persistent keepalive: every 25 seconds

Що це означає: Недавній handshake і лічильники трафіку зростають. Якщо «latest handshake» — «never», у вас проблеми з маршрутами/NAT/фаєрволом.

Рішення: Якщо handshakes є, але трафік не проходить — підозрюйте allowed IPs/маршрути або фаєрвол-політику поза тунелем.

Завдання 13: Підтвердіть переадресацію і policy routing на Linux-шлюзі

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

cr0x@server:~$ ip rule show
0:	from all lookup local
32766:	from all lookup main
32767:	from all lookup default

Що це означає: Форвардинг увімкнено; дивних policy routing правил немає.

Рішення: Якщо forwarding = 0 — ваш шлюз дуже дорогий хост. Увімкніть форвардинг і переконайтеся, що фаєрвол дозволяє форвард.

Завдання 14: Перевірте лічильники фаєрволу для відкидання трафіку тунелю (nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "wg0" ip saddr 10.20.0.0/16 ip daddr 10.10.0.0/16 tcp dport { 53, 443, 445 } accept
    counter packets 184 bytes 11040 drop
  }
}

Що це означає: Політика forward — drop, і у вас є конкретне правило allow з wg0 до office-a. Лічильник на фінальному drop вказує, що щось відкидається.

Рішення: Якщо лічильники drop ростуть під час скарг — перегляньте, яких портів/підмереж не вистачає. Додавайте правила свідомо; не робіть «allow all» від безвиході.

Завдання 15: Виміряйте пропускну здатність (контрольовано), щоб помітити вузькі місця CPU або шейпінг

cr0x@server:~$ iperf3 -c 10.20.8.50 -P 4 -t 10
Connecting to host 10.20.8.50, port 5201
[  5] local 10.10.12.34 port 46318 connected to 10.20.8.50 port 5201
[  7] local 10.10.12.34 port 46334 connected to 10.20.8.50 port 5201
[  9] local 10.10.12.34 port 46344 connected to 10.20.8.50 port 5201
[ 11] local 10.10.12.34 port 46356 connected to 10.20.8.50 port 5201
[SUM]   0.00-10.00  sec   420 MBytes   352 Mbits/sec  sender
[SUM]   0.00-10.00  sec   418 MBytes   350 Mbits/sec  receiver

Що це означає: Ви отримуєте ~350 Mbps через тунель між цими хостами. Це може бути чудово або жахливо залежно від вашого WAN та обладнання шлюзу.

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

Завдання 16: Перевірте CPU шлюзу під навантаженням (підказка про вузьке місце шифрування)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0 (gw-a) 	12/27/2025 	_x86_64_	(4 CPU)

11:14:01 AM  CPU   %usr   %nice    %sys %iowait  %irq  %soft  %steal  %guest  %gnice  %idle
11:14:02 AM  all   35.12    0.00   20.44    0.00  0.00   5.33    0.00    0.00    0.00  39.11
11:14:02 AM    0   80.00    0.00   18.00    0.00  0.00   2.00    0.00    0.00    0.00   0.00
11:14:02 AM    1   10.00    0.00   25.00    0.00  0.00   8.00    0.00    0.00    0.00  57.00
11:14:02 AM    2   20.00    0.00   15.00    0.00  0.00   5.00    0.00    0.00    0.00  60.00
11:14:02 AM    3   30.00    0.00   24.00    0.00  0.00   6.00    0.00    0.00    0.00  40.00

Що це означає: CPU0 завантажений. Це часто вказує на проблему з однією чергою/affinity преривань або процес, що не масштабується. Пропускна здатність VPN може просісти через «гаряче» ядро.

Рішення: Якщо під час піку ви бачите гаряче ядро — подумайте про налаштування IRQ affinity, увімкнення multiqueue, апгрейд обладнання або зміну шифру/оффлоаду (акуратно).

Плейбук для швидкої діагностики

Це потік «п’ять хвилин, без драм». Ви намагаєтесь швидко знайти вузьке місце: маршрутизація, стан тунелю, MTU, DNS або сервіс на далекому кінці.

Перше: чи це справді тунель, чи лише один додаток?

1. Виберіть тестовий хост у кожному офісі (або jump box), яким ви керуєте.
2. Протестуйте TCP до відомого сервісу (наприклад, nc -vz remote-ip 443).
3. Перевірте DNS-резолюцію для того самого імені з обох боків.

Якщо тільки один додаток ламається, а базовий TCP працює — припиніть звинувачувати VPN. Ідіть вгору по стеку (TLS, автентифікація, залежності додатка).

Друге: підтвердьте маршрутизацію і шлях назад

1. Зробіть traceroute в обидві сторони, якщо можна (A→B і B→A). Асиметрична маршрутизація поширена, коли одна сторона має кілька шлюзів.
2. Перевірте маршрути на шлюзах, щоб упевнитися, що кожна підмережа відома і вказує в тунель.
3. Шукайте NAT, де ви його не очікували. NAT в маршрутизованому site-to-site зазвичай є симптомом перекриття або тимчасового патчу.

Третє: sanity check MTU/MSS

1. Запустіть DF ping, щоб знайти приблизний path MTU.
2. Перевірте MSS встановленої TCP-сесії (ss -ti).
3. Якщо ймовірний blackholing — clamp MSS на шлюзі.

Четверте: чи хворий транспортний лінк?

1. Запустіть mtr на 50–200 пакетів, щоб побачити втрати і джиттер.
2. Перевірте помилки/дропи на WAN-інтерфейсах шлюзів.
3. Перевірте, чи канал ISP не насичений (шейпінг або bufferbloat можуть імітувати «повільність VPN»).

П’яте: логи демонів тунелю і стан

1. Для IPsec: підтвердіть, що IKE і child SA інстальовані і стабільні.
2. Для WireGuard: підтвердіть handshakes і що лічильники трафіку зростають.
3. Шукайте періодичні події: переключення ключів, таймаути DPD, зміни endpoint (NAT).

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

1) «Тунель піднятий, але SMB/RDP/файлові передачі зависають»

Симптоми: Ping працює. Малі HTTP-запити працюють. Великі завантаження зависають. Копії SMB стартують швидко, потім зависають.

Корінна причина: MTU blackhole або відсутність MSS-clamping; PMTUD блокується десь.

Виправлення: Визначте path MTU за допомогою DF ping; clamp TCP MSS на VPN-шлюзі; розгляньте зниження MTU тунелю. Повторно протестуйте iperf і реальні передачі.

2) «Працює тільки в одному напрямку»

Симптоми: Офіс A може дістатися Офісу B, але не навпаки. Або якась підмережа може ініціювати, але не отримує відповіді.

Корінна причина: Відсутній зворотний маршрут, асиметрична маршрутизація через інший інтернет-вихід або припущення стану фаєрволу.

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

3) «Працює годину, потім періодично падає»

Симптоми: Періодичні від’єднання. VoIP-дзвінки обриваються через регулярні інтервали. В логах — переключення ключів або DPD таймаути.

Корінна причина: Агресивні lifetime, таймаути NAT-меппінгу або нестабільний WAN з короткими втратами пакетів, що вбивають keepalive’и.

Виправлення: Налаштуйте keepalives/persistent keepalive (WireGuard) або DPD (IPsec). Уникайте надто коротких інтервалів ротації ключів. Якщо за NAT — переконайтеся, що NAT-T і UDP-пінхоли стабільні.

4) «DNS випадково падає, логіни повільні, з’являються помилки Kerberos»

Симптоми: Інтермітентні таймаути внутрішніх імен; іноді автентифікація не проходить; повтори раптово допомагають.

Корінна причина: Клієнти використовують DNS віддалого сайту як первинний; переадресація DNS через хисткий тунель; split-horizon неправильно налаштований; зсув часу.

Виправлення: Віддавайте перевагу локальним резолверам; реплікуйте зони; додайте умовну переадресацію; перевірте NTP на обох сайтах; тримайте DNS-залежності локально, де можливо.

5) «Ми додали NAT щоб впоратися з перекриттями; тепер усе дивно»

Симптоми: Деякі сервіси працюють, інші — ні. Логи показують несподівані source IP. Політики доступу ламаються. Трасування проблем стає археологією.

Корінна причина: Перекриття підмереж, замасковані NAT; додатки спираються на source IP або зворотні пошуки.

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

6) «Пропускна здатність жахлива, але лінк ISP швидкий»

Симптоми: Тести швидкості в інтернеті хороші; передачі через VPN повільні; CPU шлюзу пікає.

Корінна причина: Шифрування обмежене CPU; одне ядро перегрівається; немає offload; погане чергування; малий MTU додає оверхед.

Виправлення: Заміряйте iperf. Перевірте завантаження CPU по ядрам. Апгрейдьте шлюз, налаштуйте IRQ affinity або використайте підтримуваний шлях шифрування/оффлоаду. Не гадати — вимірюйте до/після.

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

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

Компанія отримала два офіси після поглинання. Офіс A тримав все: ідентичність, файли, внутрішні веб-додатки. Офіс B мав невелику мережу, «виглядав добре» і фаєрвол, налаштований кимось роками раніше. План — прямий IPsec site-to-site тунель. Менеджер проекту любив фразу «це просто тунель».

Першого дня тунель піднявся. Всім аплодували. Офіс B досі не міг зайти в CRM за іменем хоста. За IP — працювало. War room негайно звинуватив VPN, бо це було єдине змінене. Команда VPN почала міняти шифри та таймери переключення, наче кулінарне шоу.

Через дві години хтось нарешті запустив dig з клієнта Офісу B. Він використовував DNS Офісу A як primary через тунель. При невеликому навантаженні це працювало. При ранкових логінах DNS-запити ставали в чергу за великими SMB-передачами. Імена таймаутили, автентифікація десятками запитів повторювалася і користувачі бачили «інтернет не працює».

Неправильне припущення було в тому, що DNS — «дрібний трафік» і може їхати разом з усім іншим без пріоритету чи локальності. Виправлення було нудним: додали локальні DNS-резолвери в Офіс B, реалізували conditional forwarding для внутрішніх зон і явно дозволили DNS з вищим пріоритетом. Тунель не змінювався. Результат змінився.

Після цього написали одне операційне правило: «Кожен сайт має мати можливість резолвити внутрішні імена локально під час WAN-відмови.» Це правило врятувало принаймні три інциденти пізніше, включно з одним, коли ISP впав і ніхто не помітив протягом п’ятнадцяти хвилин, бо сайт залишився функціональним.

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

Інша організація мала добру коннективність, але хотіла «більше швидкості». Їх WAN-посилення пройшло, і хтось вирішив, що VPN — вузьке місце. Вони увімкнули набір «перформанс»-опцій на шлюзі: коротші інтервали переключення ключів, агресивний DPD і більш CPU-інтенсивний шифр, бо «сильніше — краще». Також включили шейпінг «щоб згладити», не визначивши цілей.

Тунель піднімався. Більшість трафіку було нормальним. А потім, в точно регулярні моменти, хвиля скарг: дзвінки впали, RDP завис, передачі фалів зупинялися й потім відновлювалися. Візерунок виглядав як годинник-привид.

Це не було привидом. Це була ротація ключів у поєднанні з шейпінгом, що створила затримки в чергах під час переговорів. Пакети переключення змагалися з даними. DPD спрацьовував при піках затримки. Шлюзи скидали й перебирали стан, викликаючи reset сесій. Усі вважали це «рандомною нестабільністю», що насправді була точно відтворюваною.

Відкат виправив негайно: відновили розумні lifetime, пом’якшили DPD і прибрали шейпінг, поки не з’явилися вимірювання. Пізніше додали QoS вибірково для голосу, а не загальний «зробити все красивим». Урок: оптимізація без вимірюваної проблеми — це додавання складності з таймером.

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

Одна команда експлуатації підтримувала hub-and-spoke VPN з двома офісами і невеликою VPC у хмарі. Нічого особливого: два тунелі на сайт, BGP з префікс-фільтрами і робоча перевірка, яка тестувала DNS, TCP/443 і великий пакет ping кожну хвилину з кожної сторони. Дашборди не були красиві, але чесні.

Одного дня Офіс B повідомив «повільно до всього в Офісі A». Стан тунелю був піднятий. З погляду користувача це означало «тунель піднятий, значить додатки винні». Команда додатків готувалась до боротьби.

Моніторинг показав кращу картину: затримка і втрати злетіли лише на шляху, що йшов через ISP #1 в Офісі B. Резервний тунель через ISP #2 був чистим. BGP все ще віддавав перевагу ISP #1, бо тунель «піднятий». Команда відрегулювала метрики BGP, щоб віддати перевагу чистому шляху, і тимчасово зменшила пріоритет поганій лінії.

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

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

1) Чи використовувати IPsec чи WireGuard для site-to-site VPN?

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

2) Чи можна з’єднати два офіси, якщо одна сторона за NAT або carrier-grade NAT?

Зазвичай так. Для IPsec — використовуйте NAT-T (UDP 4500) і переконайтеся, що keepalives/DPD налаштовані. Для WireGuard — persistent keepalive допомагає підтримувати NAT-меппінг. Якщо вхідні підключення неможливі, може знадобитися досяжний хаб (VM у хмарі) і підключення обох сайтів назовні.

3) Чи потрібен статичний публічний IP на обох сайтах?

Це полегшує життя, але не строго необхідно. Динамічні IP працюють з DDNS або через hub-підхід. Все ж для продакшену: платіть за статичні IP, якщо можете. Це дешевше за години, витрачені на дебаг «чому змінився endpoint».

4) Чи варто маршрутизувати весь інтернет-трафік Офісу B через Офіс A?

Тільки якщо є чітка причина (централізовані засоби безпеки, комплаєнс). Інакше тримайте егрегес локальним і маршрутуйте через VPN лише внутрішні префікси. Full-tunnel site-to-site — класичний спосіб створити несподівані відмови.

5) Скільки підмереж слід дозволити через тунель?

Стільки, скільки потрібно. Почніть з конкретних серверних підмереж і потрібних портів. Розширюйте за потреби. «Allow any-any» — шлях до внутрішніх інцидентів між сайтами.

6) Чому все ламається, коли хтось починає великий файл-копіювання?

Найчастіше — MTU/MSS або bufferbloat/насичення WAN-лінку. Перевірте path MTU з DF ping, MSS з ss -ti, виміряйте втрати/затримки з mtr під час копії.

7) Чи можна запускати BGP поверх VPN, чи це занадто складно?

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

8) Як зробити, щоб фейловер не ламав користувацькі сесії?

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

9) Які порти треба відкрити для типового налаштування?

Залежить. Звично: IPsec використовує UDP 500 і UDP 4500 (плюс ESP, якщо не NAT-T). WireGuard використовує один UDP-порт на ваш вибір (часто 51820). Решта внутрішніх дозволених портів — це політика, не вимога VPN.

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

Ні. Шифрування захищає дані в дорозі; воно не захищає від скомпрометованого пристрою на віддаленому боці. Сегментуйте, обмежуйте і логируйте. Припускайте злом, бо реальність вже припускає його.

Наступні кроки, які не соромно показувати пізніше

1. Напишіть IP-план і забороніть перекриття. Якщо перекриття вже є — плануйте перенумерацію замість «тимчасового NAT назавжди».
2. Оберіть маршрутизовані тунелі з чіткими дозволеними префіксами. Уникайте L2-розширення, якщо вам не подобається біль.
3. Виберіть IPsec (IKEv2) або WireGuard на основі того, що ви можете експлуатувати, а не що рекламна презентація обіцяє.
4. Розв’яжіть split vs full tunnel свідомо. За замовчуванням — split. Full tunnel лише з причиною.
5. Зробіть DNS локальним на кожному сайті з переадресацією/реплікацією. Тестуйте резолюцію під час симульованої WAN-відмови.
6. Виправте MTU/MSS рано і перевірте DF ping та реальні передачі. «Пінгується» — це не план тестування.
7. Додайте моніторинг, який відображає біль користувачів: DNS, TCP, втрати/затримки, а не тільки «тунель піднятий».
8. Тестуйте фейловер по-справжньому. Потім документуйте, що ламається (сесії можуть скидатись), щоб керівництво не дивувалось пізніше.

Якщо ви зробите це в такому порядку — отримаєте site-to-site VPN, що поводиться як доросла інфраструктура: нудний, передбачуваний і цікавий лише у тих питаннях, які ви самі обрали.