Router-VPN überwachen, ohne einer Statuslampe zu vertrauen
Peer-Zustand, die gewählte Route und eine erlaubte Anwendungssonde beantworten verschiedene Fragen. Alarmieren Sie an der Grenze, die versagt hat, nicht an einem grünen Symbol.
Die Statusseite meldet verbunden, die Lampe ist grün, und das Büro erreicht den Dateiserver nicht. Eine dieser Tatsachen betrifft den Tunnel, die andere den Weg hindurch. Beides zu überwachen ist der Unterschied zwischen einem Alarm, auf den man reagieren kann, und einem, den man zu ignorieren lernt.
Fünf Prüfungen, der Reihe nach, vom Peer nach außen.
Prüfung 1: Peer- oder Association-Zustand
Jedes Protokoll legt seinen eigenen Zustand offen. WireGuard zeigt den letzten Handshake und die Übertragungszähler pro Peer über wg show. OpenVPN schreibt den Sitzungszustand in seine Statusdatei oder Verwaltungsschnittstelle, und IPsec legt Sicherheitsassoziationen über Werkzeuge wie ipsec statusall offen. Die Falle besteht darin, einen Zeitstempel als Urteil zu lesen: Ein untätiger WireGuard-Peer, der nichts zu senden hat, wird nicht kürzlich einen Handshake ausführen, und das ist kein Ausfall.
Vergleichen Sie den Zeitstempel mit dem erwarteten Verkehr und den Keepalive-Einstellungen, bevor Sie jemanden rufen.
Prüfung 2: die gewählte Route
Eine Tunnelschnittstelle kann existieren, während nichts hineinroutet. Prüfen Sie die Weiterleitungstabelle für das Ziel, das Sie interessiert, nicht für das eigene Subnetz des Tunnels. Fehlt das Präfix oder zeigt es woanders hin, ist der Peer-Zustand irrelevant.
Diese Prüfung erwischt den Fehler, den eine Statuslampe nie zeigt.
Eine nützliche zweite Prüfung vergleicht auch die Quelladresse. ip route get 10.20.5.10 liefert den nächsten Hop, die Schnittstelle und die bevorzugte Quelle, und eine falsche Quelle genügt, um den Rückverkehr am fernen Ende zu brechen. Notieren Sie das erwartete Tripel einmal und alarmieren Sie dann, wenn sich ein Element ändert. Diese eine Zeile erwischt NAT-Änderungen, Schnittstellen-Flaps und Fehler im policybasierten Routing.
Prüfung 3: ein erlaubter Anwendungspfad
Prüfen Sie etwas, das die tatsächliche Anforderung repräsentiert. Ein vom Router ausgehender Ping startet von der eigenen Adresse und Richtlinie des Routers, die sich vom weitergeleiteten LAN-Verkehr unterscheiden können, und viele Hosts drosseln ICMP. Ist die Anforderung ein privater Dienst, testen Sie diesen Dienst auf seinem echten Port.
Halten Sie das Sondenvolumen bescheiden. Eine Überwachungsschleife sollte nicht zu dem Verkehr werden, den sie misst.
Prüfung 4: was sich geändert hat und wann
Korrelieren Sie WAN-Änderungen, Schlüsselerneuerungen, Routenrücknahmen und Anwendungsfehler auf einer Zeitachse. Unterscheiden Sie einen Tunnelausfall von einer Ausweichroute, die stillschweigend den normalen Internetzugang wiederherstellt, denn beide erzeugen identische Nutzermeldungen und gegensätzliche Diagnosen. Zeitzonenfehler kehren die Reihenfolge um, normalisieren Sie also vor dem Vergleich. Die Zeitachse ist es, die vier Prüfungen zu einer Ursache macht.
Bewahren Sie Protokolle für die Übergänge auf, nicht für die Nutzlast.
Prüfung 5: der Alarm sollte die Grenze benennen
Ein Alarm, der VPN weg meldet, schickt jemanden in der Hälfte der Fälle an die falsche Stelle. Einer, der sagt, der Peer-Handshake sei seit zwölf Minuten veraltet, die Route nach 10.20.0.0/16 fehle oder die Sonde auf Port 445 schlage fehl, zeigt auf eine bestimmte Prüfung.
Führen Sie Betriebszähler, statt Nutzlasten zu durchsuchen. Zähler beantworten die Überwachungsfrage, ohne Inhalte zu sammeln, die Sie nicht brauchen.
Und lassen Sie die Failover-Richtlinie entscheiden, was als Nächstes geschieht. Die Überwachung soll feststellen, welche Grenze versagt hat, nicht jedes Mal eine breite Umgehung genehmigen, wenn eine Sonde fehlschlägt. Das OpenVPN-2.6-Handbuch dokumentiert die Statusdatei und die Verwaltungsschnittstelle, die die erste Prüfung skriptfähig machen.