← Inne projekty

MikroTik ZTP

Router wchodzi do sieci sam. Docelowo dziewięćset pięćdziesiąt obiektów.

Problem

Każdy obiekt monitoringu to router, rejestrator i kamery, spięte tunelem do centrali. Przy takiej skali ręczna konfiguracja jednego po drugim jest niewykonalna, a błąd oznacza wyjazd serwisu.

Rozwiązanie

Serwer, który przyjmuje zgłoszenie nowego routera, sprawdza je, generuje plik konfiguracyjny i zakłada połączenie po stronie centrali przez API. Jedno źródło prawdy to plik CSV z klientami. Adresacja idzie od końca puli w dół, więc poszerzenie zakresu to jedna komenda, a nie dotykanie dziewięciuset pięćdziesięciu urządzeń.

Co robi

  • Router zgłasza się sam, serwer waliduje i generuje jego konfigurację
  • Peer i trasa zakładane w centrali przez API, bez logowania się na sprzęt
  • Jedno źródło prawdy: plik CSV z klientami
  • Adresacja od końca puli w dół, poszerzenie zakresu to jedna komenda
  • Izolacja klientów jedną regułą na interfejsie zamiast list adresowych
  • Autoryzacja tokenem i pinowanie klucza publicznego
  • Panel z mapą obiektów, serwer syslog, alarmy, zrzuty i kopie — stan całej sieci bez otwierania terminala na każdym routerze

Na czym zbudowane

  • Serwer ZTP w Pythonie na Debianie 13 pod systemd, HTTPS z własnym certyfikatem
  • Konfiguracja routerów generowana jako pliki .rsc z jednego pliku CSV
  • Peer i trasa zakładane w centrali przez REST API RouterOS 7
  • WireGuard jako transport, adresacja od końca puli w dół
  • Panel webowy z mapą obiektów na Leaflecie, serwer syslog, alarmy i kopie
  • Proxmox po stronie centrali, osobny moduł pve.py
  • Testy: 44 asercje działające bez sprzętu plus runbook z jedenastoma testami akceptacyjnymi

Co to zmieniło

  • Konfiguracja routera po routerze odpada: router zgłasza się sam, a serwer generuje mu plik z jednego CSV
  • Poszerzenie puli adresów to jedna komenda zamiast dotknięcia 950 urządzeń — a każde dotknięcie ręczne to ryzyko wyjazdu serwisu, najdroższej pozycji w całym procesie
  • Zły wpis nie wychodzi dopiero w polu: walidacja idzie przed generowaniem konfiguracji
  • Pierwsze uruchomienie na fizycznym sprzęcie: dziewięć testów, tunel 3/3, izolacja klientów 0/3 w obie strony
  • Przepustowość przez tunel 20,7 Mbit/s wobec 22,1 surowo — narzut 5,5%; procesor centrali w 6% przy 42 Mbit/s zagregowanych
  • 44 asercje testów jednostkowych działających bez sprzętu
  • Liczby pochodzą z pierwszego uruchomienia na sprzęcie, nie z produkcji na 950 obiektach — tej jeszcze nie ma

Stack

  • Python
  • RouterOS 7 REST API
  • WireGuard
  • Debian 13
  • systemd
  • Leaflet

Historia

Protokół BGP odrzucono świadomie: gryzie się z listą dozwolonych adresów w WireGuardzie. Zastąpił go generator tras statycznych z jednego pliku. Izolacja klientów, która wcześniej nie działała przy siedmiuset obiektach, zeszła do jednej reguły na interfejsie zamiast list adresowych. Zasada nadrzędna projektu brzmi: nie odcinaj dostępu do żadnego urządzenia, bo router bez dostępu znaczy wyjazd serwisu.