NetGuard: buduję własny watchdog sieci do automatycznego restartu routera, AP i serwera

Co zrobić, kiedy router, punkt dostępowy, switch, serwer Home Assistant albo urządzenie PoE zawiesi się wtedy, gdy nikogo nie ma w domu? Można czekać na powrót i ręcznie odłączyć zasilanie. Można też zbudować urządzenie, którego jedynym zadaniem będzie zauważyć problem, upewnić się, że to rzeczywiście awaria i w kontrolowany sposób spróbować przywrócić usługę do życia. Tak powstaje MarkLabs NetGuard.

Problem zaczął się od bardzo prostego pytania

W domu mam coraz więcej urządzeń, których działanie przestało być tylko wygodnym dodatkiem. Router zapewnia dostęp do sieci. Punkty dostępowe obsługują Wi-Fi. Zarządzalny switch łączy kolejne fragmenty infrastruktury. Osobny serwer uruchamia Home Assistant i inne usługi. Dochodzą do tego kamery IP, switche PoE, rejestratory i urządzenia, które zwykle mają działać przez całą dobę bez jakiejkolwiek ingerencji.

Dopóki wszystko działa, o tej warstwie domu praktycznie się nie myśli. Problem zaczyna się wtedy, gdy jedno urządzenie nie tyle całkowicie się wyłączy, co zwyczajnie się zawiesi. Zasilanie jest. Diody świecą. Być może część interfejsu nawet odpowiada. Usługa, której faktycznie potrzebujemy, przestaje jednak działać.

Klasyczne rozwiązanie jest banalne: wyciągnąć wtyczkę, odczekać kilka sekund i ponownie podłączyć zasilanie.

Tyle że to rozwiązanie działa dobrze tylko wtedy, kiedy jestem w domu.

Na pierwszy rzut oka brzmi to jak zadanie dla inteligentnego gniazdka. W praktyce bardzo szybko pojawiło się jednak więcej pytań.

Co jeśli nie działa właśnie Wi-Fi, przez które sterowane jest gniazdko? Co jeśli nie odpowiada Home Assistant? Co jeśli po restarcie urządzenie potrzebuje dwóch minut na pełne uruchomienie, a watchdog uzna ten czas za kolejną awarię? Co jeśli awaria operatora spowoduje, że router będzie bez końca restartowany mimo tego, że sam działa prawidłowo? Co jeśli moduł wykonawczy przyjmie dwa razy tę samą komendę i zamiast jednego resetu wykona dwa?

W tym momencie projekt przestaje być prostym „pingiem sterującym przekaźnikiem”.

Watchdog infrastruktury nie może zależeć od Wi-Fi

To jedna z najważniejszych decyzji całego projektu i właśnie dlatego jako Mastera wybrałem płytkę WT32-ETH01.

WT32-ETH01 łączy ESP32 z fizycznym interfejsem Ethernet. To dla NetGuarda znacznie ważniejsze niż możliwość zbudowania projektu na dowolnym ESP32 z Wi-Fi.

Gdybym zbudował watchdog infrastruktury na urządzeniu komunikującym się wyłącznie przez Wi-Fi, stworzyłbym dość paradoksalny system. Urządzenie odpowiedzialne za diagnozowanie awarii sieci samo zależałoby od warstwy sieciowej, której działanie ma kontrolować.

Wyobraźmy sobie najprostszy przypadek. Punkt dostępowy zawiesza się i przestaje obsługiwać klientów. Watchdog podłączony do tego samego Wi-Fi również traci komunikację. Z punktu widzenia innych systemów przestają działać jednocześnie AP i urządzenie, które miało ten AP naprawić.

Podobny problem może wystąpić przy zmianie konfiguracji sieci bezprzewodowej, zakłóceniach radiowych, utracie zasięgu, awarii części radiowej routera albo problemie z uwierzytelnieniem klienta.

Dlatego w NetGuardzie nie chcę zastanawiać się, czy niedostępność obserwowanego hosta wynika z jego awarii, czy może po prostu sam watchdog właśnie stracił Wi-Fi.

Oczywiście Ethernet nie sprawia magicznie, że sieć staje się niezniszczalna. Jeżeli restartuję router, port Ethernet Mastera również przez chwilę straci link. Różnica polega na tym, że sam NetGuard pozostaje uruchomiony, jego logika nadal istnieje, a po powrocie routera może obserwować przywrócenie linku i ponownie rozpocząć diagnostykę.

Taki sposób myślenia jest zresztą bardzo bliski temu, jak podchodzę do infrastruktury również w moim kursie Home Assistant po polsku: najpierw stabilna sieć, zasilanie i możliwość poradzenia sobie z awarią, dopiero później wygodne automatyzacje.

Dwa urządzenia zamiast jednego

Drugą kluczową decyzją było rozdzielenie projektu na dwie niezależne funkcjonalnie części:

Nie chciałem, żeby układ sterujący 230 V jednocześnie wykonywał zapytania HTTP, analizował reguły, obsługiwał interfejs WWW, Home Assistant i całą diagnostykę. Moduł wykonawczy powinien mieć możliwie jasno określoną rolę: dostać prawidłowe polecenie, bezpiecznie wykonać przełączenie i przekazać informację zwrotną.

To również daje interesującą właściwość awaryjną. Jeśli Master zleci czasowe wyłączenie kanału, Power Module sam pilnuje czasu i ponownie włączy kanał po jego zakończeniu. Zerwanie komunikacji w trakcie takiej operacji nie powinno pozostawić urządzenia trwale bez zasilania.

Szczegółowo pokażę tę część w drugim artykule serii, w którym przerabiam SONOFF 4CHR3 na NetGuard Power Module.

Jak oba moduły będą ze sobą rozmawiały?

Master i Power Module komunikują się przewodowo przez UART. Nie chciałem dodawać pomiędzy nimi kolejnego Wi-Fi, brokera, API w sieci LAN ani usługi, która musiałaby działać, żeby urządzenie mogło odciąć zasilanie.

Samo połączenie logiczne pomiędzy płytkami nie będzie jednak wykonane „na krótko”. Do separacji obu stron wykorzystuję moduł z izolatorem cyfrowym ADuM1201.

Jest to szczególnie istotne dlatego, że Power Module powstaje na bazie urządzenia pracującego po stronie zasilania sieciowego. Nie chcę traktować galwanicznego rozdzielenia obu części jako dodatku, który można dołożyć później. Jest elementem architektury od początku projektu.

Cztery kanały, ale urządzenie i cel diagnostyczny to nie to samo

To rozróżnienie okazało się bardzo ważne podczas projektowania logiki.

NetGuard będzie miał cztery fizyczne kanały zasilania. W mojej docelowej instalacji planuję wykorzystać je przede wszystkim do urządzeń infrastruktury:

• router,
• punkt dostępowy Wi-Fi,
• switch zarządzalny,
• serwer z Home Assistant.

To jednak nie oznacza, że NetGuard będzie potrafił obserwować tylko cztery adresy.

Fizyczne urządzenie zasilane oraz cel diagnostyczny to dwa różne pojęcia. Jeden kanał może zasilać przykładowo switch PoE, a NetGuard może równocześnie obserwować konkretną kamerę podłączoną do tego switcha.

Jeżeli kamera przestanie odpowiadać, reguła może zdecydować, że sposobem naprawczym będzie restart zasilania całego switcha PoE.

To jeden z powodów, dla których projekt może być ciekawy również poza samym Home Assistant. Podobny mechanizm można wykorzystać dla kamer, rejestratorów, modemów, mostów sieciowych, sterowników czy innych urządzeń, które po zawieszeniu najczęściej odzyskują sprawność po pełnym odcięciu zasilania.

Temat przewodowego monitoringu PoE rozwijam również w osobnym LAB-ie MarkLabs poświęconym kamerom, NVR, Frigate i Home Assistant. NetGuard może stać się dla takiego systemu dodatkową warstwą odzyskiwania po awarii.

Sam PING to za mało

Pierwsza wersja watchdoga, jaka przychodzi do głowy, wygląda bardzo prosto:

Nie chcę jednak oddawać kontroli nad zasilaniem ważnych urządzeń tak prostemu warunkowi.

Pojedynczy pakiet ICMP może zaginąć. Host może przez chwilę odpowiadać wolniej. Urządzenie może być aktualizowane. Sieć może właśnie odzyskiwać połączenie. Router może działać prawidłowo, podczas gdy problem znajduje się po stronie operatora.

Dlatego Master jest projektowany jako właściwy silnik diagnostyczny. Oprócz PING może sprawdzać także dostępność połączenia TCP, odpowiedź HTTP lub HTTPS oraz rozwiązywanie nazw DNS.

Co więcej, cele diagnostyczne można łączyć w reguły.

Przykład dla punktu dostępowego może wyglądać tak:

Dzięki temu brak odpowiedzi AP nie jest automatycznie interpretowany jako powód do restartu, jeżeli równocześnie zniknęła cała sieć.

To dopiero początek. Reguła może wymagać kilku kolejnych zgodnych cykli, zanim w ogóle wystąpi o reset urządzenia.

Szczegóły całego silnika diagnostycznego, dostępnych typów testów i sposobu budowania reguł pokażę w części 3: NetGuard Master na WT32-ETH01.

Restart ma być ostatecznością, a nie pierwszą reakcją

Im dłużej pracowałem nad projektem, tym bardziej przesuwał się jego główny problem. Samo sterowanie przekaźnikiem jest łatwe. Znacznie trudniejsze jest ustalenie, kiedy wolno go przełączyć.

Dlatego NetGuard ma kilka warstw zabezpieczających przed bezsensownym resetowaniem infrastruktury.

Po uruchomieniu Master nie powinien natychmiast reagować na wszystkie nieosiągalne hosty. Cała sieć może jeszcze startować. Switch może zestawiać porty. Serwer może uruchamiać system i usługi. Router może dopiero pobierać konfigurację WAN.

Potrzebny jest więc czas ochronny po starcie.

Po restarcie konkretnego urządzenia również nie można od razu zacząć traktować braku odpowiedzi jako nowej awarii. Router, AP czy serwer potrzebują czasu na ponowne uruchomienie. To osobny okres stabilizacji.

Do tego dochodzi minimalny odstęp do kolejnej próby oraz limit liczby restartów. Jeżeli urządzenie po kilku kontrolowanych próbach nadal nie działa, ciągłe odcinanie zasilania co minutę raczej nie rozwiąże problemu, za to może go pogłębić.

Power Module też musi być obserwowany

Jeśli Master ma podejmować decyzję o odłączeniu 230 V, musi wiedzieć, czy moduł wykonawczy w ogóle jest gotowy do pracy.

Sama obecność przewodów RX i TX nie wystarcza. NetGuard Power okresowo wysyła heartbeat zawierający między innymi informację o swojej bieżącej sesji oraz stanie czterech kanałów. Master może na tej podstawie ocenić, czy komunikacja jest aktywna, a zmiana identyfikatora sesji pozwala zauważyć restart samego modułu Power.

Nie chcę więc sytuacji, w której interfejs pokaże „wysłano reset”, mimo że urządzenie wykonawcze od dawna nie odpowiada.

Docelowo operacja ma być traktowana jako wykonana dopiero wtedy, gdy komunikacja pomiędzy modułami przebiegnie w sposób zgodny z protokołem.

Dlaczego Power Module nie korzysta z własnego Wi-Fi?

SONOFF 4CHR3 fabrycznie jest urządzeniem sieciowym, więc można zadać rozsądne pytanie: skoro ma własny ESP8285 i Wi-Fi, po co w ogóle łączyć go przewodem z Masterem?

Odpowiedź jest właściwie taka sama jak przy wyborze Ethernetu dla WT32-ETH01.

NetGuard ma działać również wtedy, gdy Wi-Fi nie działa.

W moim firmware dla NetGuard Power warstwa Wi-Fi i usługi chmurowe nie są potrzebne. Moduł ma jedno konkretne zadanie: realizować polecenia otrzymywane przewodowo z Mastera i pilnować czterech kanałów.

Mniej zależności oznacza tutaj mniej elementów, które mogą zawieść dokładnie w chwili, kiedy system jest najbardziej potrzebny.

Home Assistant będzie dodatkiem, nie warunkiem działania

Ponieważ w mojej sieci Home Assistant jest jednym z urządzeń, które NetGuard ma chronić, architektura nie może wyglądać tak:

To oczywiście nie ma sensu.

Home Assistant będzie więc tylko dodatkową warstwą nad NetGuardem.

Master ma podejmować decyzje lokalnie i działać bez HA. Integracja przez MQTT pozwoli natomiast przenieść do Home Assistanta informacje o stanie urządzenia, celach diagnostycznych, regułach, wykonanych resetach i dostępności Power Module.

Z Home Assistanta będzie można również wywołać wybrane operacje ręczne, ale nie chcę, aby HA bezpośrednio przełączał GPIO w SONOFF-ie. Polecenie nadal przechodzi przez logikę Mastera.

Integrację z MQTT i Home Assistant pokażę od podstaw w części 4 serii NetGuard.

Jak będzie wyglądał fizyczny NetGuard?

Projekt nie kończy się na dwóch płytkach leżących obok laptopa.

WT32-ETH01 dostanie własną obudowę z druku 3D. Master będzie zasilany oddzielnym zasilaczem i podłączony przewodowo do routera.

SONOFF 4CHR3 również będzie elementem fizycznej części wykonawczej. Na wyjściu rozważam dwa praktyczne warianty: cztery oddzielne gniazda 230 V albo odpowiednio przerobioną listwę zasilającą. W obu przypadkach zależy mi na tym, żeby finalny zestaw wyglądał jak normalne urządzenie infrastruktury, a nie prototyp laboratoryjny z odsłoniętymi przewodami.

Ważne jest też fizyczne rozdzielenie odpowiedzialności. Master musi pozostać aktywny niezależnie od tego, który kanał właśnie restartuje. Z tego powodu jego zasilacz nie może zostać przypadkiem podłączony do jednego z wyjść NetGuard Power.

To nie będzie projekt opisywany dopiero po fakcie

Tę serię chcę poprowadzić trochę inaczej niż typowy artykuł „zbuduj gotowe urządzenie według schematu”.

NetGuard faktycznie powstaje teraz.

Mam już działające elementy firmware, komunikację pomiędzy modułami i pierwsze testy na fizycznym SONOFF 4CHR3. Równocześnie część testów sprzętowych nadal jest przede mną. Zanim urządzenie trafi do docelowej instalacji, chcę sprawdzić między innymi wszystkie cztery kanały, zachowanie podczas restartów, stabilność długoterminową i scenariusze utraty komunikacji.

Jeżeli w trakcie tych testów pojawi się problem, w kolejnych częściach nie zamierzam go pomijać. Znacznie bardziej interesuje mnie pokazanie, dlaczego określona wersja rozwiązania nie była wystarczająco dobra i jak została poprawiona, niż stworzenie wrażenia, że pierwszy prototyp od razu działał idealnie.

Co NetGuard ma potrafić po zakończeniu projektu?

Finalnie chcę dojść do urządzenia, które po zamontowaniu obok infrastruktury sieciowej może działać miesiącami bez codziennej obsługi.

Nie musi być centralnym systemem zarządzania siecią. Nie ma zastępować profesjonalnego monitoringu ani administratora. Ma wykonać jeden konkretny rodzaj pracy bardzo przewidywalnie.

Przykład z mojego domu

Załóżmy, że jeden z punktów dostępowych przestaje odpowiadać.

NetGuard nie powinien od razu kliknąć przekaźnikiem. Najpierw sprawdza AP w kolejnych cyklach. Jednocześnie może sprawdzić router i inny host w sieci. Jeżeli router działa, a kolejne próby kontaktu z AP nadal kończą się niepowodzeniem, reguła nabiera znacznie większej pewności, że problem faktycznie dotyczy AP.

Dopiero wtedy Master może zlecić Power Module kontrolowany RESET odpowiedniego kanału.

Po przywróceniu zasilania AP potrzebuje czasu na uruchomienie. NetGuard nie interpretuje tego czasu jako kolejnej awarii. Po okresie stabilizacji zaczyna ponownie sprawdzać urządzenie.

Jeżeli wszystko wróciło do normy, temat jest zakończony.

Jeżeli nie, kolejna próba nie następuje od razu. I właśnie ta część projektu jest dla mnie znacznie ciekawsza niż samo sterowanie przekaźnikiem.

NetGuard nie zastąpi UPS-a

Warto też od razu postawić wyraźną granicę. NetGuard nie rozwiązuje każdego problemu z niezawodnością.

Jeżeli w domu całkowicie zniknie zasilanie i infrastruktura nie ma podtrzymania, watchdog również nie ma czego naprawiać. Nie zastąpi UPS-a. Nie naprawi uszkodzonego zasilacza. Nie wymieni zerwanego kabla. Nie przywróci urządzenia z uszkodzoną pamięcią flash.

Jego zadaniem jest automatyczne wykonanie tej jednej czynności, którą w wielu przypadkach i tak wykonałbym ręcznie: potwierdzić problem i na kilka sekund całkowicie odłączyć urządzenie od zasilania.

Różnica polega na tym, że może zrobić to również wtedy, kiedy jestem kilkaset kilometrów od domu.

Firmware będzie publiczny

Nie planuję pozostawić NetGuarda jako zamkniętego projektu działającego tylko w mojej instalacji.

Po ustabilizowaniu obu części firmware udostępnię kod na GitHubie. Chcę też przygotować gotowe obrazy BIN, żeby osoba, która chce odtworzyć projekt, nie musiała rozpoczynać od budowania środowiska kompilacji.

W kolejnych częściach pokażę zarówno drogę dla osoby, która chce zbudować firmware samodzielnie, jak i prostsze wgrywanie gotowego obrazu.

Repozytorium dodam tutaj po opublikowaniu stabilnego wydania:

Co dalej?

Pierwszym elementem, który doprowadzam do wersji nadającej się do finalnych testów, jest NetGuard Power.

W kolejnej części rozbieram SONOFF 4CHR3, pokazuję jego płytkę, przygotowanie do programowania i mój własny firmware. Zobaczymy też, dlaczego wyłączyłem Wi-Fi i chmurę, jak działa komunikacja UART, po co w torze pojawia się ADuM1201, jak NetGuard potwierdza wykonanie resetu i co powinno się wydarzyć, jeżeli komunikacja z Masterem zniknie już po odłączeniu zasilania urządzenia.

NetGuard – najczęstsze pytania

Czy NetGuard działa bez Home Assistant?

Tak. To jedno z głównych założeń projektu. Diagnostyka i decyzje o restartach działają na NetGuard Master. Home Assistant jest dodatkowym interfejsem do podglądu, historii i ręcznych operacji.

Dlaczego NetGuard Master nie korzysta z Wi-Fi?

Ponieważ watchdog infrastruktury sieciowej nie powinien zależeć od Wi-Fi, którego awarię może być zmuszony diagnozować. WT32-ETH01 korzysta z fizycznego Ethernetu i w mojej instalacji będzie przewodowo podłączony bezpośrednio do routera.

Ile urządzeń można restartować?

Fizyczny Power Module ma cztery niezależne kanały. Cele diagnostyczne są jednak od nich oddzielone, więc można obserwować więcej usług i hostów niż fizycznych odbiorników podłączonych do gniazd.

Czy można monitorować kamery PoE?

Tak. Przykładowo NetGuard może obserwować dostępność kamery, a po potwierdzonej awarii wykonać restart kanału, do którego podłączony jest zasilający ją switch PoE.

Czy NetGuard będzie dostępny na GitHubie?

Tak. Po ustabilizowaniu projektu planuję udostępnić kod źródłowy oraz gotowe pliki BIN.