Monitoruj VPN na routerze, nie ufając jednej lampce stanu

Strona stanu mówi połączono, lampka jest zielona, a biuro nie dociera do serwera plików. Jeden z tych faktów dotyczy tunelu, drugi drogi przez niego. Monitorowanie obu to różnica między alertem, na który można zareagować, a takim, którego uczy się ignorować.

Pięć kontroli, po kolei, od peera na zewnątrz.

Kontrola 1: stan peera lub asocjacji

Każdy protokół ujawnia własny stan. WireGuard pokazuje ostatni handshake i liczniki transferu dla każdego peera przez wg show. OpenVPN zapisuje stan sesji do pliku stanu lub interfejsu zarządzania, a IPsec ujawnia asocjacje bezpieczeństwa narzędziami takimi jak ipsec statusall. Pułapką jest czytanie znacznika czasu jako wyroku: bezczynny peer WireGuard, który nie ma nic do wysłania, nie wykona niedawno handshake'u, i to nie jest awaria.

Porównaj znacznik czasu z oczekiwanym ruchem i ustawieniami keepalive, zanim kogoś zaalarmujesz.

Kontrola 2: wybrana trasa

Interfejs tunelu może istnieć, podczas gdy nic do niego nie jest routowane. Sprawdź tablicę przekazywania dla miejsca docelowego, które cię interesuje, a nie dla własnej podsieci tunelu. Jeśli prefiks jest nieobecny lub wskazuje gdzie indziej, stan peera jest nieistotny.

Ta kontrola wychwytuje awarię, której lampka stanu nigdy nie pokazuje.

Przydatna druga kontrola porównuje też adres źródłowy. ip route get 10.20.5.10 zwraca następny przeskok, interfejs i preferowane źródło, a błędne źródło wystarczy, by zerwać ruch powrotny na drugim końcu. Zapisz oczekiwaną trójkę raz, a potem alarmuj, gdy zmieni się dowolny element. Ta jedna linia wychwytuje zmiany NAT, fluktuacje interfejsu i błędy routingu opartego na polityce.

Kontrola 3: dozwolona ścieżka aplikacji

Przetestuj coś reprezentatywnego dla rzeczywistego wymagania. Ping z routera wychodzi z własnego adresu i polityki routera, które mogą różnić się od przekazywanego ruchu LAN, a wiele hostów ogranicza ICMP. Jeśli wymaganiem jest usługa prywatna, przetestuj tę usługę na jej prawdziwym porcie.

Utrzymuj skromny wolumen prób. Pętla monitorująca nie powinna stawać się ruchem, który mierzy.

Kontrola 4: co się zmieniło i kiedy

Skoreluj zmiany WAN, odnowienia kluczy, wycofania tras i awarie aplikacji na jednej osi czasu. Odróżnij awarię tunelu od trasy zapasowej, która po cichu przywraca zwykły dostęp do internetu, bo obie dają identyczne zgłoszenia użytkowników i przeciwne diagnozy. Błędy strefy czasowej odwrócą kolejność, więc normalizuj przed porównaniem. To oś czasu zamienia cztery kontrole w przyczynę.

Zachowuj logi dla przejść, nie dla ładunku.

Kontrola 5: alarm powinien nazwać granicę

Alarm mówiący VPN padł w połowie przypadków wysyła kogoś w złe miejsce. Alarm mówiący, że handshake peera jest przestarzały od dwunastu minut, brak trasy do 10.20.0.0/16 lub próba na port 445 zawodzi, wskazuje konkretną kontrolę.

Prowadź liczniki operacyjne zamiast przeglądać ładunki. Liczniki odpowiadają na pytanie monitoringu bez zbierania treści, której nie potrzebujesz.

I pozwól polityce przełączania zdecydować, co dalej. Monitoring powinien wskazać, która granica zawiodła, a nie autoryzować szerokiego obejścia za każdym razem, gdy próba zawiedzie. Podręcznik OpenVPN 2.6 dokumentuje plik stanu i interfejs zarządzania, które czynią pierwszą kontrolę skryptowalną.