Eine leere VPN-Tabelle blockiert für sich genommen nichts

Eine Policy-Regel schickt markierte Pakete in eine eigene Tabelle, und die übliche Erwartung ist, dass der Verlust der VPN-Route sie blockiert. Der Mechanismus tut etwas anderes. Wenn eine Tabelle keine passende Route enthält, läuft die Suche zur nächsten Regel weiter statt anzuhalten, und die Tabelle main hält weiterhin eine gewöhnliche Standardroute für den Uplink. Das Ergebnis ist eine Konfiguration, die fail-closed aussieht und sich fail-open verhält.

Nichts ist kaputt; so ist Policy-Routing spezifiziert.

Die Suche läuft weiter, wenn eine Tabelle nichts enthält

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 lookup default
32766: from all lookup main

Nehmen Sie diesen Regelsatz: Eine markierte Suche geht in Tabelle 42, und eine spätere Regel schickt dieselbe Markierung in eine Tabelle namens default. Solange Tabelle 42 eine brauchbare Standardroute hält, liefert die erste Suche den Pfad. Wenn diese Route verschwindet und sonst nichts in Tabelle 42 passt, wird die Suche nicht zu einem Verwerfen; die Verarbeitung geht zur nächsten Regel weiter, und wenn auch diese nichts findet, erreicht sie die Tabelle main. Nichts in dieser Folge meldet, welche Regel die endgültige Antwort geliefert hat, sodass eine funktionierende Verbindung wie eine funktionierende Policy aussieht.

Tabelle 253, üblicherweise default genannt, ist eine gewöhnliche Routing-Tabelle und normalerweise leer. Ihr Name ist keine Anweisung, Pakete zu verwerfen, und er ist nicht dasselbe wie eine Standard-Zielroute innerhalb einer Tabelle.

Terminale Aktionen beenden die Suche

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 prohibit
32766: from all lookup main

Eine terminale Regel kann auf die VPN-Suche folgen, anstelle einer Suche in einer leeren Tabelle. Mit derselben Markierung beendet eine prohibit-Aktion, die nach der Regel für Tabelle 42 steht, die Suche, wenn diese Tabelle nichts liefert, und gibt eine administrative Ablehnung zurück, statt der Tabelle main eine weitere Chance zu geben. Unreachable und blackhole sind ebenfalls terminal, mit anderem Fehlerverhalten für den Absender.

Eine Route vom Typ throw ist anders: Innerhalb dieser Tabelle verhält sie sich, als hätte nichts gepasst, sodass spätere Regeln trotzdem zum Zug kommen. Das macht throw für einen bewussten Rückfall nützlich und als endgültige Sperre falsch.

Prüfen Sie mit der echten Markierung und Schnittstelle

ip -4 rule show
ip -4 route show table 42
ip -4 route get 198.51.100.20 from 10.44.0.2 iif lan0 mark 0x36

Untersuchen Sie die echten Regeln und die Tabelle statt eines Diagramms und fragen Sie dann den Fluss mit dem Quell-, Markierungs- und Eingangskontext ab, den er tatsächlich hat. Eine schreibgeschützte Suche auf ein Ziel, der Quelladresse, Schnittstelle und Markierung mitgeteilt werden, meldet die Route, die der Kernel wählen würde, ohne dass ein Paket das System verlässt. Eine Markierung in der Abfrage anzugeben beweist nicht, dass die Firewall echten Verkehr markiert; das ist eine getrennte Prüfung der Markierungsregeln. Bestätigen Sie den Wert mit einem Zähler oder einem Log, bevor Sie Schlüsse aus der Abfrage ziehen.

Lokal erzeugte Anfragen brauchen ihren eigenen Kontext, weil ihr Markierungspfad sich oft von dem weitergeleiteten Verkehrs unterscheidet. Prüfen Sie sie mit der Ausgangsschnittstelle, die die Anwendung wirklich verwenden würde.

Zwei Fehlerzustände, nicht einer

Ein Fehlerzustand ist, dass die VPN-Route verschwindet und der Verkehr auf den Uplink durchfällt. Ein toter Tunnel, dessen Route installiert bleibt, ist ein anderer: Pakete bleiben in einen unbrauchbaren Pfad gelenkt, statt durchzufallen, und das Symptom ist stiller Verlust statt einer sichtbaren direkten Verbindung. Testen Sie beides und ebenso das Verhalten bei Start, Wiederverbindung und Dienststopp.

Eine solche Regel hilft nur, solange sie existiert und solange Pakete noch die Markierung tragen, die sie auswählt. Ein Shutdown-Skript, das die Regel löscht, oder ein Pfad, der die Markierung entfernt, stellt das offene Verhalten wieder her. Diese Übergänge sollte man üben.

Wenden Sie die Policy auf IPv6 getrennt an und halten Sie genehmigte Endpunkt-Ausnahmen ausdrücklich statt implizit.