nftables-Richtlinie stabil halten, während die VPN-Schnittstelle kommt

Tunnel sind entbehrlich; eine Richtlinie sollte es nicht sein. Auf einem Linux-Gateway kann eine nftables-Regel, die die Tunnelschnittstelle über den Namen trifft, einmal geladen werden und gilt weiter, sobald diese Schnittstelle erscheint. Die Schnittstelle hat dennoch einen Lebenszyklus: Sie wird erzeugt, sie verschwindet, und die Routen und Übersetzungen darum herum folgen ihrem eigenen Zeitplan. Genau diese Zuständigkeiten zu trennen hält den Zugriff während einer Wiederverbindung stabil.

Ein Namensabgleich überlebt die Schnittstelle

nftables bietet numerische Abgleiche über den Schnittstellenindex und die dynamischen Namensabgleiche iifname und oifname. Regeln mit diesen Namen lassen sich sauber laden, auch wenn das Tunnelgerät noch nicht erzeugt wurde, was ein Regelsatz beim Start genau braucht. Der Abgleich endet, wenn die Schnittstelle umbenannt wird, und setzt wieder ein, wenn eine neue Schnittstelle den Namen übernimmt. Ein numerischer Index hat diese Eigenschaft nicht, deshalb ist die Namensform für einen Tunnel die übliche Wahl.

Der Name ist ein Abgleichsschlüssel, kein Beleg dafür, wer am anderen Ende steht. Die Authentifizierung des Peers bleibt Aufgabe der VPN.

Lesen Sie die Kette, bevor Sie Regeln hinzufügen

Sehen Sie nach, was der Regelsatz derzeit enthält und wo eine neue Regel stünde, denn die Reihenfolge entscheidet über das Ergebnis.

nft list ruleset
nft -c -f /etc/nftables.conf

Die Auflistung zeigt Ketten, Regeln und Handles, und der Prüfmodus validiert eine Kandidatendatei, ohne sie zu laden. Eine nur für den Tunnel gedachte Freigabe, die nach einer früheren Annahme für denselben Fluss steht, ändert nichts, weil die erste passende Regel gewinnt. Deshalb kann eine späte Regel richtig aussehen und keine Wirkung haben. Lesen Sie die Kette der Reihe nach und bestätigen Sie, dass die Sperre für Verkehr vom Client zum Uplink weiterhin allem Breiteren vorausgeht.

Routen, Übersetzung und Flüsse haben andere Zuständigkeiten

Die Anwesenheit der Schnittstelle erzeugt keine Routen und authentifiziert den Peer nicht. Das gehört zum VPN-Manager, während die Übersetzung einen dritten Lebenszyklus hat.

conntrack -L -s 10.20.0.0/24 | head
ip route show dev vpn0

Die conntrack-Auflistung zeigt bestehende Flüsse mit ihren ursprünglichen und übersetzten Werten, und die Routenauflistung zeigt, was der Manager für die Schnittstelle installiert hat. NAT-Regeln legen den Verbindungsverfolgungszustand beim ersten Paket an, daher behält ein etablierter Fluss seine Übersetzung auch nach einer Regeländerung. Deshalb sind eine aktualisierte Regel und ein Fluss, der den neuen Weg nutzt, zwei verschiedene Aussagen. Entscheiden Sie, welche Sitzungen sich neu verbinden müssen, und lassen Sie unbeteiligte Flüsse in Ruhe.

Kalten Start, Ausfall und Wiederherstellung akzeptieren

Testen Sie das Gateway mit fehlendem Tunnel beim Start, dann mit vorhandenem, dann nach einem Abbruch und einer Rückkehr. Bestätigen Sie, dass verbotene Weiterleitung verweigert bleibt, solange der Tunnel fehlt, dass ein neu erlaubter Fluss nach der Authentifizierung des Peers funktioniert und dass die Wiederherstellung kein Löschen unbeteiligten Zustands verlangt. Löschen Sie nicht die ganze POSTROUTING-Kette oder jeden conntrack-Eintrag als Stoppaktion eines Profils, weil andere Dienste sie teilen. Halten Sie fest, welche Komponente die Schnittstelle, die Route und die Richtlinie geändert hat, statt nur, dass ein Start-Hook mit null beendet wurde.

Eine Richtlinie, die eine Wiederverbindung überlebt, ist eine, deren Zuständigkeiten benannt sind und deren Regeln mit dem Tunnel sowohl unten als auch oben getestet wurden. Ein Hook, der Erfolg meldet, beweist nur, dass der Hook lief.