VPN повна сітка для трьох офісів: коли вона потрібна і як її підтримувати керованою

December 30, 2025 • February 3, 2026 • Читання: 6 хв • Views: 9

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

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

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

Що “повна сітка” реально означає для 3 офісів (і чого не означає)

Для трьох майданчиків — назвімо їх NYC, DAL, SFO — повна сітка означає, що ви будуєте
три тунелі site-to-site: NYC↔DAL, DAL↔SFO, SFO↔NYC. Кожен майданчик має прямий зашифрований шлях до інших.
Ніякого hairpin через центральний хаб.

Це та частина, яку вендори люблять малювати у вигляді акуратного трикутника. У реальному житті «повна сітка» — це не лише тунелі. Це:

Політика маршрутизації: які префікси рекламуються куди й що перемагає, коли існує кілька шляхів.
Політика безпеки: що дозволено схід-захід між офісами.
Операційна політика: як впроваджувати зміни, щоб не зламати половину WAN.
Ідентичність і іменування: DNS, split-horizon, топологія AD site або інший стек аутентифікації.

Для трьох офісів повна сітка не є автоматично «складною». Її легко зробити складною. Ось у чому різниця.

Швидка математика: чому біль зростає

Кількість тунелів у повній сітці — n(n−1)/2. Для 3 сайтів: 3 тунелі. Для 6 сайтів: 15. Для 10 сайтів: 45.
Більшість команд можуть підтримувати 3 тунелі у здоровому стані. Багато команд не можуть постійно підтримувати 15 тунелів без автоматизації та телеметрії.

Цікаві факти і трохи історії (бо ви успадкуєте старі ідеї)

Факт 1: IPsec зародився в 1990-х як частина історії безпеки IPv6, але широко застосувався на IPv4 через… реальність.
Факт 2: «NAT traversal» (UDP 4500) існує тому, що IPsec ESP погано співпрацював з NAT; це було не опцією — це було виживання.
Факт 3: Багато продуктів «site-to-site VPN» усе ще успадковують світогляд від епохи ліній оренди: стабільні кінцеві точки, передбачувані шляхи, менше rekey.
Факт 4: BGP став дефолтним для динамічної маршрутизації WAN не тому, що він дружній, а тому, що він жорстко явний щодо шляхів і політик.
Факт 5: Проблема MTU/MSS у VPN існує десятиліттями; це не «хмарна» проблема — PPP, GRE та IPsec вже ламають пакети раніше.
Факт 6: Split-horizon DNS старший за «zero trust» на роки; це старий інструмент, який залишається релевантним, коли різні мережі потребують різних відповідей.
Факт 7: Великий виграш SD-WAN не в шифруванні (VPN вже це робили); він у централізованому контролі, видимості та виборі шляху при втраті/джиттері.
Факт 8: Топології «повної сітки» були поширені в ранніх корпоративних WAN на Frame Relay PVC — потім всі знову згадали про білінг і перейшли на хаби.

Коли ви фактично потребуєте повної сітки

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

1) Ваш трафік справді між сайтами, а не до дата-центру

Якщо користувачі в NYC постійно звертаються до файлових серверів у DAL, а DAL постійно до збірників у SFO, відправляти все через хаб
— це все одно, що пересилати локальну пошту через інший штат «раді видимості». Ваш хаб стає податком.

2) Вам потрібна ізоляція відмов між сайтами

У hub-and-spoke хаб — це спільний домен відмов: DDoS на канал хаба, оновлення фаєрвола хаба, невірна політика — кожен це відчує.
Сітка може зберегти NYC↔DAL живим, коли SFO має «цікавий» день.

3) У вас кілька інтернет-каналів і ви хочете кращого вибору шляху

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

4) Маєте регульовані вимоги сегментації між сайтами

Це звучить парадоксально («сітка = більше довіри»), але якщо зробити правильно, сітка може зменшити експозицію, не пропускаючи все через хаб,
де все змішується. Можна застосувати парні політики: DAL може потрапляти до фінансів NYC, але не до лабораторії NYC; SFO може звертатися до SSO NYC, але не до DAL OT.

5) Ви готові керувати цим як системою, а не як одноразовим проєктом

Повна сітка — це операційне зобов’язання. Якщо у вас немає моніторингу, версіонування конфігів і процесу змін, ви будуєте гарний трикутник,
який перетвориться на сучасне мистецтво при першій зміні CPE провайдера.

Перефразована ідея (John Allspaw): надійність походить від того, як робота виконується в реальних умовах, а не від ідеальних планів.
Mesh VPN карає за думки про «ідеальний план».

Коли повна сітка — неправильний інструмент

Найпоширеніша причина, через яку команди обирають повну сітку — емоційна: «Я не хочу хаб». Добре. Але уникання хаба шляхом створення трьох незалежних,
непослідовно керованих тунелів — це не стратегія. Це хобі.

Не робіть повної сітки, якщо у вас насправді є центральний сайт

Якщо більшість трафіку — «філія → HQ», будуйте hub-and-spoke. Зробіть хаб відмовостійким. Дайте йому кілька uplink-ів. Слідкуйте за ним агресивно.
Ви отримаєте простішу політику і кращий контроль над blast-radius.

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

Якщо NYC працює на брандмауерному пристрої, DAL — на Linux-боксі, якого хтось назвав «vpn1», а SFO — на cloud router з іншим IKE-стеком,
ви підписуєтесь на відлагодження трьох діалектів одного протоколу. Це не інженерія. Це лінгвістика.

Не робіть повної сітки, якщо ваша проблема — «віддалений доступ»

Site-to-site mesh для мереж. Remote access для людей і пристроїв. Якщо ви намагаєтесь вирішити доступ ноутбука до офісу шляхом з’єднання офісів,
отримаєте мережу, яка ідеально з’єднана і все одно не знає, хто користувач.

Жарт #1: Повна сітка схожа на груповий чат — класно, поки хтось не додасть принтер, і раптом усі отримують сповіщення о 3 ранку.

Варіанти проєктування: IPsec, WireGuard, SD-WAN та «дешево і весело»

Варіант A: IPsec (IKEv2) site-to-site

IPsec нудний у хорошому сенсі: широко підтримується, інтероперабельний, зрозумілий фаєрволам і зазвичай прийнятний для аудиту.
Він також наповнений ручками, які можуть нашкодити: proposals, lifetimes, DPD, NAT-T, PFS, поведінка фрагментації та «допомога» від вендора.

Якщо йдете IPsec, віддавайте перевагу:

IKEv2 замість IKEv1. Менше привидів.
Маршрутним тунелям (VTI) замість політично-базованих, коли можливо. Маршрути належать маршрутизації.
Послідовним пропозиціям у всіх тунелях, ідеально — один набір, який всі пристрої добре підтримують.

Варіант B: WireGuard site-to-site

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

Для трьох сайтів WireGuard може бути відмінним, якщо:

Ви контролюєте обидва кінці (Linux-маршрутизатори або пристрої, що добре його підтримують).
Ви можете стандартизувати ту саму позицію фаєрвола і моніторинг.
Ви комфортно працюєте з динамічною маршрутизацією окремо (статичні маршрути або BGP/OSPF зверху).

Варіант C: SD-WAN (керована політика + оверлеї)

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

Для трьох офісів SD-WAN може бути зайвим — якщо ви не ростете, не маєте кількох каналів на сайт або не потребуєте керування на рівні застосунків.

Варіант D: Hub-and-spoke зі «смарт» маршрутизацією (часто правильний компроміс)

Якщо хочете «переважно пряме», але без складності повної сітки, зробіть hub-and-spoke з:

Резервними хабами (active/active або active/passive).
BGP між сайтами і хабами.
Політикою, що віддає перевагу локальному виходу в інтернет і хабу для критичних сервісів.

Ви отримуєте керовану топологію і при цьому уникнете частини hairpin для трафіку в інтернет.

Маршрутизація, DNS і ідентичність: де повна сітка помирає на практиці

Модель маршрутизації: статичні маршрути проти динамічної маршрутизації

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

Динамічна маршрутизація (зазвичай BGP) зверху на маршрутних тунелях — «дорослий» варіант:

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

Вибір підходу для точно трьох сайтів

Ось упереджений погляд:

Статичні маршрути підходять, якщо в кожного офісу один LAN-префікс, немає перекриттів мереж і ви не плануєте додавати сайти незабаром.
BGP вартий зусиль, якщо будь-який офіс має кілька внутрішніх сегментів, ви хочете чистого failover або плануєте рости за межі трьох сайтів.

Split-horizon DNS: тихий обов’язок

Більшість міжофісного болю — не IP-з’єднання. Це розв’язування імен і виявлення сервісів:

DNS NYC повертає внутрішню IP, яку може досягти тільки NYC, якщо маршрути вірні.
Клієнти в DAL розв’язують «fileserver» в неправильний сайт, бо хтось налаштував пошуковий суфікс і вважає, що цього достатньо.
Split tunneling SaaS надсилає DNS в одне місце, а трафік в інше, і потім ви чуєте «в мене на телефоні працює».

Визначте, чи хочете ви:

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

DNS, чутливий до сайту, потужний. Це також шлях до випадкового створення розподіленої системи, поки ви цього не помітите.

Перекриваючі підмережі: брехня «ми ніколи цього не зробимо»

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

Контролі безпеки, що не дозволяють сітці стати раєм для бокового руху

Повна сітка збільшує зв’язність. Зловмисники люблять зв’язність.
Ваше завдання — гарантувати, що сітка збільшує націлену зв’язність, а не випадкову довіру.

Принцип: маршрутуйте все, що потрібно, але за замовчуванням майже нічого не дозволяйте

Маршрутизація і фаєрвол — різні шари. Ви можете рекламувати маршрути широко (для простоти) і все одно застосовувати сувору політику на L3/L4.
Або ж міцно фільтрувати маршрути і тримати правила фаєрвола простішими. Оберіть один як основну площину контролю і дотримуйтесь.

Патерн сегментації, що працює

Використовуйте зони й явні allow-list-и:

NYC-users → DAL-apps: дозволити 443, 22 (тільки до bastion), 445 (тільки до файлового кластера), заборонити решту.
DAL-users → SFO-users: заборонити (більшість організацій не потребує «user LAN → user LAN» зовсім).
Усі сайти → моніторинг: дозволити тільки до централізованих метрик/логів.

Жарт #2: Якщо ви дозволяєте «any-any» між офісами «тільки на зараз», вітаємо — ви винайшли машину часу, де «зараз» триває три роки.

Як зробити це керованим: іменування, автоматизація, моніторинг, контроль змін

Стандартизувати примітиви

Виберіть послідовну модель і дотримуйтесь її:

Маршрутні тунелі з VTI і передбачуваними іменами (наприклад, vti-nyc-dal).
Послідовні підмережі для кожного сайту (уникайте хитрощів). Приклад: NYC=10.10.0.0/16, DAL=10.20.0.0/16, SFO=10.30.0.0/16.
Послідовні BGP ASN якщо ви використовуєте BGP: приватні ASN по сайтах, задокументовані.
Послідовний макет зон фаєрвола: users, servers, management, guest.

Робіть конфіг набираним у diff

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

Моніторинг: вимірюйте те, що ламається першим

VPN ламаються банальними способами:

Втрати пакетів і джиттер ламають голос/VDI перед тим, як «тунель впаде».
Проблеми MTU ламають конкретні застосунки (SMB, деякі HTTPS), тоді як ping працює.
Рекейї флаплять і викликають короткі brownout-и, які користувачі описують як «рандомні».

Моніторте:

Стан тунелю (IKE SA, child SA, здоров’я handshake).
Затримку/втрати між майданчиками (не лише до інтернету).
Пропускну здатність і дропи на VPN-інтерфейсі та WAN-інтерфейсі.
Суміжність маршрутизації (стан BGP сесії, зміни кількості маршрутів).

Контроль змін, який вас не ненавидітиме

Вам не потрібна бюрократія. Потрібна звичка:

Робіть зміни у вікно обслуговування.
Майте реальний план відкату (збережений конфіг, протестована процедура).
Змінюйте один тунель за раз, якщо ви не робите координований cutover.
Після зміни: перевірте маршрутизацію, DNS, справжній applicational flow.

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

Коли «VPN повільний» або «сайт B не дістає сайт C», вам не до філософських дискусій про топологію.
Потрібно швидко знайти вузьке місце. Ось порядок, який працює в продакшені.

Спочатку: це справді VPN?

Перевірте, чи проблема специфічна для застосунку (SMB проти HTTPS проти RDP).
Перевірте, чи тільки в одному напрямку (асиметрична маршрутизація, стан фаєрвола).
Перевірте, чи тільки одна пара сайтів (NYC↔DAL добре, DAL↔SFO зламано).

По-друге: стан підложки (шлях ISP) важливіший за суперечки про оверлей

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

По-третє: стан тунелю та крипто

Чи стабільний IKE SA, чи відбуваються rekey/флапи?
Чи є ретрансміси, відкидання фрагментів, проблеми NAT-T?
Чи активовано апаратне offload (якщо релевантно), або оновлення прошивки його вимкнуло?

По-четверте: маршрутизація і MTU (два тихі вбивці)

Маршрутизація: перевірте next-hop і переконайтесь, що немає hairpin-петль.
MTU: тестуйте з DF; за потреби clamp MSS.

По-п’яте: політика (фаєрвол) і ідентичність (DNS/AD)

Відмови фаєрвола між зонами. Шукайте неявні deny.
DNS, що повертає недоступні цілі; неправильні AD site mapping; split-brain DNS.

Практичні завдання: команди, очікуваний результат і яке рішення прийняти

Нижче практичні завдання, які можна виконати з Linux-шлюзів VPN або діагностичних хостів на кожному сайті.
Сенс не в самій команді, а в циклі: спостерігай → інтерпретуй → приймай рішення.

Завдання 1: Підтвердити базову досяжність між шлюзами сайту (підложка)

cr0x@server:~$ ping -c 5 203.0.113.20
PING 203.0.113.20 (203.0.113.20) 56(84) bytes of data.
64 bytes from 203.0.113.20: icmp_seq=1 ttl=54 time=18.7 ms
64 bytes from 203.0.113.20: icmp_seq=2 ttl=54 time=19.1 ms
64 bytes from 203.0.113.20: icmp_seq=3 ttl=54 time=18.6 ms
64 bytes from 203.0.113.20: icmp_seq=4 ttl=54 time=120.3 ms
64 bytes from 203.0.113.20: icmp_seq=5 ttl=54 time=19.0 ms

--- 203.0.113.20 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 18.6/39.1/120.3/40.6 ms

Що це означає: Немає втрат пакетів, але сплеск затримки вказує на джиттер або транзієнтну заторність.
Рішення: Якщо сплески корелюють зі «VPN повільний», розслідуйте шлях ISP, насичення або bufferbloat перед тим, як чіпати налаштування VPN.

Завдання 2: Протрасувати публічний шлях, щоб виявити дивні об’їзди

cr0x@server:~$ traceroute -n 203.0.113.20
traceroute to 203.0.113.20 (203.0.113.20), 30 hops max, 60 byte packets
 1  198.51.100.1  1.012 ms  0.941 ms  0.915 ms
 2  198.51.100.9  3.122 ms  3.101 ms  3.094 ms
 3  203.0.113.1   9.884 ms  9.860 ms  9.841 ms
 4  203.0.113.20  18.992 ms  18.970 ms  18.948 ms

Що це означає: Короткий шлях, стабільні хопи. Якщо ви бачите раптові довгі шляхи або timeouts — підложка підозріла.
Рішення: Якщо шлях змінився недавно, відкрийте тикет до ISP або переключіться на вторинний канал, якщо він є.

Завдання 3: Перевірити інтерфейси тунелю й лічильники (здоров’я оверлею)

cr0x@server:~$ ip -s link show dev vti-nyc-dal
6: vti-nyc-dal: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1436 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none
    RX:  bytes  packets  errors  dropped overrun mcast
      987654321 1234567  0       12      0       0
    TX:  bytes  packets  errors  dropped carrier collsns
      876543210 1122334  0       0       0       0

Що це означає: RX drop-и на тунелі часто вказують на проблеми MTU, чергування або політику, що відкидає вище по ланцюгу.
Рішення: Якщо лічильники drops зростають під час скарг, перейдіть до MTU/MSS тестів і перевірте логи фаєрвола на VTI.

Завдання 4: Підтвердити маршрут до віддаленої підмережі (правильність маршрутизації)

cr0x@server:~$ ip route get 10.30.5.10
10.30.5.10 via 169.254.30.1 dev vti-nyc-sfo src 10.10.0.1 uid 0
    cache

Що це означає: Ядро відправить трафік до SFO через тунель NYC↔SFO.
Рішення: Якщо це неочікувано йде через DAL (hairpin), виправте пріоритети маршрутизації (metrics/BGP policy) перед тим, як звинувачувати застосунок.

Завдання 5: Виявити асиметричну маршрутизацію (класичне «працює в одну сторону»)

cr0x@server:~$ tcpdump -ni vti-nyc-dal host 10.20.8.50 and tcp port 445 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vti-nyc-dal, link-type RAW (Raw IP), snapshot length 262144 bytes
IP 10.10.9.25.49812 > 10.20.8.50.445: Flags [S], seq 112233, win 64240, options [mss 1360,sackOK,TS val 123 ecr 0,nop,wscale 7], length 0
IP 10.10.9.25.49812 > 10.20.8.50.445: Flags [S], seq 112233, win 64240, options [mss 1360,sackOK,TS val 1123 ecr 0,nop,wscale 7], length 0
IP 10.10.9.25.49812 > 10.20.8.50.445: Flags [S], seq 112233, win 64240, options [mss 1360,sackOK,TS val 2123 ecr 0,nop,wscale 7], length 0
5 packets captured

Що це означає: SYN ретрансміти без SYN-ACK на цьому інтерфейсі. Або шлях повернення інший (асиметричний), або блокується.
Рішення: Захопіть трафік на віддаленому сайті також. Якщо SYN-ACK повертається через інший тунель, виправте симетрію маршрутизації або очікування стану фаєрвола.

Завдання 6: Правильно протестуйте MTU з DF (не довіряйте лише «ping працює»)

cr0x@server:~$ ping -M do -s 1372 -c 3 10.30.5.10
PING 10.30.5.10 (10.30.5.10) 1372(1400) bytes of data.
1400 bytes from 10.30.5.10: icmp_seq=1 ttl=63 time=32.1 ms
1400 bytes from 10.30.5.10: icmp_seq=2 ttl=63 time=31.8 ms
1400 bytes from 10.30.5.10: icmp_seq=3 ttl=63 time=32.0 ms

--- 10.30.5.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 31.8/32.0/32.1/0.1 ms

Що це означає: Payload 1372 (1400 байт ICMP) проходить з DF — отже path MTU принаймні 1400.
Рішення: Якщо більші розміри падають (наприклад, 1472), встановіть MTU тунелю відповідно і clamp TCP MSS, щоб уникнути проблем з фрагментацією.

Завдання 7: Перевірити помилки «потрібна фрагментація» (курильний пістолет)

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

--- 10.30.5.10 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1012ms

Що це означає: Локальний інтерфейс має MTU 1436; кадри 1500 байт не пройдуть через тунель.
Рішення: Clamp MSS (наприклад, 1360) і переконайтесь, що внутрішні інтерфейси не припускають jumbo/1500 end-to-end через VPN.

Завдання 8: Перевірити стан сесії BGP і кількість маршрутів

cr0x@server:~$ vtysh -c "show ip bgp summary"
BGP router identifier 10.10.0.1, local AS number 65010
BGP table version is 42
3 BGP AS-PATH entries
1 BGP community entries

Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd
169.254.20.2    4      65020     812     799       42    0    0 02:11:34        18
169.254.30.2    4      65030     805     790       42    0    0 02:09:57        22

Що це означає: Обидва сусіди Established; ви отримуєте префікси. Раптове падіння до 0 префіксів — це маршрутизований аутейдж, навіть якщо тунель «up».
Рішення: Якщо префікси відсутні, перевірте фільтри, досяжність next-hop і чи не змінилась IP-адреса інтерфейсу тунелю.

Завдання 9: Перевірити, які маршрути ви фактично експортуєте (уникати випадкового транзиту)

cr0x@server:~$ vtysh -c "show ip bgp neighbors 169.254.20.2 advertised-routes"
BGP table version is 42, local router ID is 10.10.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.10.0.0/16      0.0.0.0                  0         32768 i
*> 10.10.50.0/24     0.0.0.0                  0         32768 i

Що це означає: Ви рекламуєте лише префікси NYC, а не «весь світ».
Рішення: Якщо бачите маршрути DAL, які рекламуються в SFO через NYC, можливо ви ненавмисно зробили NYC транзитом; виправте export policy.

Завдання 10: Підтвердити IP forwarding і rp_filter (Linux-бокс може укусити)

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

Що це означає: Форвардинг увімкнений, але строгий reverse-path filtering може відкидати асиметричні потоки (поширено в багатотунельних сітках).
Рішення: Якщо у вас асиметрія маршрутизації за дизайном або під час failover, встановіть rp_filter у loose (2) на релевантних інтерфейсах.

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

cr0x@server:~$ sudo swanctl --list-sas
nyc-dal: #12, ESTABLISHED, IKEv2, 1d 02:11:04, 198.51.100.10[nyc]...203.0.113.20[dal]
  local  'nyc' @ 198.51.100.10[4500]
  remote 'dal' @ 203.0.113.20[4500]
  AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_256
  nyc-dal-child: #22, INSTALLED, TUNNEL, reqid 1, 2h 11:04, ESP in UDP SPIs: c1a2b3c4_i c4b3a2c1_o
    AES_GCM_16_256, 12345678 bytes_i, 11223344 bytes_o, rekeying in 31 minutes

Що це означає: Тунель встановлено, child SA інстальовано, лічильники трафіку інкрементуються, рекейк заплановано.
Рішення: Якщо байт-и стоять в 0, поки застосунки падають — скоріш за все у вас проблеми маршрутизації/фаєрвола, а не «VPN помер».

Завдання 12: Слідкувати за рефлапами рекеїв у логах (brownout-и)

cr0x@server:~$ sudo journalctl -u strongswan --since "30 min ago" | tail -n 12
Aug 22 10:11:03 nyc-gw charon[2014]: 12[IKE] rekeying IKE_SA nyc-dal[12]
Aug 22 10:11:04 nyc-gw charon[2014]: 12[IKE] sending CREATE_CHILD_SA request 1 [ SA No KE TSi TSr ]
Aug 22 10:11:09 nyc-gw charon[2014]: 12[IKE] retransmit 1 of request with message ID 47
Aug 22 10:11:14 nyc-gw charon[2014]: 12[IKE] retransmit 2 of request with message ID 47
Aug 22 10:11:19 nyc-gw charon[2014]: 12[IKE] giving up after 3 retransmits
Aug 22 10:11:19 nyc-gw charon[2014]: 12[IKE] deleting IKE_SA nyc-dal[12] between 198.51.100.10[nyc]...203.0.113.20[dal]

Що це означає: Рекеї не вдалися; тунель зруйновано. Користувачі бачать коротке відключення, що виглядає «рандомно».
Рішення: Розслідуйте втрати на підложці, mismatched lifetimes/proposals, NAT-T поведінку або CPU-навантаження під час рекейку.

Завдання 13: Перевірити лічильники політики фаєрвола для міжсайтних дозволів/відмов

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 "vti-nyc-dal" oifname "lan0" ip saddr 10.20.0.0/16 ip daddr 10.10.50.0/24 tcp dport { 443, 445 } accept
    counter packets 1842 bytes 221040 drop
  }
}

Що це означає: Політика за замовчуванням — drop; існує конкретний allow. Останній лічильник-drop ловить щось.
Рішення: Якщо лічильник drop зростає під час інциденту, додайте цілеспрямований allow (або виправте застосунок, щоб він використовував очікувані порти), не відкривайте «any-any».

Завдання 14: Виміряти реальну пропускну здатність і втрати за допомогою iperf3 (без здогадок)

cr0x@server:~$ iperf3 -c 10.20.8.50 -t 10 -P 4
Connecting to host 10.20.8.50, port 5201
[  5] local 10.10.9.25 port 41862 connected to 10.20.8.50 port 5201
[  6] local 10.10.9.25 port 41864 connected to 10.20.8.50 port 5201
[  7] local 10.10.9.25 port 41866 connected to 10.20.8.50 port 5201
[  8] local 10.10.9.25 port 41868 connected to 10.20.8.50 port 5201
[SUM]   0.00-10.00  sec   412 MBytes   346 Mbits/sec  0             sender
[SUM]   0.00-10.00  sec   410 MBytes   344 Mbits/sec                receiver

Що це означає: Ви можете передати ~344 Mbps між сайтами в тестових умовах.
Рішення: Якщо бізнесовий трафік повільніший, дивіться на обмеження на потік, QoS, TCP windowing або вузькі місця на рівні застосунку — не звинувачуйте лише «VPN».

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

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

У компанії було три офіси і акуратна повна сітка. Мережеву діаграму хотілося б використовувати в домашньому завданні з геометрії, що всіх заспокоювало.
Також було припущення: «Якщо тунель up, то маршрути в порядку». Ніхто цього не записав, і припущення поширилося тихо, як пил.

Потім з’явилась зміна: новий VLAN у DAL для лабораторії підрядника. Інженер додав підмережу локально, оновив статичні маршрути на одному тунелі
і пішов далі. Лабораторія могла дістати NYC, тому тікет закрили з веселою приміткою. SFO не могла дістатись до лабораторії, але той шлях не тестували.

Через тиждень pipeline у SFO почав падати, коли намагався витягти артефакти з хоста DAL, який перемістили в новий VLAN.
Збої були неперіодичні, бо деякі jobs все ще брали кешовані артефакти. Команда називала це «нестабільним CI», що означає «ми ще не знаємо, що ламається».

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

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

Інша організація хотіла «максимальної продуктивності», тож ввімкнула агресивні крипто-настроювання і скоротила lifetimes, бо хтось прочитав, що рекеї безпечніші.
Також під час rollout увімкнули debug-логування і забули вимкнути. Класика.

Доторкало деякий час — все виглядало нормально. Потім понеділок: більше користувачів, більше трафіку, більше рекеїв. Шлюзи стали підскакувати по CPU під час рекейків,
а оскільки lifetime були короткі, сплески були частими. Користувачі не бачили повного ауту. Вони бачили мікро-аутейджі: дзвінки падали, SMB гальмував,
RDP зависав на п’ять секунд і потім повертався.

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

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

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

Компанія з фінансами запустила три офіси в mesh, але вони ставилися до VPN як до продакшену: конфіги в version control, вікна змін і простий runbook для валідації.
Це не було гламурно. Але саме тому вони іноді спали.

Одного дня ISP в одному місті мав частковий аутейдж: не повний дроп, а стільки втрат, щоб зіпсувати UDP-інкапсульований трафік.
Тунель лишався «up» достатньо довго, щоб всіх збити з пантелику, але симптоми застосунків були миттєві — джиттер голосу, повільний доступ до файлів, дивні таймаути.

Їхній моніторинг це зловив, бо вони вимірювали втрати між шлюзами і відстежували IPSec ретрансміси. On-call виконав runbook:
перевірити втрати підложки, підтвердити лічильники тунелю, виконати MTU тести і переключити трафік на вторинний канал. Вони не сперечалися з мережею.
Переключили навантаження.

Найкраща частина: у них був пост-інцидентний чеклист, який включав кроки «відновити первинний», тому failback не став другим інцидентом.
Без геройств. Просто відпрацьована нудьга.

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

1) Симптом: «Ping працює, а SMB/HTTPS зависає»

Корінь: Path MTU blackhole; TCP-пакети більші за MTU тунелю відкидаються, ICMP fragmentation-needed блокується або MSS не затиснутий.

Виправлення: Встановіть MTU тунелю відповідно і clamp TCP MSS на вході/виході VPN. Підтвердіть DF-ping тестами і реальними застосунками.

2) Симптом: «Тунель up, але одна підмережа недосяжна»

Корінь: Відсутня реклама маршруту (статичний маршрут не додано, BGP-фільтр, неправильний next-hop), або перекриття підмереж.

Виправлення: Перевірте таблиці маршрутів на всіх трьох сайтах; якщо BGP — перевірте advertised/received routes і prefix-lists. Виправте перекриття перенумерацією.

3) Симптом: «Працює з NYC до DAL, не працює з DAL до NYC»

Корінь: Асиметрична маршрутизація плюс stateful firewall drop; rp_filter на Linux; політика маршрутів відправляє повернення іншим тунелем.

Виправлення: Забезпечте симетрію для stateful потоків або використовуйте stateless правила там, де доречно. Встановіть rp_filter у loose при потребі.

4) Симптом: «Випадкові 10–30 секундні аутейджі»

Корінь: Rekey flaps через втрати пакетів, mismatched lifetimes, CPU-стрибки або занадто агресивні DPD налаштування.

Виправлення: Узгодьте lifetimes/proposals; налаштуйте DPD; розслідуйте підложкові втрати; масштабування CPU; уникайте екстремальних інтервалів рекейків.

5) Симптом: «DAL дістає SFO тільки коли тунель NYC вимкнений»

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

Виправлення: Виправте політику маршрутизації: віддавайте перевагу прямому тунелю, фільтруйте транзитні маршрути, встановіть правильні local-pref/weight і next-hop-self, де треба.

6) Симптом: «DNS працює, але повернений IP недосяжний з одного офісу»

Корінь: Split-horizon mismatch; site-aware записи не узгоджені з маршрутизацією; внутрішні сервіси прив’язані до локальних підмереж.

Виправлення: Вирішіть модель DNS (єдиний вигляд або site-aware). Зробіть її явною і протестуйте розв’язування + з’єднання з кожного сайту.

7) Симптом: «Пропускна здатність погана тільки для одиничних потоків»

Корінь: Пер-потокове shaping, проблеми TCP window, або застосунок використовує один стрім; оверголов шифру зменшує ефективний MSS/пропускну спроможність.

Виправлення: Використайте iperf3 з паралельними потоками для порівняння. Розгляньте QoS, TCP tuning або зміни на стороні застосунку; не «збільшуйте смугу» автоматично.

8) Симптом: «Все помирає під час бекапів»

Корінь: Немає QoS і насичення uplink; bufferbloat; бекапи захоплюють тунель.

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

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

Покроковий план: побудуйте триофісну сітку, яка вас не переслідуватиме

Визначте топологію з причини: затримка/пропускна здатність/ізоляція відмов. Запишіть причину.
Нормалізуйте адресацію: виберіть неперекриваючі RFC1918 діапазони для кожного сайту; зарезервуйте місце для росту.
Виберіть тип тунелю: за замовчуванням — маршрутні тунелі (VTI).
Виберіть маршрутизацію: статична, якщо дійсно мала і стабільна; BGP, якщо щось змінюється частіше, ніж раз на квартал.
Визначте зони безпеки: users, servers, management, guest, voice/OT за потреби.
Напишіть міжсайтову політику: allow-list-и по парах зон; deny user-to-user LAN за замовчуванням.
План DNS: один вигляд або site-aware; задокументуйте, які імена розв’язуються куди на кожному сайті.
Базовий MTU/MSS: встановіть MTU тунелю, clamp MSS і підтвердіть DF-ping тестами.
Спостережуваність: стан тунелю, BGP стан, loss/latency probe-и, дропи інтерфейсів і семплінг логів.
Управління конфігом: експортуйте конфіги; зберігайте у VCS; використовуйте послідовні імена.
Тестування: для кожної зміни тестуйте з кожного сайту хоча б один хост у кожній віддаленій підмережі.
Тренування відмов: симулюйте тунель down, деградацію каналу і DNS mis-route. Відпрацьовуйте failover і failback.

Пре-чендж чекліст (зробіть перед змінами в продакшені)

Поточні конфіги експортовані і збережені (з мітками часу і ID зміни).
Процедура відкату написана і здійсненна без інтернет-героїв.
Список критичних потоків між сайтами (порти + підмережі + відповідальні).
Комунікація вікна обслуговування (включно з тим, «що зламається»).
Відкриті моніторингові дашборди: втрати/затримка, стан тунелю, BGP, помилки інтерфейсів.

Пост-чендж верифікаційний чекліст (частина, яку всі пропускають)

Тунелі встановлені і стабільні (без флапів у логах).
Маршрути присутні на всіх сайтах (очікувана кількість префіксів).
MTU тест проходить на очікуваному розмірі (DF ping).
Щонайменше одна реальна транзакція застосунку для кожної пари сайтів (не лише ping).
Лічильники deny фаєрвола не зашкалюють.
Документацію оновлено: префікси, піринги, політики і винятки.

FAQ

1) Для трьох офісів, чи повна сітка завжди краща за hub-and-spoke?

Ні. Якщо більшість трафіку йде до «ядра» (дата-центр/HQ), hub-and-spoke простіший і часто надійніший.
Повна сітка краща, коли site-to-site трафік великий або потрібна парна ізоляція відмов.

2) Чи використовувати статичні маршрути або BGP для трисайтної сітки?

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

3) Який найшвидший спосіб уникнути витоків маршрутів у сітці?

Використовуйте prefix-lists (або еквівалент) і рекламайте кожному сусіду тільки локальні префікси. Припускайте, що будь-який сусід охоче прийме нісенітницю, якщо ви його не зупините.
Також вирішіть, чи дозволено будь-якому сайту бути транзитом. Зазвичай відповідь — «ні».

4) Чому мій тунель показує “up”, але користувачі все одно скаржаться?

Бо «up» зазвичай означає, що control plane живий (IKE SA). Data plane може бути зламаний MTU blackhole, втратами пакетів, петлями маршрутизації або відмовами фаєрвола.
Виміряйте втрати/затримку, перевірте лічильники і валідуйте реальні потоки застосунків.

5) Чи потрібно клаmpити MSS?

Якщо effective MTU через VPN менше за 1500 (поширено з IPsec/NAT-T), clamp MSS часто найпростіший спосіб запобігти важко відлагоджуваним зависанням.
Підтвердіть DF ping тестами і спостерігайте, чи «великі відповіді» падають.

6) Чи може WireGuard безпечно робити повну сітку між офісами?

Так, якщо ви правильно керуєте ключами і дисципліновані з AllowedIPs та політиками фаєрвола. WireGuard полегшує тунелі; він не автоматизує політику маршрутизації.
Для трьох сайтів він відмінний на Linux-шлюзах з уніфікованими конфігами і моніторингом.

7) Як не дозволити сітці стати кошмаром з точки зору безпеки?

Default-deny міжсайтового форвардингу, сегментуйте по зонах і явно дозволяйте тільки потрібні потоки.
Логуйте відмови з розумною швидкістю. І тримайте доступ до управління поза загальною міжсайтовою тканиною.

8) Що моніторити, щоб помітити проблеми раніше за користувачів?

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

9) А як щодо високої доступності для трьох сайтів?

HA допомагає, але це не магія. Почніть з двох інтернет-каналів, якщо можливо, потім резервні шлюзи з протестованим методом failover.
Переконайтесь, що failover не змінює source IP так, щоб ламати очікування пірів, і відпрацюйте failback.

10) Як зрозуміти, чи вартий SD-WAN для трьох офісів?

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

Висновок: практичні наступні кроки

Для трьох офісів повна VPN-сітка або чиста низькозатримкова тканина, або трикутник перекладання відповідальності. Різниця не в топології.
Вона в тому, чи ви ставитесь до маршрутизації, DNS, MTU і політик як до першокласних громадян, і чи експлуатуєте цю систему дисципліновано.

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

Запишіть реальну причину для сітки (затримка, пропускна здатність, ізоляція). Якщо не можете — перегляньте hub-and-spoke.
Зробіть інвентар підмереж і усуньте перекриття до того, як вони помножаться.
Виконайте MTU DF-ping тести і clamp MSS, де потрібно.
Якщо використовуєте статичні маршрути — порахуйте їх. Якщо кількість дратує — перейдіть на BGP.
Додайте моніторинг втрат/затримки між шлюзами і рекейк-флапів. «Тунель up» — не спостережуваність.
Впровадьте default-deny міжсайтову політику і додайте явні allow-list-и для реальних бізнес-потоків.

Побудуйте сітку так, ніби вам доведеться відлагоджувати її о 2:00 ночі. Бо доведеться. Мета — щоб вона була нудною, коли це станеться.

Схожі статті

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