Linux-VPN-Antworten verschwinden? Prüfen Sie rp_filter und die Route

Anfragen verlassen den Rechner, der VPN-Peer antwortet, und die Antwort erreicht nie den Socket. Der Tunnel steht, die Logs des Peers zeigen das gesendete Paket, und nichts in der Anwendung erklärt die Stille. Unter Linux ist die Reverse-Path-Filterung einer der üblichen Verdächtigen: Ein eingehendes IPv4-Paket kann verworfen werden, wenn die Quellvalidierung nicht zu der Route passt, die der Kernel für diese Quelle erwartet. Wer das der Reihe nach durchgeht, erfährt, ob das die Ursache ist oder ein Zufall. Es bewahrt Sie auch davor, eine Sicherheitskontrolle abzuschalten, um eine fehlende Route zu reparieren.

Was die Quellvalidierung entscheidet

Der Kernel prüft, ob die Quelladresse eines Pakets für die Schnittstelle, auf der es ankam, plausibel ist, indem er die Routingtabelle nach einer Route zurück zu dieser Quelle befragt. Zeigt die Rückroute woanders hin, kann das Paket verworfen werden, bevor irgendeine Firewall-Regel oder ein Anwendungs-Socket es sieht. Diese Prüfung existiert, um bestimmte Spoofing-Muster schwerer zu machen, und deshalb laufen asymmetrische und policy-routed Designs hinein, während jeder gewöhnliche Client im selben Netz einwandfrei funktioniert. Gewöhnliche Clients haben symmetrisches Routing, und genau das setzt die Prüfung voraus.

Das wichtige Wort ist plausibel. Das Paket kann völlig legitim sein und die Prüfung trotzdem nicht bestehen, weil nicht die Legitimität geprüft wird.

Lesen Sie den wirksamen Modus, nicht ein Feld

Es gibt drei Modi: deaktiviert, strikt und locker. Strikt erzwingt eine andere Routenerwartung als locker, und die globale Einstellung wirkt mit denjenigen je Schnittstelle zusammen, sodass das Lesen einer einzelnen Datei falsch beschreiben kann, was tatsächlich gilt. Lesen Sie beides, und lesen Sie es an der Schnittstelle, die die Antwort empfängt, nicht an der der Standardroute.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

Die Routenabfrage in der dritten Zeile ist der Teil, den Leute überspringen. Sie sagt Ihnen, was der Kernel über die Quelle annimmt, und das ist genau die Eingabe der Prüfung.

Finden Sie die Abweichung, bevor Sie die Prüfung ändern

Finden Sie heraus, warum die Antwort auf dieser Schnittstelle ankommt und ob ihre Rückroute anders sein soll. Eine Policy-Regel, die Anfragen über einen Pfad hinausschickt, während Antworten über einen anderen zurückkehren, ist ein legitimes Design, und genau dieses Design lehnt die strikte Validierung ab. Marks, die im Policy-Routing verwendet werden, können hier ebenfalls zählen, weil sie ändern, was die Rückwärtsabfrage liefert.

Fehlt die Rückroute schlicht, behebt das Hinzufügen die Ursache, statt eine Prüfung abzuschalten. Eine fehlende Route, eine Firewall-Ablehnung und ein falscher Traffic-Selector erzeugen alle dasselbe sichtbare Symptom, und nur eines davon betrifft die Quellvalidierung.

Schalten Sie Quellprüfungen nicht als erste Reaktion global ab. Das tauscht eine konkrete Diagnose gegen eine breite Verhaltensänderung, an die Sie sich später erinnern müssen.

Eine selektive Anpassung, die Sie verteidigen können

Wenn eine enge Anpassung wirklich nötig ist, begrenzen Sie sie auf die Schnittstelle, die sie braucht, notieren Sie warum, und legen Sie sie in der Konfiguration ab, der diese Schnittstelle gehört, damit sie einen Neustart übersteht. Testen Sie dann genau den Ablauf erneut, der fehlgeschlagen ist, von derselben Quelle zum selben Ziel, statt eines Pings auf etwas Bequemes.

Nehmen Sie einen Fall auf, der weiterhin abgelehnt werden sollte. Gelingt dieser Fall jetzt, hat die Anpassung mehr geschwächt als den einen Pfad, den Sie reparieren wollten.

Halten Sie IPv4 und IPv6 getrennt

Ein vertraut aussehendes sysctl ist keine Richtlinie für jede Adressfamilie. IPv6 hat sein eigenes Verhalten und seine eigenen Einstellungen, und ein Rechner kann in der einen Familie strikt und in der anderen nachsichtig sein, ohne dass es jemand merkt, bis ein bestimmtes Ziel ausfällt. Prüfen Sie beides, wenn die Arbeitslast beides nutzt.

Halten Sie Modus, Schnittstelle, die Ausgabe der Routenabfrage und den Grund der Änderung an einer Stelle fest. Die nächste Person findet die Einstellung und keine Erklärung und wird sie entweder entfernen oder dorthin kopieren, wo sie nicht hingehört.