MikroTik WireGuard site-to-site: чистий шаблон конфігурації для двох офісів

Цілі проєктування (на що ми оптимізуємо)

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

• Чи тунель піднятий? (хендшейк + лічильники байтів зростають, не «враження»)
• Чи шлях правильний? (маршрути і обходи NAT, а не випадкові hairpin‑и)
• Чи стабільна продуктивність? (MTU/MSS, черги, взаємодія з FastTrack)
• Чи може молодший адміністратор підтримувати це? (чисті назви, мінімум правил)
• Чи можна розширити на більше сайтів пізніше? (план адрес і побудова пірів)

Цей шаблон використовує маршрутизовану модель (різні LAN‑підмережі в кожному офісі). Жодного мосту. Жодного L2‑розширення.
Мостування приносить із собою широкомовні шторми та дивні вибори Windows. Вам і так вистачає хвилювань.

Також: тримайте простір IP‑адрес тунелю окремо від LAN‑простору. Якщо ви повторно використовуєте LAN‑підмережу всередині тунелю «бо вона вільна»,
ви створюєте майбутній інцидент. Це відстрочена насолода, але болю в підсумку.

Кілька цікавих фактів (контекст WireGuard + MikroTik)

Кілька коротких контекстних пунктів, які дійсно допомагають приймати кращі рішення:

1. WireGuard навмисно компактний. Його кодова база значно менша в порівнянні зі старими VPN‑стеками, щоб зменшити поверхню атаки і складність аудиту.
2. За замовчанням використовується сучасна криптографія. Немає цирку з перемовинами набору шифрів; протокол обирає вузький набір (наприклад, ChaCha20‑Poly1305), щоб уникнути пониження рівня захисту.
3. «Хендшейк up» не означає «трафік тече». WireGuard може встановити хендшейк навіть якщо маршрутизація/NAT/брандмауер заважають корисним пакункам проходити.
4. WireGuard певним чином безстанний. Він не будує традиційну «сесію», як деякі VPN; піри ідентифікуються за публічними ключами, і кінцеві точки можуть роумити.
5. PersistentKeepalive існує через реальність NAT. Якщо одна сторона за NAT, періодичні пакети утримують відображення, щоб вхідний трафік не помирав після простою.
6. MikroTik додав WireGuard відносно пізно. Підтримка RouterOS з’явилася через роки після популярності WireGuard на Linux, через що в старих парках RouterOS часто зустрічаються мікси legacy VPN і WG.
7. Простота WireGuard переносить складність у маршрутизацію. Це особливість. Ви хочете, щоб маршрути були явними, придатними для огляду й журналювання.
8. Проблеми з MTU стали помітнішими з сучасними веб‑додатками. Більші TLS‑записи, HTTP/2 і «усе інкапсульовано» призводять до того, що фрагментація і чорні діри MTU проявляються як дивні помилки в додатках.

Одна цитата, бо людям операцій теж потрібна поезія:
Все ламається, увесь час. — Вернер Фогельс

Не цинічно. Практично. Ми будуємо системи, які ламаються передбачувано і відновлюються чисто.

План мережі: підмережі, IP тунелю та DNS

Розклад офісів (приклад)

• LAN Офіс A: 10.10.10.0/24 (маршрутизатор: 10.10.10.1)
• LAN Офіс B: 10.20.20.0/24 (маршрутизатор: 10.20.20.1)
• Мережа тунелю WireGuard: 10.99.0.0/30
  • WG IP Офіс A: 10.99.0.1/30
  • WG IP Офіс B: 10.99.0.2/30
• WG UDP‑порт: 13231/udp (виберіть один порт, задокументуйте його)

Чому /30 для тунелю?

Тому що це точка‑до‑точки. Потрібні дві IP. /30 — консервативний варіант, який не дозволяє «допомагати» собі додавати випадкові хости в мережу тунелю.
Якщо плануєте 10+ сайтів, використовуйте /24 і виділяйте /32 для кожного сайту — але для двох офісів не перевантажуйте мережу.

Стратегія DNS (оберіть один, свідомо)

Маршрутизація site‑to‑site — половина боротьби. Іменування — друга половина. Є три розумні опції:

1. Кожен сайт розв’язує локальні імена локально. Якщо Офіс A потребує ресурсів Офісу B, використовуйте FQDN, які розв’язуються на 10.20.20.0/24 і навпаки.
2. Центральний DNS в одному з сайтів. Вказуйте обидва сайти на один авторитетний DNS (досяжний через тунель). Це поширено в корпоративних налаштуваннях, але робить доступність DNS залежною від тунелю.
3. Split‑horizon DNS. Найкраще для гібридних мереж, найдратівливіше в підтримці. Варто використовувати при перекритті сервісів або розділенні cloud/private.

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

Чистий шаблон конфігурації: Офіс A та Офіс B

Шаблон розроблений для RouterOS v7+. Якщо у вас стара версія RouterOS — оновіть. Якщо не можете оновити, вам не будуть доступні приємні речі.
(Це не жарт. Це політика підтримки.)

Угоди з іменування, що врятують вас пізніше

• Назва інтерфейсу: wg-s2s-officeB (щоб майбутній ви розумів, що це)
• Імена списків адрес: lan-officeA, lan-officeB
• Префікси коментарів у правилах брандмауера: S2S-WG: щоб ви могли швидко фільтрувати

Офіс A (публічна IP, слухає)

Припущення:
Маршрутизатор Офісу A має публічний WAN або стабільний проброс портів до нього. Офіс B може бути за NAT.
Ми зробимо так, щоб Офіс A слухав на UDP 13231, а Офіс B ініціював з keepalive.

cr0x@server:~$ cat office-a-routeros.rsc
# Office A: MikroTik RouterOS v7+ WireGuard site-to-site template

# Variables you must set:
# - Replace PUBLIC_WAN_INTERFACE if needed (example: ether1)
# - Set correct LAN interface/list and subnets
# - Paste actual keys (do not reuse this placeholder layout)

# 1) WireGuard interface
/interface/wireguard/add name=wg-s2s-officeB listen-port=13231 mtu=1420 comment="S2S-WG: OfficeA<->OfficeB"

# 2) WireGuard tunnel IP
/ip/address/add address=10.99.0.1/30 interface=wg-s2s-officeB comment="S2S-WG: tunnel IP OfficeA"

# 3) Peer (Office B)
/interface/wireguard/peers/add interface=wg-s2s-officeB public-key="OFFICE_B_PUBLIC_KEY" \
  allowed-address=10.99.0.2/32,10.20.20.0/24 \
  comment="S2S-WG: peer OfficeB"

# 4) Route to Office B LAN via WireGuard
/ip/route/add dst-address=10.20.20.0/24 gateway=wg-s2s-officeB comment="S2S-WG: route to OfficeB LAN"

# 5) Address lists for cleaner firewall rules
/ip/firewall/address-list/add list=lan-officeA address=10.10.10.0/24 comment="OfficeA LAN"
/ip/firewall/address-list/add list=lan-officeB address=10.20.20.0/24 comment="OfficeB LAN"

# 6) Firewall: allow WireGuard inbound on WAN
/ip/firewall/filter/add chain=input action=accept protocol=udp dst-port=13231 in-interface=ether1 \
  comment="S2S-WG: allow WireGuard UDP from WAN"

# 7) Firewall: allow WireGuard interface traffic to the router itself (optional but practical)
/ip/firewall/filter/add chain=input action=accept in-interface=wg-s2s-officeB \
  comment="S2S-WG: allow input from WireGuard (management/ping as needed)"

# 8) Firewall: allow forwarding between LANs over the tunnel
/ip/firewall/filter/add chain=forward action=accept in-interface=wg-s2s-officeB out-interface-list=LAN \
  comment="S2S-WG: allow WG to LAN forwarding"
/ip/firewall/filter/add chain=forward action=accept in-interface-list=LAN out-interface=wg-s2s-officeB \
  comment="S2S-WG: allow LAN to WG forwarding"

# 9) NAT bypass (no masquerade between sites)
# Place this BEFORE any general masquerade rule.
/ip/firewall/nat/add chain=srcnat action=accept src-address=10.10.10.0/24 dst-address=10.20.20.0/24 \
  comment="S2S-WG: no-NAT OfficeA->OfficeB"

# 10) Optional: log drops related to the tunnel during bring-up (disable after)
/ip/firewall/filter/add chain=forward action=log log-prefix="S2S-WG DROP " src-address=10.10.10.0/24 dst-address=10.20.20.0/24 \
  comment="S2S-WG: temporary debug log OfficeA->OfficeB"

Офіс B (за NAT, ініціює)

Офіс B встановить endpoint, що вказує на публічну IP/DNS‑ім’я Офісу A, і поставить persistent-keepalive=25s.
Це не магія; це просто утримання відображення NAT живим.

cr0x@server:~$ cat office-b-routeros.rsc
# Office B: MikroTik RouterOS v7+ WireGuard site-to-site template

# 1) WireGuard interface
/interface/wireguard/add name=wg-s2s-officeA listen-port=13231 mtu=1420 comment="S2S-WG: OfficeB<->OfficeA"

# 2) WireGuard tunnel IP
/ip/address/add address=10.99.0.2/30 interface=wg-s2s-officeA comment="S2S-WG: tunnel IP OfficeB"

# 3) Peer (Office A)
/interface/wireguard/peers/add interface=wg-s2s-officeA public-key="OFFICE_A_PUBLIC_KEY" \
  endpoint-address=203.0.113.10 endpoint-port=13231 persistent-keepalive=25s \
  allowed-address=10.99.0.1/32,10.10.10.0/24 \
  comment="S2S-WG: peer OfficeA"

# 4) Route to Office A LAN via WireGuard
/ip/route/add dst-address=10.10.10.0/24 gateway=wg-s2s-officeA comment="S2S-WG: route to OfficeA LAN"

# 5) Address lists for cleaner firewall rules
/ip/firewall/address-list/add list=lan-officeA address=10.10.10.0/24 comment="OfficeA LAN"
/ip/firewall/address-list/add list=lan-officeB address=10.20.20.0/24 comment="OfficeB LAN"

# 6) Firewall: allow WireGuard traffic (input from WAN not needed if behind NAT, but allow from WG interface)
/ip/firewall/filter/add chain=input action=accept in-interface=wg-s2s-officeA \
  comment="S2S-WG: allow input from WireGuard (management/ping as needed)"

# 7) Firewall: allow forwarding between LANs over the tunnel
/ip/firewall/filter/add chain=forward action=accept in-interface=wg-s2s-officeA out-interface-list=LAN \
  comment="S2S-WG: allow WG to LAN forwarding"
/ip/firewall/filter/add chain=forward action=accept in-interface-list=LAN out-interface=wg-s2s-officeA \
  comment="S2S-WG: allow LAN to WG forwarding"

# 8) NAT bypass (no masquerade between sites)
# Place this BEFORE any general masquerade rule.
/ip/firewall/nat/add chain=srcnat action=accept src-address=10.20.20.0/24 dst-address=10.10.10.0/24 \
  comment="S2S-WG: no-NAT OfficeB->OfficeA"

# 9) Optional: log drops related to the tunnel during bring-up (disable after)
/ip/firewall/filter/add chain=forward action=log log-prefix="S2S-WG DROP " src-address=10.20.20.0/24 dst-address=10.10.10.0/24 \
  comment="S2S-WG: temporary debug log OfficeB->OfficeA"

Жарт №1: WireGuard настільки простий, що ви витратите більшість часу на відлагодження тих частин, які не налаштували — напрочуд у дусі мереж.

Обробка ключів (не робіть це як попало)

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

cr0x@server:~$ ssh admin@office-a 'wg genkey | tee /tmp/wg.key | wg pubkey > /tmp/wg.pub && ls -l /tmp/wg.* && cat /tmp/wg.pub'
-rw------- 1 admin admin 45 Dec 28 10:12 /tmp/wg.key
-rw-r--r-- 1 admin admin 45 Dec 28 10:12 /tmp/wg.pub
hF2m3dZyJf1q3oV6n8r2b1P9kY0aQk7mZxv6b2rNQXo=

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

Брандмауер і NAT: що дозволяти, а що відмовляти

Політика брандмауера має бути явною. «Ми дозволяємо WireGuard» — це не політика; це настрій.
Для site‑to‑site вам потрібно:

• Input: дозволити UDP‑порт 13231 на маршрутизатор (тільки на боці, що слухає на публічному WAN)
• Forward: дозволити LAN↔WG трафік (жорстко обмежте, якщо можете)
• NAT: accept (обхід) трафіку між сайтами перед загальною маскараде

Про FastTrack (специфічно для MikroTik)

FastTrack може бути класним, поки ним не стане. Залежно від версії RouterOS і налаштувань, FastTrack може обходити частини connection tracking і mangle,
і це може заважати формуванню трафіку VPN, обліку брандмауера або правилам MSS‑клампінгу.

Моє правило: не FastTrack‑ьте трафік, який заходить чи виходить через WireGuard, поки ви не переконалися, що він поводиться передбачувано. Якщо вмикаєте — робіть винятки та вимірюйте.

Обхід NAT: найпоширеніша причина «з’єднання є, але нічого не працює»

Якщо ви маскуруєте трафік OfficeA→OfficeB, Офіс B побачить пакети від адреси тунелю маршрутизатора Office A або від WAN IP, а не від оригінального клієнта.
Це ламає аудит, може порушити ACL і перетворює відлагодження на сумний квест.

Додайте явні правила srcnat action=accept для міжсайтових підмереж і розмістіть їх перед загальною маскараде.
Потім залиште короткий коментар на правилі маскараде, щоб попередити майбутнього вас не змінювати порядок.

Дизайн маршрутизації: статичні маршрути без сюрпризів

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

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

MTU, MSS‑клампінг і чому «малі ping’и працюють» — пастка

WireGuard інкапсулює пакети в UDP. Інкапсуляція додає накладні витрати. Накладні зменшують ефективний MTU. Це нормально.
Типовий режим відмови також звичний: деякі мережі відкидають ICMP «потрібна фрагментація», тому Path MTU Discovery ламається.
Потім великі TCP‑пакети губляться, і користувачі кажуть «деякі сайти завантажуються, деякі — ні».

Встановіть MTU WireGuard у консервативне значення (1420 — поширена відправна точка). Потім тестуйте великими ping’ами і реальним TCP.
Якщо бачите дивні симптоми — клампіть TCP MSS на трафіку через тунель.

Правило MSS‑клампінгу (приклад)

Це практичне виправлення для проблем чорної діри MTU. Воно не замінює розуміння шляху, але утримує продакшн стабільним.

cr0x@server:~$ cat mss-clamp-routeros.rsc
# Apply on both sides if needed
/ip/firewall/mangle/add chain=forward action=change-mss new-mss=1360 protocol=tcp tcp-flags=syn \
  in-interface=wg-s2s-officeB out-interface-list=LAN comment="S2S-WG: clamp MSS WG->LAN"
/ip/firewall/mangle/add chain=forward action=change-mss new-mss=1360 protocol=tcp tcp-flags=syn \
  in-interface-list=LAN out-interface=wg-s2s-officeB comment="S2S-WG: clamp MSS LAN->WG"

Рішення: додавайте MSS‑клампінг тільки якщо спостерігаєте проблеми, пов’язані з MTU (або знаєте, що проходите через канали з меншим MTU).
Клампінг всього підряд «на всяк випадок» може знизити пропускну здатність. Не катастрофа, але не культовуйте сліпо.

Операційні завдання: команди, виводи й рішення (12+)

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

Завдання 1: Перевірити, що інтерфейс WireGuard існує і працює (RouterOS)

cr0x@server:~$ ssh admin@office-a 'interface/wireguard/print detail where name="wg-s2s-officeB"'
 0 name="wg-s2s-officeB" mtu=1420 listen-port=13231 private-key="<hidden>" running=yes

Значення виводу: running=yes підтверджує, що інтерфейс операційний.
Рішення: якщо running=no, виправте створення інтерфейсу, наявність ключа або версію RouterOS перед тим, як чіпати брандмауер/маршрути.

Завдання 2: Підтвердити, що peer показує недавній хендшейк

cr0x@server:~$ ssh admin@office-a 'interface/wireguard/peers/print detail where comment~"OfficeB"'
 0 interface=wg-s2s-officeB public-key="OFFICE_B_PUBLIC_KEY" allowed-address=10.99.0.2/32,10.20.20.0/24
   last-handshake=1m12s rx=183204 tx=201889 endpoint-address=198.51.100.55 endpoint-port=51820

Значення виводу: last-handshake свіжий і лічильники rx/tx зростають.
Рішення: якщо хендшейк порожній/старий — перевірте досяжність UDP і налаштування endpoint перед дебагом маршрутів.

Завдання 3: Перевірити наявність IP‑адрес тунелю

cr0x@server:~$ ssh admin@office-a 'ip/address/print where interface="wg-s2s-officeB"'
 0   address=10.99.0.1/30 network=10.99.0.0 interface=wg-s2s-officeB

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

Завдання 4: Перевірити, що статичний маршрут існує і активний

cr0x@server:~$ ssh admin@office-a 'ip/route/print detail where dst-address=10.20.20.0/24'
 0 dst-address=10.20.20.0/24 gateway=wg-s2s-officeB distance=1 scope=30 target-scope=10 active=yes

Значення виводу: active=yes означає, що маршрутизатор вважає маршрут придатним.
Рішення: якщо неактивний — можливо інтерфейс down, неправильний gateway або конфлікт маршруту (більш специфічний маршрут десь ще).

Завдання 5: Запінгувати віддалену IP тунелю з маршрутизатора

cr0x@server:~$ ssh admin@office-a 'ping 10.99.0.2 count=5'
  SEQ HOST                                     SIZE TTL TIME       STATUS
    0 10.99.0.2                                   56  64 23ms       ok
    1 10.99.0.2                                   56  64 22ms       ok
    2 10.99.0.2                                   56  64 22ms       ok
    3 10.99.0.2                                   56  64 23ms       ok
    4 10.99.0.2                                   56  64 22ms       ok

Значення виводу: зв’язок по IP тунелю добрий.
Рішення: якщо це не вдається, але хендшейк є — дивіться на входні правила брандмауера на віддаленій стороні і помилки в allowed‑address.

Завдання 6: Запінгувати віддалений LAN‑хост з локального LAN‑хоста (end‑to‑end)

cr0x@server:~$ ping -c 4 10.20.20.50
PING 10.20.20.50 (10.20.20.50) 56(84) bytes of data.
64 bytes from 10.20.20.50: icmp_seq=1 ttl=62 time=25.1 ms
64 bytes from 10.20.20.50: icmp_seq=2 ttl=62 time=24.6 ms
64 bytes from 10.20.20.50: icmp_seq=3 ttl=62 time=24.9 ms
64 bytes from 10.20.20.50: icmp_seq=4 ttl=62 time=24.7 ms

--- 10.20.20.50 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms

Значення виводу: фактичний шлях бізнес‑трафіку працює.
Рішення: якщо маршрутизатор↔маршрутизатор працює, а host↔host ні — швидше за все відсутні правила forward на LAN, неправильно встановлений gateway на хостах або асиметрична маршрутизація.

Завдання 7: Трасування шляху, щоб підтвердити, що маршрутизація дійсно використовується

cr0x@server:~$ traceroute -n 10.20.20.50
traceroute to 10.20.20.50 (10.20.20.50), 30 hops max, 60 byte packets
 1  10.10.10.1  0.395 ms  0.324 ms  0.311 ms
 2  10.99.0.2   23.012 ms  22.911 ms  22.903 ms
 3  10.20.20.50 24.771 ms  24.701 ms  24.679 ms

Значення виводу: хоп 2 — віддалений тунельний ендпоінт; маршрутизація правильна.
Рішення: якщо хоп 2 показує ISP‑хоп, ваш трафік витікає в інтернет через помилку в маршрутах/NAT.

Завдання 8: Перевірити порядок правил обходу NAT

cr0x@server:~$ ssh admin@office-a 'ip/firewall/nat/print where chain="srcnat"'
 0 chain=srcnat action=accept src-address=10.10.10.0/24 dst-address=10.20.20.0/24 comment="S2S-WG: no-NAT OfficeA->OfficeB"
 1 chain=srcnat action=masquerade out-interface=ether1 comment="MASQ: internet"

Значення виводу: accept‑правило вище masquerade. Добре.
Рішення: якщо masquerade вище accept — виправте порядок. Це не предмет для торгів, якщо ви дбаєте про збереження IP джерела.

Завдання 9: Підтвердити, що лічильники брандмауера інкрементуються на потрібних правилах

cr0x@server:~$ ssh admin@office-a 'ip/firewall/filter/print stats where comment~"S2S-WG: allow"'
 0 chain=input action=accept packets=921 bytes=87244 comment="S2S-WG: allow WireGuard UDP from WAN"
 1 chain=input action=accept packets=110 bytes=9320 comment="S2S-WG: allow input from WireGuard (management/ping as needed)"
 2 chain=forward action=accept packets=12844 bytes=11833492 comment="S2S-WG: allow WG to LAN forwarding"
 3 chain=forward action=accept packets=12192 bytes=11011220 comment="S2S-WG: allow LAN to WG forwarding"

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

Завдання 10: Захопити пакети на інтерфейсі WireGuard (RouterOS sniffer)

cr0x@server:~$ ssh admin@office-a 'tool/sniffer/quick interface=wg-s2s-officeB ip-address=10.20.20.50'
  TIME   NUM  DIR  SRC-ADDRESS        DST-ADDRESS        PROTOCOL  SIZE
  1.234   12  <->  10.10.10.25        10.20.20.50        icmp      98
  1.456   13  <->  10.20.20.50        10.10.10.25        icmp      98

Значення виводу: пакети проходять інтерфейс WG в обидві сторони.
Рішення: якщо бачите тільки один напрямок — підозрюйте drop брандмауера на далекій стороні або проблеми з поверненням маршруту/дефолтним шлюзом на хості призначення.

Завдання 11: Перевірити конфлікти маршрутів (більш специфічні маршрути перемагають)

cr0x@server:~$ ssh admin@office-a 'ip/route/print where dst-address~"10.20.20."'
 0 dst-address=10.20.20.0/24 gateway=wg-s2s-officeB distance=1 active=yes
 1 dst-address=10.20.20.0/24 gateway=10.10.10.254 distance=1 active=no

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

Завдання 12: MTU‑тест з ping без фрагментації

cr0x@server:~$ ping -M do -s 1380 -c 3 10.20.20.50
PING 10.20.20.50 (10.20.20.50) 1380(1408) bytes of data.
1388 bytes from 10.20.20.50: icmp_seq=1 ttl=62 time=25.9 ms
1388 bytes from 10.20.20.50: icmp_seq=2 ttl=62 time=25.4 ms
1388 bytes from 10.20.20.50: icmp_seq=3 ttl=62 time=25.5 ms

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

Значення виводу: payload 1380 працює без фрагментації; це хороший знак для TCP‑продуктивності.
Рішення: якщо не вдається при помірних розмірах (1360–1380), реалізуйте MSS‑клампінг і/або знизьте MTU WG.

Завдання 13: Підтвердити доступність UDP‑порту WireGuard з інтернету (з тестової хости)

cr0x@server:~$ sudo nmap -sU -p 13231 203.0.113.10
Starting Nmap 7.94 ( https://nmap.org ) at 2025-12-28 10:40 UTC
Nmap scan report for 203.0.113.10
Host is up (0.021s latency).

PORT      STATE         SERVICE
13231/udp open|filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 1.23 seconds

Значення виводу: UDP часто показує open|filtered, бо немає TCP‑хендшейку.
Рішення: якщо показує closed, ймовірно ISP/edge блокує або неправильний проброс портів/брандмауер. Виправте досяжність перед тим, як чіпати піри.

Завдання 14: Спостерігати лічильники трансферу WireGuard під час тесту

cr0x@server:~$ ssh admin@office-b 'interface/wireguard/peers/print detail where comment~"OfficeA"'
 0 interface=wg-s2s-officeA public-key="OFFICE_A_PUBLIC_KEY" allowed-address=10.99.0.1/32,10.10.10.0/24
   last-handshake=14s rx=901233 tx=884120 endpoint-address=203.0.113.10 endpoint-port=13231

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

Швидкий план діагностики

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

Перш за все: чи peer взагалі живий?

1. Перевірте last-handshake на обох сторонах.
2. Перевірте лічильники rx/tx під час генерації трафіку.
3. Якщо хендшейк застарілий: валідируйте досяжність UDP (ISP, проброс портів, WAN‑брандмауер).

Вирішальний висновок: якщо хендшейк мертвий — вузьке місце це досяжність підкладки (WAN‑шлях, NAT, брандмауер).

Друге: чи маршрути вказують у тунель?

1. Перевірте, що статичні маршрути існують і активні.
2. З LAN‑хоста зробіть traceroute до віддаленої LAN‑IP.
3. На маршрутизаторі снифайте інтерфейс WG для цього потоку.

Вирішальний висновок: якщо хендшейк гарний, а traceroute показує ISP‑хопи — вузьке місце це маршрутизація/NAT‑політика.

Третє: чи брандмауер/NAT переписує або відкидає?

1. Перевірте порядок NAT: accept‑обхід має бути вище masquerade.
2. Перевірте лічильники брандмауера на allow‑правилах.
3. Тимчасово увімкніть таргетоване логування drop для двох LAN‑підмереж.

Вирішальний висновок: якщо пакети потрапляють у лог drop або лічильники masquerade несподівано зростають — вузьке місце це політика (фільтр/NAT).

Четверте: чи це дивні проблеми MTU/продуктивності?

1. Ping з DF і великими payload.
2. Тест одного TCP потоку (копіювання файлів або iperf якщо є).
3. Якщо переривчасті помилки додатків: клампіть MSS і повторно тестуйте.

Вирішальний висновок: якщо малі ping’и працюють, а більші — падають, вузьке місце це MTU‑чорна діра.

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

1) Хендшейк є, але ніхто не дістає до іншого сайту

Симптом: last-handshake свіжий, але ping/traceroute до віддаленої LAN не працює.

Корінь проблеми: відсутній статичний маршрут, неправильний allowed‑address або маскараде накладається на міжсайтовий трафік.

Виправлення: додайте/активуйте маршрут до віддаленої LAN через WG; переконайтеся, що allowed‑address пірів включає віддалену LAN; додайте правило обходу NAT accept вище masquerade.

2) Працює лише в одному напрямку (A→B працює, B→A ні)

Симптом: можна дістатися до B з A, але не навпаки.

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

Виправлення: підтвердіть дефолтні шлюзи на хостах призначення; перевірте allow‑правила forward в обох напрямках; снифайте інтерфейс WG, щоб побачити, чи існує повернення трафіку.

3) Деякі додатки працюють, інші зависають (особливо HTTPS, SMB, RDP)

Симптом: DNS розв’язується, малі ping’и працюють, але веб‑додатки таймаутять або SMB зависає.

Корінь проблеми: MTU/PMTUD чорна діра; upstream блокує повідомлення про фрагментацію.

Виправлення: знизьте MTU WireGuard (почніть з 1420 і коригуйте) і/або додайте MSS‑клампінг на форвард‑SYN пакети.

4) Тунель відпадає через кілька хвилин простою

Симптом: хендшейк стає старим; трафік відновлюється лише після «повторної спроби».

Корінь проблеми: закінчення відображення NAT на боці за NAT; відсутній keepalive.

Виправлення: встановіть persistent-keepalive=25s на NATed‑пірі; перевірте, що вихідний UDP дозволений.

5) Міжсайтовий трафік маскується і ACL ламаються

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

Корінь проблеми: загальне правило masquerade спрацьовує раніше за ваш обхід.

Виправлення: додайте srcnat action=accept для LAN‑LAN трафіку і розмістіть його вище masquerade; перевірте лічильники.

6) Можна пінгувати IP тунелю, але не віддалені LAN

Симптом: 10.99.0.1↔10.99.0.2 пінгуються, але 10.10.10.0/24↔10.20.20.0/24 не працює.

Корінь проблеми: allowed‑address включає лише /32 тунелю, а не LAN‑префікси; або правила forward не дозволяють LAN‑форвард.

Виправлення: включіть віддалені LAN‑підмережі в allowed‑address; додайте forward accept правила для LAN↔WG в обох напрямах.

7) Навантаження CPU і провал пропускної здатності під час передач

Симптом: великі копіювання файлів навантажують CPU маршрутизатора; затримки зростають; інтернет «ніби повільний».

Корінь проблеми: слабка модель маршрутизатора, неправильні черги/FastTrack, або надмірне логування брандмауера.

Виправлення: вимкніть дебаг‑логування; впевніться, що не логируєте кожен forwarded‑пакет; розгляньте апгрейд устаткування або цілеспрямоване формування трафіку (не наосліп).

Три корпоративні міні‑історії (як це йде не так)

Інцидент, спричинений хибним припущенням: «Хендшейк означає, що все гаразд»

Середня компанія з’єднала два офіси через WireGuard на MikroTik. Адмін зробив класичну перевірку:
хендшейк недавній, отже VPN в порядку. Вони оголосили успіх. Працівники почали мапити мережеві диски.

За годину почали приходити тікети: деякі ПК могли дістатися віддаленого файлового сервера, інші — ні. «Працюючі» ПК були в VLAN,
який випадково мав більш ліберальну політику брандмауера. Решта були у суворому VLAN, де правила forward не включали інтерфейс WireGuard.

Адмін продовжував тикати налаштування WireGuard. Нічого не змінювалося, бо тунель не був проблемою. Докази були очевидні:
лічильники пірів зростали під час ping’ів, але лічильники у forward chain не рухалися для реального трафіку користувачів.
Вони дебагили неправильний рівень, бо припустили, що хендшейк = end‑to‑end з’єднання.

Виправлення було банальним: додати явні forward‑правила для конкретних LAN‑підмереж в обидва напрями до/з WG і звузити їх по портах.
Після цього зв’язність стала консистентною, і команда безпеки перестала «пильнувати».

Оптимізація, що вилазить боком: «FastTrack для всього»

Інша організація мала проблему з продуктивністю: великі передачі між офісами були повільніші, ніж очікувалося. Хтось запропонував увімкнути FastTrack широко
щоб знизити навантаження CPU і підвищити throughput. Вони так і зробили у forward‑ланці з широким правилом для встановлених з’єднань.

День пройшов добре. CPU впав. Графіки заспокоїлися. Потім почалися дивні скарги:
деякі HTTPS‑сесії зависали, особливо додатки з довготривалими з’єднаннями. SMB‑копії стартували швидко, а потім деградували.
Helpdesk класифікував це як «переривчастий інтернет», що є корпоративною мовою для «ми не знаємо».

Корінь проблеми: FastTrack обходив частини pipeline брандмауера/mangle, на які вони покладалися для MSS‑клампінгу і обліку трафіку.
Деякі потоки проходили з клампінгом, інші — ні, залежно від стану з’єднання і порядку правил. Продуктивність стала недетермінованою.

Вони відкотили FastTrack для WireGuard‑пов’язаного трафіку і залишили його для простих інтернет‑NAT потоків.
Пропускна здатність стабілізувалась. Урок не в тому, що FastTrack поганий. Урок у тому, що треба знати, що саме ви обходите, і дисципліновано ставитися до винятків.

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

Третя команда мала охайну звичку: кожна зміна брандмауера/NAT для VPN мала префікс коментаря, і вони тримали короткий базовий знімок того, як «здорово» виглядає — часи хендшейку, статус маршрутів і лічильники правил під час стандартного тесту ping.

Одного ранку Офіс B втратив доступ до ERP сервера Офісу A. Тунель був піднятий. Маршрути на перший погляд виглядали правильно.
Замість хаотичних маніпуляцій, інженер на чергуванні порівняв лічильники з базовою лінією: правило обходу NAT більше не співпадало.

Виявилось, що рутинний «прибирання» минулої ночі перемістив порядок правил NAT. Правило masquerade опинилося вище обходу accept.
Для деякого трафіку все ще «працювало», але ERP‑сервери мали ACL, що очікували реальні IP клієнтів, і почали відмовляти сесії.

Через те, що команда мала коментарі і базові лінії, діагностика зайняла хвилини. Вони відновили порядок NAT, додали guard‑коментар на правилі masquerade
і ввели невелику політику peer‑review для змін у порядку правил. Це не було гламурно. Це також запобігло повторним відмовам того ж класу.

Жарт №2: Найнебезпечніший мережевий пристрій — той, що позначений «тимчасово», бо він переживе вашу організаційну структуру.

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

Покрокове підняття (два офіси)

1. Виберіть підмережі: підтвердіть, що LAN‑и не перекриваються (10.10.10.0/24 і 10.20.20.0/24) і оберіть тунель /30 (10.99.0.0/30).
2. Оновіть RouterOS: обидва маршрутизатори на v7+ з тим самим мажорним релізом, якщо можливо.
3. Згенеруйте ключі на кожному маршрутизаторі; обміняйтесь публічними ключами поза основним каналом.
4. Створіть WG‑інтерфейси з явними іменами і MTU 1420.
5. Призначте IP тунелю інтерфейсам WG.
6. Налаштуйте піри:
   • allowed‑address пірів Офісу A має включати тунель /32 і LAN Офісу B /24.
   • allowed‑address пірів Офісу B має включати тунель /32 і LAN Офісу A /24.
   • Офіс B встановлює endpoint на Офіс A і persistent keepalive, якщо за NAT.
7. Додайте статичні маршрути до віддаленої LAN через WG‑інтерфейс.
8. Додайте правила брандмауера:
   • Дозволити UDP‑порт на WAN Офісу A.
   • Дозволити forward LAN↔WG в обох напрямах.
9. Додайте обхід NAT accept‑правила перед masquerade.
10. Тестуйте по шарам:
    • Хендшейк
    • Ping IP тунелів
    • Ping віддаленої LAN IP з маршрутизатора
    • Ping віддаленого хоста з LAN хоста
    • MTU‑тест з DF ping
11. Вимкніть debug‑логування після валідації.
12. Запишіть відомий‑добрий стан: маршрути, лічильники, частота хендшейку і де налаштований keepalive.

Чекліст змін (кожного разу, коли щось чіпаєте)

• Чи вплине зміна на порядок правил в NAT або filter? Якщо так — перевірте, що обхід NAT все ще співпадає.
• Чи змінюємо визначення підмереж? Якщо так — оновіть allowed‑address і статичні маршрути на обох сторонах.
• Чи ввели ви перекриваючі підмережі через новий VLAN? Якщо так — зупиніться і переробіть дизайн до деплойменту.
• Чи включили FastTrack або нові mangle‑правила? Якщо так — повторно протестуйте MTU/MSS і виміряйте пропускну здатність.
• Чи змінили ISP або WAN‑адресацію? Якщо так — негайно перевірте endpoint і досяжність UDP.

Чекліст безпеки (мінімальна гігієна)

• Обмежте input до UDP‑порту 13231 на WAN (Офіс A) і тримайте інші input‑порти закритими.
• Схематизуйте forward‑правила по підмережах (і навіть по портах/сервісах, якщо можна).
• Тримайте ключі WireGuard поза тікетами та чатами.
• Логуйте тільки те, що потрібно, і тільки коли потрібно. Постійне «логувати все» — самонанесений DoS.

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

1) Чи мостити два офіси, щоб це було «одна LAN»?

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

2) Чому ми додаємо віддалені LAN‑підмережі в allowed-address?

В WireGuard allowed‑address діє як політика маршрутизації/селектор: які префікси вважаються допустимими для цього пірa.
Якщо ви опустите LAN‑підмережу, ви отримаєте хендшейк і, можливо, тунельні ping’и, але не справжню міжсайтову маршрутизацію.

3) Чи потрібен persistent-keepalive на обох сторонах?

Здебільшого лише на стороні за NAT (або за агресивними stateful брандмауерами). Якщо обидві сторони мають публічні IP і стабільний UDP,
зазвичай можна його опустити. У сумнівах — встановіть лише на NATed‑стороні 25 секунд.

4) Який порт використовувати для WireGuard?

Будь‑який UDP‑порт, який ви надійно можете дозволити на WAN‑краю. Виберіть один, задокументуйте його і не використовуйте випадкові порти для різних VPN.
Операційна ясність цінніша за хитрий «прихований» порт.

5) Чи можна запускати кілька site‑to‑site тунелів на одному маршрутизаторі?

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

6) Хендшейк свіжий, але rx зростає, а tx — ні (або навпаки). Що це значить?

Маєте односторонній трафік. Або зламана шлях повернення (маршрут/дефолтний шлюз), або брандмауер відкидає один напрямок.
Снифайте інтерфейс WG і перевірте лічильники forward правил, щоб побачити, де пакети зникають.

7) Як уникнути перекривань підмереж, коли бізнес купує ще один офіс?

Плануйте: ведіть внутрішній IPAM та резервуйте діапазони для кожного сайту. Якщо успадкуєте перекриття, доведеться перенумерувати одну сторону
або впровадити NAT між сайтами (операційний борг). Перенумерація болить один раз; NAT болить довічно.

8) Чи NAT‑ити трафік між сайтами, щоб зробити «простішим»?

Уникайте цього. NAT ховає IP джерела, ламає очікування ACL і ускладнює відлагодження.
Використовуйте міжсайтовий NAT лише тимчасово для сумісності (наприклад, перекриття підмереж, яке не можна терміново переробити), і заплануйте його видалення.

9) Чи потрібний спеціальний QoS для WireGuard site‑to‑site?

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

10) Який найкращий «health check»?

Свіжий хендшейк плюс стійке зростання лічильників передач під час запланованого синтетичного тесту (наприклад, ping плюс невеликий TCP‑зонд).
Сам по собі хендшейк недостатній; лічильники можуть бути застарілими. Потрібні обидва, простежені в часі.

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

Якщо ви зробите лише три речі після прочитання цього, зробіть ці:

1. Закріпіть чистий план IP (відокремлені LAN‑и, окремий тунель /30) і запишіть його в місці, де він не загубиться.
2. Правильно реалізуйте обхід NAT (accept‑правила вище masquerade) і перевірте через лічильники, а не надію.
3. Прийміть порядок швидкої діагностики: хендшейк → маршрутизація → брандмауер/NAT → MTU. Це не дасть вам дебагити неправильний рівень.

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