WireGuard full mesh: коли варто робити прямі тунелі між офісами (і коли ні)

Ви помічаєте це спершу в дрібницях: мережеві шейри здаються «липкими», VoIP дзвінки між офісами звучать, ніби хтось говорить через акваріум, а улюблена панель CFO завантажується досить повільно, щоб звинуватити «хмару».
Потім ви дивитесь на шлях і розумієте, що трафік з Офісу A до Офісу B зациклюється через центральний дата-центр за сотні кілометрів лише тому, що так налаштували VPN у 2017, і ніхто не хоче це чіпати.

Full mesh на WireGuard виглядає як панацея: просто з’єднайте кожен офіс напряму з кожним іншим. Латентність падає, вихід в інтернет залишається локальним, і ви перестаєте платити «податок за центральний хаб».
Це також чудовий спосіб побудувати операційну сніжинку, яка вибухне, щойно ви додасте 13-й сайт.

Що ви насправді вирішуєте: топологія та домени відмов

Люди говорять про «full mesh», наче це функція продукту. Це ні.
Це ставка.
Ставка полягає в тому, що скорочення довжини шляху (і уникнення вузла-«пляшкового горла») того варте, щоб збільшити кількість відносин, якими треба керувати: ключі, endpoints, маршрути, правила фаєрвола, моніторинг і радіус ураження інцидентів.

WireGuard сам по собі — не найскладніше. WireGuard — чистий, мінімальний протокол із невеликим кодом і передбачуваною поведінкою.
Складність — у системі навколо нього: політика маршрутизації, реальність NAT, управління адресами, граничні випадки MTU/фрагментації та люди, які роблять зміни в масштабі.

Математика масштабування, яку ніхто не хоче бачити на слайді

У full mesh з n сайтами у вас n(n-1)/2 тунелів (або взаємних peer-зв’язків), якщо всі намагаються піритись між собою напряму.
Це означає: 10 сайтів → 45 зв’язків. 20 сайтів → 190. 50 сайтів → 1225. Зростання квадратичне, а ваша витримка — ні.

Ви можете автоматизувати генерацію і розповсюдження конфігів. Варто це робити. Але автоматизація не знімає операційну складність; вона лише дозволяє створювати її швидше.

Що WireGuard робить добре (і чого він не прикидається)

WireGuard дає автентифіковане шифрування, просту модель інтерфейсу і приємну властивість: якщо немає трафіку — майже немає стану.
Але WireGuard не робить динамічної маршрутизації. Він не робить вибір шляху. Він не скаже «peer B упав; використайте peer C».
Ці поведінки походять від вашого шару маршрутизації (статичні маршрути, BGP/OSPF через FRR, політика маршрутизації, логіка SD-WAN) та вашого мережевого дизайну.

Наївний висновок для надійних систем старий і вірний: тримайте контрольну площину простою, але не прикидайтеся, ніби вона відсутня.

Один афоризм, щоб не обманювати себе

Hope is not a strategy. — General Gordon R. Sullivan

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

Коли прямі тунелі між офісами виправдані

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

1) У вас є чутливий в реальному часі трафік між сайтами, що страждає від hairpin-латентності

VoIP, відео, VDI, віддалений робочий стіл до on-prem додатків, OT/SCADA телеметрія та все інтерактивне.
Якщо Офіс A і Офіс B мають 8 ms відгук, а ваш хаб — 40 ms детур, математика буває жорстока.
Джиттер часто гірший за чисту латентність, а перевантаження хабу додає джиттер безкоштовно.

Прямий тунель дає стабільний шлях, який не конкурує з іншим трафіком, що йде до хабу.

2) Ваш хаб — це вузьке місце, яке ви не можете (або не повинні) масштабувати нескінченно

Іноді хаб — пара віртуальних фаєрволів з ліцензіями вартістю як яхта. Іноді це тісний DC-канал, який закупівля не оновить до наступного кварталу, тобто «ніколи».
Full mesh розподіляє навантаження і зменшує режим «усі дороги ведуть до Риму».

3) Вам потрібні локальні виходи в інтернет, але ви хочете міцного site-to-site зв’язку

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

4) Ваш WAN-транспорт гетерогенний і ви хочете різноманітності шляхів

В офісах може бути fiber, cable, LTE або дивний «бізнес-бродбенд», що здається алергічним до аптайму.
З мульти-WAN на сайті ви можете мати кілька WireGuard peer-ів і політику маршрутизації, щоб тримати трафік подалі від найгіршого лінка.
Mesh не дає автоматично трафік-інжинірингу, але дає більше варіантів шляхів для інжинірингу.

5) У вас невелика кількість сайтів і сильна культура автоматизації

Full mesh керований при 3–8 сайтах. Може бути прийнятним при ~10–15, якщо ви централізовано генеруєте конфіги, відстежуєте виділення IP, вимагаєте рецензії і тестуєте зміни.
Після цього потрібен серйозний план маршрутизації і поширення конфігів, інакше ви будуєте машину Руба Голдберга, яка лусне після першої кавової аварії.

6) Вам потрібно обмежити відмови парами сайтів

У дизайні hub-and-spoke нестабільність хабу стає проблемою для всіх. У mesh — flap тунелю впливає лише на два кінці.
Оцей вужчий радіус ураження може бути різницею між «одиничним тикетом» і «компанійною інцидентною нарадою».

7) Ви мігруєте з MPLS і очікування any-to-any закладено

Організації, що виросли на MPLS, звикли, що будь-який офіс може зв’язатися з будь-яким іншим. Коли ви замінюєте це hub-and-spoke, користувачі помічають.
Mesh (або частковий mesh з маршрутизацією) може відповідати очікуванням із меншими політичними битвами.

Коли full mesh — пастка

Mesh зазнає поразки передбачуваними способами. Пораження — не екзотичні криптобаги; це «люди і таблиці маршрутів».
Ось коли я уникну full mesh і виберу інший шаблон.

1) У вас більше сайтів, ніж уваги операційної команди

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

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

2) Сайти за ворожим NAT або з частою зміною IP

WireGuard може працювати за NAT, але йому все одно треба знайти іншу сторону.
Якщо обидві сторони за carrier-grade NAT зі змінними адресами і без стабільного rendezvous (або ви не можете використати relay), прямі тунелі стануть хобі для підтримки аптайму.

3) Потрібна чітка сегментація або відповідність вимогам

Full mesh схиляє до «всі можуть дістатися всіх», якщо ви не впровадите серйозну політику маршрутизації/фаєрвола.
Якщо ви в регульованому середовищі або у вас бізнес-одиниці, які не повинні ділитися мережами, mesh перетворюється на головоломку з реалізації політик.
Чим більше країв — тим більше місць, де ви випадково дозволите трафік.

4) Ви не терпите людської помилки в AllowedIPs

AllowedIPs — одночасно механізм контролю доступу WireGuard і селектор маршрутизації. Це елегантно. Це також гострий ніж.
Помилковий запис AllowedIPs може зробити чорну діру в трафіку, вкрасти трафік у правильного peer-а або створити маршрутизовані петлі в поєднанні з системними маршрутами.

5) Вашій команді потрібен «налаштував і забув»

Якщо у вас невелика команда з рідкісними змінами, обирайте дизайн з меншим числом рухомих частин:
hub-and-spoke, подвійні хаби або кілька регіональних хабів.
Ви не менш професійні, обираючи нудне. Ви більш працевлаштовані.

Короткий жарт №1: Full mesh — як груповий чат: чудово з п’ятьма людьми, і катастрофа, коли додають усю тітку.

Варіанти дизайну, що не обмежуються «mesh або нічого»

Hub-and-spoke (один хаб) — стартовий набір

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

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

Подвійний хаб — «доросла» версія

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

Часто це найкраще співвідношення ціни та якості: ви уникаєте квадратичного зростання і підвищуєте стійкість.

Регіональні хаби (частковий mesh) — латентність без божевілля

Створіть 3–6 регіональних агрегаційних точок; офіси роблять mesh всередині регіону або підключаються до найближчого регіону. Міжрегіональний трафік іде hub-to-hub.
Ви зберігаєте більшість виграшів по латентності і драматично зменшуєте кількість peer-ів.

Mesh з динамічною маршрутизацією (FRR + BGP) — «серйозний мережевий» варіант

Якщо наполягаєте на mesh у масштабі — не робіть це на статичних маршрутах в надії.
Запустіть маршрутизуючий демон (зазвичай FRR) і обмінюйтеся маршрутами через WireGuard. Нехай шар маршрутизації обробляє досяжність і відкат.

Заувага: ви ввели справжню контрольну площину маршрутизації. Потрібно її захистити, моніторити і підтримувати консистентною. Це того варте, але не безкоштовно.

Оверлей + relay для NATed сайтів — прийміть реальність

Деякі сайти не можуть забезпечити стабільний inbound. У такому випадку розгляньте relay (VPS або хаб), до якого обидві сторони можуть дістатися.
Це не «чистий mesh», але дає робочу досяжність з передбачуваною поведінкою.

Цікаві факти та історичний контекст

• WireGuard створив Jason A. Donenfeld у середині 2010-х з метою бути компактним, сучасним і аудитованим у порівнянні з традиційними VPN-стеками.
• Інтеграція в ядро Linux відбулася у 2020, що суттєво змінило операційну історію: оновлення і продуктивність стали простішими для багатьох команд.
• WireGuard використовує Noise-подібний хендшейк (ідеї з Noise protocol framework), віддаючи перевагу сучасним примітивам і мінімальній складності переговорів.
• Він свідомо уникає алгоритмічної агілості — історично контроверсійний вибір, але такий, що зменшує можливості для даунгрейтів і конфігураційної складності в розгортаннях.
• AllowedIPs — механізм подвійного призначення (маршрутизація + контроль доступу). Цей дизайн елегантний і одночасно головне джерело тикетів «чому трафік йде туди?».
• Full mesh VPN існували задовго до WireGuard: ранні корпоративні WAN-дизайни прагнули any-to-any ще до того, як SD-WAN зробив це маркетинговою фішкою.
• Біль MTU старший за VPN. Проблеми фрагментації з’явилися в ранніх IP-мережах; інкапсуляція VPN просто повертає ту ж фізику в іншій упаковці.
• «Hub-and-spoke» став популярним частково через централізацію фаєрволів — простіше аудитується одна точка, ніж 40 країв, особливо при потребі відповідності.
• Операційні режими відмов переважають криптографічні у зрілих VPN: витоки маршрутів, припущення про NAT і прогалини в моніторингу призводять до більше відмов, ніж криптографія.

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

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

Завдання 1: Перевірити, що WireGuard запущений і відбувається хендшейк

cr0x@server:~$ sudo wg show
interface: wg0
  public key: pGZ2...Qm8=
  private key: (hidden)
  listening port: 51820

peer: 7y8N...aZk=
  endpoint: 198.51.100.10:51820
  allowed ips: 10.60.1.0/24, 10.60.200.2/32
  latest handshake: 32 seconds ago
  transfer: 1.21 GiB received, 980.45 MiB sent
  persistent keepalive: every 25 seconds

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

Рішення: Якщо handshake застарілий/ніколи не був, поки не чіпайте маршрути. Спочатку виправте досяжність (фаєрвол, UDP, endpoints, keepalive).

Завдання 2: Перевірити, що інтерфейс має правильні адреси

cr0x@server:~$ ip -br addr show dev wg0
wg0             UNKNOWN        10.60.200.1/24

Що це означає: Оверлейна IP налаштована. «UNKNOWN» звичайне для WireGuard інтерфейсів.

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

Завдання 3: Перевірити, що маршрути ядра відповідають вашому наміру

cr0x@server:~$ ip route show table main | grep -E 'wg0|10\.60\.'
10.60.1.0/24 dev wg0 scope link
10.60.2.0/24 dev wg0 scope link
10.60.200.0/24 dev wg0 proto kernel scope link src 10.60.200.1

Що це означає: Існують маршрути, що вказують підмережі на wg0. Якщо ви використовуєте wg-quick, він встановить маршрути на основі AllowedIPs.

Рішення: Якщо маршрут підмережі відсутній — перевірте AllowedIPs для peer-а, що повинен його нести, або ваш маршрутизуючий демон, якщо використовуєте BGP.

Завдання 4: Виявити «крадіжку маршрутів» через перекривання AllowedIPs

cr0x@server:~$ sudo wg show wg0 allowed-ips
7y8N...aZk= 10.60.1.0/24 10.60.200.2/32
Jp2c...9Qs= 10.60.0.0/16 10.60.200.3/32

Що це означає: Один peer претендує на 10.60.0.0/16, що перекриває 10.60.1.0/24. WireGuard вибирає більш специфічний префікс, але широкі префікси — популярна пастка.

Рішення: Видаліть широкі AllowedIPs, якщо ви не навмисно робите «default via this peer» дизайн. Будьте явними для кожного сайту.

Завдання 5: Перевірити, чи NAT або фаєрвол блокує UDP/51820

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

Що це означає: Машина слухає UDP/51820 на всіх інтерфейсах.

Рішення: Якщо ніщо не слухає — ви дебажите проблему сервісу/конфігу, а не мережевого шляху.

Завдання 6: Валідовувати правила фаєрвола для порту WireGuard

cr0x@server:~$ sudo nft list ruleset | grep -n '51820'
117: udp dport 51820 accept

Що це означає: Є правило allow. Якщо ви не бачите такого — вважайте, що порт заблоковано, поки не доведено протилежне.

Рішення: Додайте явні allow-правила і тимчасово логгируйте дропи, якщо гонисьте за переривчастими handshake.

Завдання 7: Протестувати базову досяжність через тунель (ICMP)

cr0x@server:~$ ping -c 3 10.60.200.2
PING 10.60.200.2 (10.60.200.2) 56(84) bytes of data.
64 bytes from 10.60.200.2: icmp_seq=1 ttl=64 time=8.12 ms
64 bytes from 10.60.200.2: icmp_seq=2 ttl=64 time=8.25 ms
64 bytes from 10.60.200.2: icmp_seq=3 ttl=64 time=8.09 ms

--- 10.60.200.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2005ms
rtt min/avg/max/mdev = 8.089/8.155/8.246/0.070 ms

Що це означає: Базова L3 досяжність працює і латентність у очікуваному діапазоні.

Рішення: Якщо ping працює, а додатки ні — підозрюйте MTU, TCP MSS або політику фаєрвола для форвардованого трафіку.

Завдання 8: Знайти проблеми MTU за допомогою DF-пінгів

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

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

Що це означає: Локальний MTU інтерфейсу (або обмеження PMTU на шляху) не дозволяє такий розмір пакета. Наклад інкапсуляції робить це звичним.

Рішення: Зменшіть MTU для wg0 (наприклад до 1380 або 1360) або прищепіть TCP MSS на форвардованому трафіку. Не вгадуйте — тестуйте розміри, поки не пройде.

Завдання 9: Інспектувати шлях та місця стрибків латентності (traceroute)

cr0x@server:~$ traceroute -n 10.60.2.10
traceroute to 10.60.2.10 (10.60.2.10), 30 hops max, 60 byte packets
 1  10.60.200.2  8.431 ms  8.207 ms  8.189 ms
 2  10.60.2.10    8.922 ms  8.743 ms  8.701 ms

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

Рішення: Якщо трафік hairpin-иться, виправте преференцію маршрутів (метрики, політика, локальний преф) або видаліть конфліктні маршрути.

Завдання 10: Підтвердити, що форвардинг увімкнений (класична підводна міна)

cr0x@server:~$ sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 0

Що це означає: IPv4 форвардинг включений. IPv6 форвардинг вимкнений (може бути правильно або пояснювати IPv6-only відмови).

Рішення: Якщо ви маршрутизуєте між офісними LAN-ами, зазвичай хочете увімкнути форвардинг на ваших VPN-рутерах. Для IPv6 вирішіть свідомо; не робіть чорних дір випадково.

Завдання 11: Дивитися пакети, щоб довести, де вони вмирають

cr0x@server:~$ sudo tcpdump -ni wg0 host 10.60.2.10 and tcp port 445 -c 6
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:01:14.220123 IP 10.60.1.50.51234 > 10.60.2.10.445: Flags [S], seq 2209001, win 64240, options [mss 1360,sackOK,TS val 111 ecr 0], length 0
12:01:15.221004 IP 10.60.1.50.51234 > 10.60.2.10.445: Flags [S], seq 2209001, win 64240, options [mss 1360,sackOK,TS val 112 ecr 0], length 0
12:01:16.221998 IP 10.60.1.50.51234 > 10.60.2.10.445: Flags [S], seq 2209001, win 64240, options [mss 1360,sackOK,TS val 113 ecr 0], length 0

Що це означає: SYN повторно передається без SYN-ACK. Трафік заходить у тунель, але не отримує відповіді.
Зазвичай це фаєрвол на дальній стороні, відсутній маршрут назад або асиметрична маршрутизація, через яку відповіді виходять іншим шляхом.

Рішення: Перевірте шлях повернення: маршрути на цільовому LAN, політики фаєрвола і правила NAT. Якщо відповіді не повертаються тим самим шляхом — виправте симетрію маршруту.

Завдання 12: Виявити асиметричну маршрутизацію за допомогою політик

cr0x@server:~$ ip rule show
0:      from all lookup local
1000:   from 10.60.2.0/24 lookup 100
32766:  from all lookup main
32767:  from all lookup default

Що це означає: Є політичне правило, що примушує трафік із 10.60.2.0/24 використовувати таблицю 100. Якщо таблиця 100 виводить в інтернет замість wg0, ви створили асиметрію.

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

Завдання 13: Перевірити, що rp_filter не відкидає легітимний форвардований трафік

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

Що це означає: Суворий reverse path filtering може відкидати пакети, коли шляхи повернення не збігаються з тим, що ядро вважає «найкращим маршрутом». Це болить у мультихомед і політично-маршрутизованих дизайнах.

Рішення: Для складної маршрутизації поставте rp_filter = 2 (loose) на релевантних інтерфейсах або переробіть дизайн для симетрії. Не відключайте його всюди без думки.

Завдання 14: Заміряти реальну пропускну здатність і знайти CPU або MTU обмеження

cr0x@server:~$ iperf3 -c 10.60.200.2 -P 4 -t 10
Connecting to host 10.60.200.2, port 5201
[SUM]   0.00-10.00  sec  1.05 GBytes   902 Mbits/sec  0             sender
[SUM]   0.00-10.00  sec  1.04 GBytes   893 Mbits/sec  12             receiver

Що це означає: Ви отримуєте ~900 Mbps з низькими ретрансмітрами. Якщо бачите значно менші числа — перевірте CPU, MTU або шейпінг на WAN.

Рішення: Якщо CPU завантажений під час iperf — роутер неправильно підібраний за потужністю або потрібний hardware offload (або просто менше тунелів на тому пристрої).

Завдання 15: Перевірити завантаження CPU під час шифрування

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

12:02:01 AM  CPU   %usr %nice %sys %iowait %irq %soft  %idle
12:02:02 AM  all   62.00  0.00  30.00   0.00  0.00  6.00   2.00
12:02:02 AM    0   78.00  0.00  20.00   0.00  0.00  2.00   0.00
12:02:02 AM    1   60.00  0.00  36.00   0.00  0.00  4.00   0.00
12:02:02 AM    2   55.00  0.00  35.00   0.00  0.00  8.00   2.00
12:02:02 AM    3   55.00  0.00  29.00   0.00  0.00  10.00  6.00

Що це означає: Ви майже не маєте idle CPU під час передачі трафіку. WireGuard ефективний, але може наситити слабкі роутери при високій пропускній здатності.

Рішення: Масштабуйте апаратне забезпечення, зменшіть конкуренцію або зменшіть кількість high-throughput тунелів на пристрої (регіональні хаби замість full mesh).

Завдання 16: Підтвердити MSS-clamping, якщо є NAT або MTU-обмеження

cr0x@server:~$ sudo iptables -t mangle -S | grep -E 'TCPMSS|wg0'
-A FORWARD -o wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Що це означає: SYN-пакети мають MSS відкоригований, щоб уникнути проблем фрагментації. Це часто «виправляє» дивні затримки додатків, які ping не покаже.

Рішення: Якщо бачите затримки, пов’язані з MTU — додайте clamping на краю VPN. Якщо воно вже є і проблеми лишаються — протестуйте фактичний PMTU і зменшіть MTU wg0.

Завдання 17: Перевірити, що endpoint peer-а — це те, що ви думаєте

cr0x@server:~$ sudo wg show wg0 endpoints
7y8N...aZk= 198.51.100.10:51820

Що це означає: WireGuard показує поточний endpoint, що використовується. Якщо peer роумить (зміна NAT), це оновлюється після отримання пакетів.

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

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

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

Спочатку: вирішіть, то це проблема тунелю чи маршруту/шляху

1. Перевірте handshake і лічильники: wg show. Якщо handshake застарілий/ніколи, це проблема досяжності/NAT/фаєрвол/ключів.
2. Перевірте куди йде трафік: ip route get <dest> і traceroute -n. Якщо трафік hairpin-иться через хаб — це пріоритет маршрутів або відсутність прямих маршрутів.
3. Захопіть кілька пакетів: tcpdump -ni wg0. Якщо SYN-и виходять, але SYN-ACK нема — це шлях повернення або фаєрвол на стороні приймача.

Друге: ізолюйте MTU та фрагментацію (мовчазний вбивця)

1. Запустіть DF-пінги зі зростаючими розмірами: ping -M do -s 1200/1300/1400.
2. Якщо падає при скромних розмірах — зменшіть MTU wg0 і/або активуйте MSS-clamping.
3. Повторно протестуйте реальний додаток (SMB, HTTPS, RDP). Помилки MTU люблять ілюзії «працює для дрібних речей».

Третє: вирішіть, throughput це, CPU чи WAN-шейпінг

1. Запустіть iperf3 через тунель для базової оцінки.
2. Слідкуйте за CPU з mpstat під час тесту.
3. Перевірте втрати/джиттер з ping і на наявність дропів з лічильників інтерфейсу (ip -s link).

Четверте: перевірте політичну маршрутизацію і саботаж rp_filter

1. ip rule show для несподіваних політик маршрутизації.
2. sysctl net.ipv4.conf.all.rp_filter коли існують асиметричні шляхи.
3. Виправляйте дизайн, а не лише симптоми. Але якщо треба латати — поставте rp_filter у loose на потрібних інтерфейсах і задокументуйте чому.

Короткий жарт №2: проблеми MTU — це мережевий еквівалент «check engine» лампи: нечітко, загрозливо і якось завжди ваша проблема.

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

1) «Тунель піднятий, але працюють лише деякі додатки»

Симптом: Ping і дрібні HTTP-запити працюють; SMB, SSH з більшими payload-ами або HTTPS uploads зависають.
Корінна причина: MTU/PMTUD чорна діра через наклад інкапсуляції; ICMP «fragmentation needed» блокується; MSS не прищеплений.
Виправлення: Поставте MTU для wg0 консервативно (зазвичай ≈1380), і прищепіть MSS на форвардованих TCP SYN. Перевірте DF-пінгами.

2) «Handshakes зупиняються через кілька хвилин, якщо немає трафіку»

Симптом: Latest handshake стає застарілим; трафік відновлюється лише після ручного ping з однієї сторони.
Корінна причина: NAT-мапінг спливає; ні одна сторона не ініціює оновлення; нема keepalive на NATed стороні.
Виправлення: Налаштуйте PersistentKeepalive = 25 (або подібне) на стороні за NAT. Переконайтесь, що фаєрвол дозволяє UDP повернення.

3) «Трафік до Офісу B йде до Офісу C і там помирає»

Симптом: Неправильний peer отримує трафік; traceroute показує несподіваний перший хоп; tcpdump показує пакети, що виходять не тим тунелем.
Корінна причина: Перекриваючі AllowedIPs або широкі префікси, встановлені для зручності; крадіжка маршрутів загальним префіксом у поєднанні з метриками OS.
Виправлення: Робіть AllowedIPs точними для кожного сайту; уникайте 0.0.0.0/0 і великих summary, якщо ви дійсно цього не маєте на увазі. Аудитуйте з wg show allowed-ips.

4) «Працює з A до B, але не з B до A»

Симптом: Односторонні потоки; SYN-и видно лише в одному напрямку; відповіді виходять в інтернет або інший WAN.
Корінна причина: Асиметрична маршрутизація через політичні таблиці, dual WAN або відсутні шляхи повернення на LAN-рутері.
Виправлення: Переконайтеся, що шлях повернення вказує назад на WireGuard-роутер; обережно використовуйте source-based routing; розгляньте таблиці маршрутів на підмережу.

5) «Після додавання нового офісу випадково ламаються інші офіси»

Симптом: Додавання нового peer-а призводить до випадкових збоїв у інших місцях; періодичні чорні діри.
Корінна причина: Перекриття адрес (дубль тунельних IP або LAN-підмереж), або AllowedIPs випадково включає чужу підмережу.
Виправлення: Впровадьте IPAM для оверлею і LAN-діапазонів; відкидайте дублікати в CI; запускайте перевірку перекриття маршрутів перед деплоєм.

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

Симптом: iperf показує низькі Mbps; CPU idle; сплески втрат пакетів; продуктивність змінюється по часу доби.
Корінна причина: WAN-шейпінг, bufferbloat або перевантаження ISP-шляху; іноді UDP-політика на бізнес-бродбенді.
Виправлення: Підтвердьте стійкими тестами; додайте QoS/SQM на краю; розгляньте мульти-WAN з відкатом; не звинувачуйте WireGuard за характер провайдера.

7) «Все ламається під час ротації ключів»

Симптом: Частина тунелів повертається, частина — ні; handshake ніколи не з’являється для підмножини.
Корінна причина: Непослідовний розгорт конфігів; старі public keys все ще посилаються; застарілі конфіги не перезапущені; часткова автоматизація.
Виправлення: Ротуйте поетапно (додавайте нові ключі паралельно де можливо), перезавантажуйте детерміновано і верифікуйте handshake автоматичними перевірками.

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

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

Середня компанія розширилася з шести офісів до одинадцяти менш ніж за рік. Мережна команда вирішила «закінчити те, що почали» і побудувати full mesh зі статичними WireGuard конфігами.
Їхнє припущення: «Це офіси; публічні IP стабільні.» Це було вірно для fiber-сайтів. Це було смішно невірно для двох нових локацій на «тимчасовому» бродбенді, що став постійним.

Одного ранку понеділка два офіси втратили досяжність до трьох інших. Не всі. Достатньо, щоб створити хаос напівпрацюючих сервісів: присутність телефону впала, але дзвінки іноді працювали; мережеві шейри з’являлися, але не відкривалися; принтери показували offline.
Моніторингова панель була зеленою, бо хаб-тунелі були в порядку, а команда зробила health checks лише для branch-to-hub.

Корінна причина була прозаїчна: ті бродбенд-канали змінили IP за вихідні. Деякі peer-и оновили endpoints через роумінг (бо NATed сторона ініціювала трафік), а деякі — ні (бо інші сайти ніколи не ініціювали).
Отож половина mesh-у сконвергувала, а інша половина зафризилася з «latest handshake: 3 days ago».

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

Урок: mesh передбачає симетрію досяжності і стабільне відкриття. Якщо у вас цього немає — ви не будуєте mesh; ви будуєте розподілену гру вгадувань.

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

Інша компанія ненавиділа латентність між двома регіонами у їхньому hub-and-spoke VPN.
Хтось запропонував «просту перемогу»: додати прямі тунелі між усіма офісами Східного регіону і усіма офісами Західного. Зву чало розумно — аж поки не зустрілося з BGP summary і людським оптимізмом.

Вони вже використовували динамічну маршрутизацію в дата-центрі. Щоб уникнути анонсу десятків малих підмереж, вони сумували маршрути на межі офісу.
Потім ввімкнули cross-region mesh-лінки і імпортували summary без строгих фільтрів, бо вікно змін було коротким, а план відкату — «вимкнути і зробити вигляд, що цього не було».

Тиждень все було добре. Потім один роутер у Східному регіоні неправильно анонсував summary через баг в шаблоні конфігу.
Раптом трафік для великої частини Східного регіону пішов неправильним шляхом, по mesh-лінку, і потім відкидався фаєрволом, що ніколи не очікував transit-трафік.

Аварія була болючою, бо спершу виглядала як «випадкова повільність SaaS». WAN-графіки були нормальні; хаб був здоровий; лише підмножина внутрішніх додатків впала.
Знайти погане summary допоміг packet capture і diff маршрутних таблиць.

Вони залишили mesh-лінки, але перестали ставитися до політики маршрутизації як до побічного квесту.
Строгі prefix-фільтри, max-prefix ліміти і валідація маршрутів стали обов’язковими. Оптимізація була норм, а відсутність запобіжників — ні.

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

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

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

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

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

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

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

Вирішіть, чи справді вам потрібен full mesh

1. Перелічіть основні міжофісні потоки: VoIP, SMB, ERP, реплікація БД, backup-трафік. Поставте поруч приблизну пропускну здатність і чутливість до латентності.
2. Порахуйте сайти зараз і через 18 місяців. Якщо ви рухаєтеся понад ~15, припустіть, що вам потрібна автоматизація маршрутизації і/або частковий mesh.
3. Класифікуйте endpoints: стабільний публічний IP, динамічний IP, за CGNAT, dual WAN, LTE backup. Mesh не любить невизначеності.
4. Визначте модель безпеки: плоска any-to-any, сегментована або «лише для певних додатків». Mesh плюс сегментація вимагають дисципліни політик.
5. Виберіть домени відмов свідомо: хочете, щоб «відмова хабу впливала на всіх» чи «відмова тунелю впливає лише на пару»?

Будуйте так, ніби збираєтесь експлуатувати

1. Виділіть оверлейні IP через IPAM (навіть простий реєстр у Git). Ніколи не «просто візьміть».
2. Стандартизуйте імена інтерфейсів: wg0 для site-to-site, wg-mgmt для management тощо. Послідовність економить час під час інциденту.
3. Генеруйте конфіги з source-of-truth. Людські правки mesh-конфігів — це пенсійний план для вашого майбутнього терапевта.
4. Визначте шаблони AllowedIPs: лише LAN-префікси по сайтах; уникайте великих summary без політики маршрутизації і рецензії.
5. Встановіть MTU свідомо і задокументуйте причину. Якщо не зробите — ви знову дізнаєтесь про це під час простою, і це дорогий урок.
6. Плануйте ротацію ключів: графік, радіус ураження і кроки верифікації. Зробіть це процедурою, а не ритуалом.

Експлуатуйте з запобіжниками

1. Моніторинг: алерти на застарілі handshakes для критичних peer-ів, зростання packet loss і CPU-сатурацію на VPN-рутерах.
2. Управління змінами: кожне додавання/видалення сайту має бути відтворюваним і підлягати рецензії. Mesh підсилює помилки.
3. Тестування: після кожної зміни запускайте ping/DF ping/iperf до щонайменше одного peer-а і одного хосту в віддаленому LAN.
4. Виявлення дрейфу: зберігайте знімки конфігів і стану маршрутизації; робіть diff регулярно. «Ми нічого не міняли» зазвичай неправда.

ЧаПи

1) Чи безпечніший WireGuard full mesh, ніж hub-and-spoke?

Не автоматично. Безпека WireGuard полягає в управлінні ключами і обмеженнях peer-ів. Mesh може збільшити поверхню атаки, бо є більше країв і більше місць для помилок в AllowedIPs чи правилах фаєрвола.
Якщо робите mesh — ставте політику на першому місці: обмежуйте маршрути, впроваджуйте сегментацію і регулярно аудитуйте.

2) Яка найбільша практична перевага прямих тунелів між офісами?

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

3) Який найбільший операційний недолік full mesh?

Кількість peer-ів і радіус ураження змін. Додавання сайту стає оновленням для багатьох peer-ів. Ротація ключів і відлагодження стають комбінаційними проблемами, якщо ви не автоматизуєте і не моніторите серйозно.

4) Скільки сайтів — це «забагато» для статичного full mesh?

Приблизно: понад 10–15 сайтів статичний mesh стає неприємним, якщо ваша автоматизація і дисципліна маршрутизації не на високому рівні. Після 20 зазвичай хочеться динамічної маршрутизації і/або регіональних хабів.

5) Чи варто запускати BGP через WireGuard?

Якщо вам потрібен масштаб, відкат і менше статичних маршрутів — так. BGP (через FRR) — солідний вибір. Але це не чарівництво.
Потрібно впровадити prefix-фільтри, max-prefix ліміти і моніторинг, або помилка маршрутизації перетвориться на компанійний outage.

6) Як справлятися з офісами з динамічними IP?

Використовуйте PersistentKeepalive на NATed боці, щоб він міг роумити і підтримувати NAT-мапінг, і віддавайте перевагу стабільним rendezvous-точкам (хаби/relay) для таких сайтів.
Очікуйте, що «чистий прямий mesh скрізь» буде крихким, якщо багато сайтів мають нестабільні endpoints.

7) Чи можна робити active-active тунелі між офісами?

Не лише за допомогою WireGuard. WireGuard дає зашифровані лінки; маршрутизація вирішує, як їх використовувати.
Active-active зазвичай реалізується через ECMP у маршрутизуючому демонові, або балансування на рівні додатку. Будьте обережні: ECMP разом з асиметричними шляхами може зламати stateful фаєрволи та middlebox-и.

8) Чому WireGuard використовує AllowedIPs для маршрутизації?

Це дизайнерський вибір, щоб зберегти WireGuard мінімальним: він вирішує, до якого peer спрямувати пакет на основі збігу префікса в destination.
Це зменшує конфігураційну поверхню, але робить правильність вашою відповідальністю. Трактуйте AllowedIPs як production-код.

9) Чи варто NAT-ити трафік через site-to-site тунелі?

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

10) Який найчистіший спосіб уникнути перекриття LAN-підмереж?

Впровадьте стандарт адресації рано (виділення для кожного сайту) і застосовуйте його через IPAM і рев’ю. Перекриття — одна з основних причин «mesh проклятий» поведінки.

Практичні наступні кроки

Якщо ви вирішуєте, чи будувати прямі офіс-до-офіс WireGuard тунелі, зробіть це в такому порядку:

1. Заміряйте поточну hairpin-латентність і джиттер між офісами, які нарікають найбільше.
2. Прототипуйте один прямий тунель між двома сайтами і валідовуйте: стабільність handshake, MTU, throughput і шлях повернення.
3. Виберіть топологію на основі кількості сайтів і стабільності endpoints: full mesh (мало/стабільно), partial mesh (регіонально) або dual hubs (зазвичай найкращий компроміс).
4. Автоматизуйте генерацію конфігів перед тим, як масштабуєтесь понад кілька сайтів. Якщо почекаєте — ви ніколи не наздоженете.
5. Встановіть запобіжники: фільтри маршрутів, sanity-перевірки префіксів, виявлення дрейфу і стандартна політика MTU/MSS.
6. Напишіть runbook поки ще все здається очевидним. Майбутній ви буде втомленим і підозрілим під час інциденту.

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