Sorgen Sie dafür, dass IPv4-Weiterleitung einen Neustart des VPN-Gateways übersteht

Der Ping auf das Gateway funktioniert, der Zugriff auf alles dahinter nicht, und das ist die Form eines Weiterleitungsproblems und nicht eines Tunnelproblems. Die lokale Zustellung an das Gateway beweist, dass der Tunnel hochkam und die Adresszuweisung funktionierte; sie sagt nichts darüber, ob der Kernel ein Paket von einer Schnittstelle zur anderen durchreicht. Bevor Sie an einem sysctl rühren, bestätigen Sie, dass die Maschine diesen Verkehr weiterleiten soll und ermitteln Sie den Netzwerk-Kontext, der die clientseitige Schnittstelle hält. Lesen Sie den Wert dann dort, und nicht dort, wo der zuletzt gelesene Leitfaden zufällig hingeschaut hat.

Das Gateway zu erreichen ist nicht dasselbe wie weiterzuleiten

Im Kernel fallen zwei getrennte Entscheidungen. Die Zustellung an eine lokale Adresse beendet die Reise des Pakets; die Weiterleitung schickt es über eine andere Schnittstelle wieder hinaus, und diese zweite Entscheidung wird pro Netzwerk-Namensraum geregelt. Ein Gateway kann vollkommen erreichbar sein, während die Weiterleitung aus ist, und aus einer Ping-Eingabe sehen beide Fehler gleich aus.

Notieren Sie, auf welcher Schnittstelle das Client-Paket ankommt und über welche Schnittstelle der weitere Weg hinausgeht. Beide gehören zu einem Namensraum, und dieser Namensraum hält die Einstellung, auf die es ankommt.

Lesen Sie den Wert dort, wo die Pakete tatsächlich sind

Auf einem Gateway, das im Host-Namensraum routet, beantwortet ein Befehl die Frage: sysctl net.ipv4.ip_forward. Wenn der eingehende und der weitere Weg in einem benannten Namensraum liegen, fragen Sie diesen Namensraum: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Der Host-Wert ist kein Stellvertreter für den Namensraum-Wert, und eine Eins auf dem Host ist kein Beweis für irgendetwas.

Nicht jeder Routing-Kontext hat eine Bezeichnung, die Sie an ip netns übergeben können. Container-Laufzeitumgebungen und Dienste erzeugen Namensräume, die nie unter einem freundlichen Namen registriert werden, und für diese nutzen Sie die Inspektionswerkzeuge der Laufzeitumgebung. Ersetzen Sie vpn-gw durch den echten Namen oder durch den Mechanismus der Laufzeitumgebung, der denselben Kontext erreicht, und hören Sie auf, auf Host-Ebene zu raten.

Geben Sie der Einstellung einen einzigen Eigentümer

Auf einem konventionellen systemd-Host-Gateway ist die dauerhafte Form eine Drop-in-Datei mit einem vom Administrator gewählten Namen wie /etc/sysctl.d/60-vpn-forwarding.conf, die net.ipv4.ip_forward = 1 enthält. Schreiben Sie die Datei und laden Sie dann genau diese Datei, damit sich auch der Live-Zustand ändert: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, gefolgt von einem Rücklesen. Der Dateiname ist ein Beispiel und kein reservierter VPN-Pfad, und die führende Zahl zählt, weil später sortierte Dateien gewinnen.

Die Rangfolge ist der Ort, an dem Dauerhaftigkeit leise bricht. Prüfen Sie sowohl den Distributionslader als auch Ihr eigenes Drop-in, denn procps sysctl --system liest am Ende auch /etc/sysctl.conf, während die sysctl.d-Reihenfolge von systemd eine völlig andere Abfolge ist. Eine spätere Zuweisung kann denselben Schlüssel direkt zurücksetzen und lässt Ihre Datei korrekt und den effektiven Wert falsch. Überschreiben Sie keine vorhandene Administratordatei, um diesen Streit zu gewinnen; finden Sie den Eigentümer und ändern Sie es dort.

Ein nach dem Booten erzeugter Namensraum wird überhaupt nicht von einem Host-Drop-in geregelt. Seine Einstellung gehört dem, was ihn erzeugt, ob das die Container-Laufzeitumgebung oder die Provisionierungseinheit für den Namensraum ist. Einem Container weitreichende Host-Rechte zu geben, um die Frage zu umgehen, ist ein schlechteres Geschäft, als zehn Minuten damit zu verbringen, den richtigen Eigentümer zu identifizieren.

Wissen Sie, was der Schalter kostet, bevor Sie ihn umlegen

ip_forward ist kein harmloser Boolean. Die Kernel-Dokumentation merkt an, dass seine Änderung mehrere andere IPv4-Parameter auf ihre Host- oder Router-Standardwerte zurücksetzt, sodass ein diagnostisches Umlegen eine an anderer Stelle vorgenommene Abstimmung verwerfen kann, ohne sie je zu erwähnen. Behandeln Sie es als Konfigurationsänderung mit Nebenwirkungen und nicht als Sonde, die man nebenbei laufen lässt.

Das schließt auch aus, es jedes Mal aus- und einzuschalten, wenn ein Client einen Host nicht erreicht. Wenn der Wert bereits Eins ist, liegt der Fehler anderswo im Pfad, und denselben Schlüssel ein drittes Mal zu schreiben bewegt ihn nicht.

Belegen Sie die Dauerhaftigkeit und testen Sie dann den Rest des Pfades

Lesen Sie den Wert zu vier Zeitpunkten zurück: direkt nach der Änderung, nachdem die VPN-Schnittstelle erscheint, nach einer Wiederverbindung und nach einem geplanten Neustart. Ein Wert, der an einem dieser Punkte zurückspringt, hat einen zweiten Eigentümer, und ein weiteres einmaliges Schreiben versteckt das nur bis zum nächsten Neustart.

Auch mit aktivierter Weiterleitung bleiben drei Dinge zu prüfen. Der Client braucht eine Route zum Ziel, das Gateway braucht eine Weiterroute plus die Berechtigung, sie zu nutzen, und das Ziel braucht einen Rückweg zur Tunneladresse des Clients. Ein privates geroutetes LAN braucht nicht automatisch NAT, also fügen Sie kein Masquerading hinzu, bevor Sie wissen, welches der drei fehlt, und testen Sie vom vorgesehenen Client statt vom Gateway selbst, denn eine auf dem Gateway gestartete Anfrage berührt nie den Weiterleitungspfad, den Sie gerade aktiviert haben. IPv6 hat seine eigene Weiterleitungs- und Routingpolitik, ein funktionierender IPv4-Test sagt also nichts darüber aus.

Halten Sie den Drop-in-Pfad, den Eigentümer des Namensraums und den Rücklesebefehl zusammen im Runbook. Wer das als Nächstes übernimmt, sollte den Wert lesen, sehen, wer ihn besitzt, und innerhalb einer Minute entscheiden können, ob das Problem die Dauerhaftigkeit oder der Rest des Pfades ist.