Маршрутизація та масштабування UMTC Mesh

Огляд архітектури

UMTC Mesh використовує ієрархічну топологію з VPS як центральним хабом та MikroTik роутерами як тактичними нодами. Система забезпечує автоматичний failover між різними каналами зв'язку.

                        ┌─────────────────┐
                        │   VPS (Hub)     │
                        │   10.10.10.1    │
                        │   WireGuard     │
                        └────────┬────────┘
                                 │
              ┌──────────────────┼──────────────────┐
              │                  │                  │
      ┌───────▼───────┐  ┌───────▼───────┐  ┌───────▼───────┐
      │  NeoForge     │  │   Node-B      │  │   Node-C      │
      │  10.10.10.2   │  │  10.10.12.1   │  │  10.10.13.1   │
      │  Primary      │  │  Secondary    │  │  Tactical     │
      └───────┬───────┘  └───────┬───────┘  └───────────────┘
              │                  │
              └────── Interval ──┘
                     (5GHz P2P)

Рівні мережі

Рівень 1: WireGuard Overlay (10.10.0.0/16)

Основна мережа для всіх сервісів. Кожна нода має унікальну /24 підмережу:

Підмережа Призначення
10.10.10.0/24 VPS та primary роутери
10.10.11.0/24 Клієнти та мобільні пристрої
10.10.12.0/24 Node-B та його клієнти
10.10.13.0/24 Node-C та його клієнти

Прямі P2P з'єднання між роутерами для backup та low-latency комунікації:

IP Роутер
192.168.55.55 Node-B
192.168.55.56 NeoForge
192.168.55.57 Node-C (planned)

Рівень 3: Local Networks

Кожен роутер має локальні мережі для клієнтів:
- 192.168.88.0/24 — LAN
- 192.168.99.0/24 — Guest/IoT

Failover Routing

Принцип роботи

MikroTik використовує check-gateway=ping для моніторингу доступності шлюзів. При недоступності основного маршруту, активується резервний з вищою distance.

Конфігурація NeoForge (Primary Router)

# Primary: Starlink
/ip route add dst-address=0.0.0.0/0 gateway=192.168.0.1 distance=1 \
    check-gateway=ping comment="primary-starlink"

# Secondary: iOS Hotspot
/ip route add dst-address=0.0.0.0/0 gateway=172.20.10.1 distance=2 \
    check-gateway=ping comment="secondary-hotspot"

# Backup: Interval (через Node-B з LTE)
/ip route add dst-address=0.0.0.0/0 gateway=192.168.55.55 distance=3 \
    comment="backup-via-B"

# WireGuard routes
/ip route add dst-address=10.10.0.0/16 gateway=wg-to-vps distance=1
/ip route add dst-address=10.10.12.0/24 gateway=192.168.55.55 distance=1

Конфігурація Node-B (Secondary Router)

# Primary: LTE
/ip route add dst-address=0.0.0.0/0 gateway=10.33.218.14 distance=1 \
    check-gateway=ping comment="primary-lte"

# Secondary: WireGuard (direct to VPS)
/ip route add dst-address=0.0.0.0/0 gateway=10.10.11.1 distance=2 \
    comment="secondary-wg"

# Backup: Interval (через NeoForge)
/ip route add dst-address=0.0.0.0/0 gateway=192.168.55.56 distance=3 \
    comment="backup-interval"

# WireGuard routes
/ip route add dst-address=10.10.0.0/16 gateway=wg-to-vps distance=1
/ip route add dst-address=10.10.0.0/16 gateway=192.168.55.56 distance=2

VPS WireGuard Configuration

Структура peers

VPS виступає центральним хабом. Кожен peer має визначені allowed-ips:

# /etc/wireguard/wg0.conf

[Interface]
PrivateKey = <VPS_PRIVATE_KEY>
Address = 10.10.10.1/24
ListenPort = 51820

# NeoForge - Primary router + routes to Node-B via interval
[Peer]
PublicKey = <NEOFORGE_PUBLIC_KEY>
AllowedIPs = 10.10.10.2/32, 192.168.88.0/24, 10.10.12.0/24
PersistentKeepalive = 15

# Node-B - Direct connection when LTE available
[Peer]
PublicKey = <NODE_B_PUBLIC_KEY>
AllowedIPs = 10.10.11.0/24, 10.10.12.0/24
PersistentKeepalive = 25

# Mobile clients
[Peer]
PublicKey = <CLIENT_KEY>
AllowedIPs = 10.10.10.69/32
PersistentKeepalive = 25

Важливо: AllowedIPs для failover

Коли Node-B недоступний напряму (LTE down), трафік до 10.10.12.0/24 має йти через NeoForge. Для цього 10.10.12.0/24 додано до AllowedIPs обох peers:

  • NeoForge peer: для routing через interval
  • Node-B peer: для direct routing коли LTE up

WireGuard автоматично обирає peer з найновішим handshake.

Фізичний рівень

Interval link використовує 5GHz WiFi у режимі station-bridge:

NeoForge (AP):

/interface wifi
add name=wifi5 configuration.mode=ap configuration.ssid=UMTC-Interval \
    configuration.channel.band=5ghz-ax configuration.channel.width=80mhz \
    security.authentication-types=wpa2-psk,wpa3-psk

/ip address add address=192.168.55.56/24 interface=wifi5

Node-B (Station):

/interface wifi
add name=wifi2 configuration.mode=station-bridge \
    configuration.ssid=UMTC-Interval \
    security.authentication-types=wpa2-psk,wpa3-psk

/ip address add address=192.168.55.55/24 interface=wifi2

Маршрутизація через interval

Для доступу до Node-B через interval, NeoForge потребує маршрут:

/ip route add dst-address=10.10.12.0/24 gateway=192.168.55.55 distance=1

NAT та Masquerade

Проблема

При routing через interval, NeoForge робить masquerade. Node-B бачить source IP як 192.168.55.56, а не оригінальний 10.10.10.x.

Рішення для API access

# На Node-B дозволити API з interval мережі
/ip service set api address=10.10.0.0/16,192.168.55.0/24

Firewall правило для mesh-api

/ip firewall filter add chain=input action=accept protocol=tcp \
    src-address=10.10.0.0/16 dst-port=8728 comment="mesh-api"
/ip firewall filter add chain=input action=accept protocol=tcp \
    src-address=192.168.55.0/24 dst-port=8728 comment="interval-api"

Масштабування

Додавання нової ноди

  1. Виділити підмережу (наприклад, 10.10.14.0/24)

  2. Згенерувати WireGuard ключі:

wg genkey | tee privatekey | wg pubkey > publickey
  1. Додати peer на VPS:
wg set wg0 peer <NEW_PUBLIC_KEY> allowed-ips 10.10.14.0/24
wg-quick save wg0
  1. Налаштувати роутер:
/interface wireguard add name=wg-to-vps listen-port=51820 private-key="<PRIVATE>"
/interface wireguard peers add interface=wg-to-vps \
    public-key="<VPS_PUBLIC_KEY>" \
    endpoint-address=203.0.113.1 endpoint-port=51820 \
    allowed-address=10.10.0.0/16 \
    persistent-keepalive=25
/ip address add address=10.10.14.1/24 interface=wg-to-vps
/ip route add dst-address=10.10.0.0/16 gateway=wg-to-vps
  1. Додати в MMM:
    - Відкрити mikro.example.com
    - "+ Add" → ввести IP, credentials
    - Роутер з'явиться в dashboard
  1. Налаштувати WiFi bridge між роутерами
  2. Присвоїти IP з 192.168.55.0/24
  3. Додати маршрути:

На hub роутері:

/ip route add dst-address=10.10.14.0/24 gateway=192.168.55.x distance=1

На VPS (якщо потрібен failover):

wg set wg0 peer <HUB_KEY> allowed-ips <existing>,10.10.14.0/24

Діагностика

Перевірка WireGuard

# На VPS
wg show

# Має показати recent handshake для активних peers

# На роутері
/interface wireguard peers print
# latest-handshake має бути < 2 хвилин

Перевірка routing

# Активні маршрути
/ip route print where active

# Трасування
/tool traceroute 10.10.10.1

Перевірка failover

# Статус gateway check
/ip route print detail where check-gateway=ping

# GW Status: reachable / unreachable

MMM Diagnostics

Відкрити "Diag" на картці роутера:
- Default Routes — показує active/inactive
- Gateway Ping — RTT до кожного gateway
- Issues — проблеми з DHCP, routing

Типові проблеми

1. Node недоступна через WG

Симптом: Ping до 10.10.x.1 timeout

Перевірити:
- wg show на VPS — handshake age
- Endpoint address peer'а — чи правильний public IP
- Firewall на роутері — UDP 51820

2. API connection failed

Симптом: MMM показує "API connection failed"

Перевірити:
- /ip service print — api enabled, address restrictions
- Firewall input chain — правило для 8728
- Source IP запитів (може бути masquerade)

Симптом: Ping між роутерами через interval timeout

Перевірити:
- WiFi інтерфейси running
- IP адреси на interval інтерфейсах
- ARP таблиця: /ip arp print where interface=wifi5

4. Failover не спрацьовує

Симптом: При падінні primary, трафік не переключається

Перевірити:
- check-gateway=ping на маршрутах
- Distance значення (менше = пріоритетніше)
- Gateway reachability в route table

Best Practices

  1. Використовуйте коментарі для маршрутів — легше дебажити
  2. Різні distance для чіткої пріоритизації
  3. check-gateway=ping тільки на default routes
  4. Регулярні бекапи конфігурації через MMM
  5. Моніторинг через Matrix alerts
  6. Документуйте IP схему та topology

Приклад повної конфігурації

Tactical Node Template

# Identity
/system identity set name="UMTC-Node-X"

# WireGuard
/interface wireguard add name=wg-to-vps listen-port=51820 private-key="XXX"
/interface wireguard peers add interface=wg-to-vps \
    public-key="<VPS_PUBLIC_KEY>" \
    endpoint-address=203.0.113.1 endpoint-port=51820 \
    allowed-address=10.10.0.0/16 persistent-keepalive=25

# IP Addressing
/ip address add address=10.10.X.1/24 interface=wg-to-vps
/ip address add address=192.168.88.1/24 interface=bridge1

# Routing
/ip route add dst-address=0.0.0.0/0 gateway=<PRIMARY_GW> distance=1 check-gateway=ping
/ip route add dst-address=0.0.0.0/0 gateway=<BACKUP_GW> distance=2
/ip route add dst-address=10.10.0.0/16 gateway=wg-to-vps distance=1

# Firewall - API access
/ip firewall filter add chain=input action=accept protocol=tcp \
    src-address=10.10.0.0/16 dst-port=8728 comment="mesh-api"

# Services
/ip service set api address=10.10.0.0/16
/ip service set winbox address=10.10.0.0/16,192.168.88.0/24
/ip service disable telnet,ftp,www

# DNS
/ip dns set servers=1.1.1.1,8.8.8.8 allow-remote-requests=yes

# NTP
/system ntp client set enabled=yes
/system ntp client servers add address=time.cloudflare.com

Останнє оновлення: 2 січня 2026

Шлях: networking/routing/umtc-routing-guide.md

UMTC Wiki © 2026 | Ukrainian Military Tactical Communications