Warum net.ipv4.conf.default.forwarding tun0 unberührt lässt

Sie setzen net.ipv4.conf.default.forwarding=1, starten das VPN neu, und der Tunnel verwirft weiterhin Pakete, die das Gateway routen sollte. Die Einstellung sieht in der Datei richtig aus, und die Schnittstelle meldet weiterhin, dass Weiterleitung deaktiviert ist. Nichts ist kaputt: Sie haben den Wert geändert, den künftige Schnittstellen erben, nicht den, den der laufende Tunnel nutzt.

Gehen Sie das auf dem Host durch, dem der Tunnel gehört, in dem Netzwerk-Namespace, in dem der Tunnel tatsächlich existiert. Ein Container oder ein Netzwerk-Namespace kann die Schnittstelle halten, während der Host andere Zahlen zeigt.

Lesen Sie die drei Werte zusammen

Vergleichen Sie zuerst den gatewayweiten Schalter, die Vorlage für neue Schnittstellen und die Schnittstelle, um die es Ihnen geht. Ersetzen Sie tun0 durch die tatsächliche Eingangsschnittstelle und lesen Sie auch die Rückschnittstelle, denn Weiterleitung wird an dem Punkt bewertet, an dem das Paket ankommt.

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

Ein häufiges Ergebnis ist ip_forward = 0, default.forwarding = 1 und tun0.forwarding = 0. Die ersten beiden sind sich über die Rolle des Hosts uneinig, und der dritte zeigt, was die Schnittstelle tatsächlich tut. Diese Kombination passt zu einem Host, der nie als Router konfiguriert wurde, sondern nur einen Vorlagenwert bekommen hat. Die drei Zahlen widersprechen sich nicht; sie beantworten drei verschiedene Fragen. Auch das Schreiben des Vorlagenwerts entscheidet die Rolle des Hosts nicht.

Warum sich der globale Schalter bewegt

net.ipv4.ip_forward ist die gatewayweite Steuerung. Eine Änderung aktualisiert die Weiterleitungseinstellungen pro Schnittstelle als Teil desselben Vorgangs, weshalb ein einzelnes Schreiben einen bestehenden Tunnel zum Weiterleiten bringen kann. default.forwarding legt nur Schnittstellen an, die danach initialisiert werden, sodass ein bereits vorhandener Tunnel den Wert behält, mit dem er geboren wurde.

Die Kernel-Dokumentation kennzeichnet ip_forward aus einem verwandten Grund als besonders: Eine Änderung setzt eine Reihe anderer IPv4-Parameter auf Host- oder Router-Standardwerte zurück. Das macht ihn zu einem groben Werkzeug. Ihn einmal im Rahmen der Etablierung der Gateway-Rolle zu setzen ist in Ordnung; ihn wiederholt als Debugging-Trick umzuschalten kann stillschweigend eine Konfiguration überschreiben, für die Sie Zeit aufgewendet haben.

Werte pro Schnittstelle gibt es ebenfalls aus einem Grund. Ein bewusst verwaltetes Gateway kann die Weiterleitung auf einer Schnittstelle ausgeschaltet lassen, die nie routen soll, selbst während der Host anderswo weiterleitet. Deshalb ist es wichtig, die laufende Schnittstelle zu lesen, und deshalb ist der globale Wert allein nicht die ganze Antwort. Lesen Sie eine solche Ausnahme als bewusste Entscheidung und notieren Sie, warum diese Schnittstelle anders ist. Sonst wird der nächste Ingenieur sie hilfreich "reparieren".

Machen Sie die Einstellung am richtigen Ort dauerhaft

Ein erfolgreiches einmaliges sysctl -w beweist, dass der Kernel den Wert akzeptiert. Es überlebt keinen Neustart und überlebt auch keinen Netzwerkmanager, der beim Wiederverbinden seine eigene Vorstellung der Schnittstellenkonfiguration erneut anwendet. Legen Sie die Gateway-Rolle in die sysctl-Konfigurationsdatei oder in den Netzwerkmanager, dem der Host gehört, und starten Sie dann den Dienst neu, der sie anwendet.

Bei Tunneln kommt es auf die Reihenfolge an. Wenn der Manager die Schnittstelle beim Booten erstellt und die Weiterleitung danach anwendet, kann die Schnittstelle den alten Standard erben. Ein Dienstneustart, der den Tunnel neu erstellt, ist ebenfalls ein Erstellungsereignis, und das übersieht man leicht, wenn die Unit gesund aussieht. Prüfen Sie die Abfolge, nicht nur den endgültigen Dateiinhalt.

Lesen Sie dieselben drei Werte erneut, nachdem sich das VPN wieder verbunden hat, und noch einmal nach einem Neustart. Ein neu erstellter Tunnel ist eine neue Schnittstelle, und eine neue Schnittstelle übernimmt den Standard, der zum Zeitpunkt der Erstellung gilt. Ändern sich die Zahlen über diese Ereignisse hinweg, wird die Konfiguration von etwas angewendet, das Sie noch nicht identifiziert haben.

Reparieren Sie das nicht mit dem falschen Werkzeug

Als die Weiterleitung kaputt aussah, liegt die Versuchung nahe, die Firewall zu leeren oder Masquerading hinzuzufügen. Keines von beidem adressiert den Weiterleitungsschalter. Weiterleitungszustand, die Erlaubnis weiterzuleiten, eine Route zum Ziel und ein Rückweg sind vier getrennte Voraussetzungen, und nur die erste ist das sysctl.

Testen Sie auch mit dem richtigen Fluss. Eine Anfrage am Gateway selbst übt überhaupt keine Weiterleitung aus; das ist lokal erzeugter Verkehr. Die Frage ist, ob ein Paket, das von einem VPN-Client oder einem LAN-Host kommt, angenommen und weitergeleitet wird, also muss der Test hinter dem Gateway entstehen.

Halten Sie den IPv6-Fall getrennt

Hier ist alles IPv4. IPv6-Weiterleitung, Router-Ankündigungen und das accept_ra-Verhalten haben eigene Steuerungen, und einen ipv4-Pfad in eine ipv6-Einstellung zu kopieren erzeugt eine Datei, die plausibel aussieht und nichts Nützliches tut. Ein Dual-Stack-Gateway braucht beide Sätze bewusst konfiguriert.

Eine letzte Prüfung: Nachdem die Werte übereinstimmen, bestätigen Sie, dass die Route des Tunnels für das Ziel gewählt wird und dass der Antwortpfad existiert. Weiterleitung auf einer Schnittstelle ohne Route ist immer noch ein schwarzes Loch, und dieser Fehler sieht von der Clientseite identisch aus.