Warum ein VPN-Client im Büro-LAN jede Antwort verliert

Ein Laptop sitzt über Ethernet im /24 des Büros und tritt zugleich einem OpenVPN-Server bei, der im selben /24 lebt. Ein Kollege pingt die Tunneladresse; die Anfrage kommt eindeutig an, und nichts geht zurück. Das Tunnellog ist sauber, und Surfen funktioniert weiter, also ist der Tunnel der falsche Verdächtige. Die IPv4-Quellvalidierung auf der empfangenden Maschine verwirft das Paket, bevor irgendetwas es liest.

Der Verlust passiert, bevor irgendetwas das Paket liest

Die Quellvalidierung stellt eine Frage zu jedem eingehenden Paket: Wenn dieser Host jener Quelle antworten würde, würde die Antwort dann über die Schnittstelle hinausgehen, auf der das Paket gerade angekommen ist? Lautet die Antwort nein, verwirft der Kernel das Paket beim Eintreffen. Weder ein Socket noch ein Weiterleitungspfad sieht es je, und deshalb zeichnet ein Mitschnitt am Tunnel weiterhin eine Anfrage auf, die die Anwendung nie erhält.

Der Client hält hier 10.66.0.9 auf seinem Tunnel, und der OpenVPN-Server antwortet unter 192.168.80.10 innerhalb des Büropräfixes. Ein Kollege auf 192.168.80.25 pingt die Tunneladresse, also quert die Anfrage das LAN, der Server leitet sie in den Tunnel, und sie kommt auf der Tunnelschnittstelle des Clients mit einer Büro-Quelladresse an. In der Routing-Tabelle jener Maschine gehört das Büropräfix zum Ethernet-Gerät, nicht zum Tunnel. Die Validierung vergleicht die Ankunftsschnittstelle mit der Route, findet eine Abweichung und verwirft das Paket, sodass der Kollege völligen Verlust sieht, während beide Enden einen gesunden Tunnel melden.

Die Spiegelrichtung hat dieselbe Form: Wenn der Client zum Büro hin beginnt, können Antworten auf der Büroseite aus demselben Grund verworfen werden. Eine nur in einer Richtung geprüfte Korrektur kommt meist als zweites Ticket zurück.

Beweisen Sie den wirksamen Modus, bevor Sie ein sysctl anfassen

Lesen Sie die effektiven Werte, statt einer Distributionsvorgabe zu vertrauen, denn die Einstellung pro Schnittstelle ist nur die Hälfte der Entscheidung. Der wirksame Modus ist der höhere aus Schnittstellenwert und dem Wert von all, eine Null auf der Tunnelschnittstelle bedeutet also nichts, solange all eins ist. Die Entscheidung des strengen Modus ist eine Routingentscheidung, führen Sie also die Suche aus, die der Kernel ausführt, und vergleichen Sie ihre Antwort mit der Schnittstelle, auf der das Paket tatsächlich ankam.

tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filter

Wiederholen Sie dann den Ping und beobachten Sie den Fehlerzähler. Ein steigender Zähler neben einer Anfrage, die der Mitschnitt bereits zeigt, ist die Signatur dieses Verlusts, nicht einer fehlenden Route. Schalten Sie dort die Marsianer-Protokollierung ein, damit der Kernel die Quelle und die Schnittstelle nennt, die er zurückgewiesen hat. Zusammen schließen sie die Verschlüsselung, die Firewall und ein fehlendes iroute als Erklärungen aus.

Schreiben Sie die Ausgangslage auf, bevor Sie etwas ändern: beide Werte, das Gerät, das die Suche gewählt hat, und den Zähler, den Sie beobachtet haben. Genau dieser Eintrag sagt Ihnen später, ob die Änderung das getan hat, was Sie denken.

Was jeder rp_filter-Modus tatsächlich annimmt

Der Kernel zeigt drei Werte pro Schnittstelle, und sie sind nicht drei Schattierungen einer Regel. Null schaltet die Prüfung ab. Eins ist streng und verlangt, dass die Quelle über die Ankunftsschnittstelle zurückgeroutet wird. Zwei ist locker und verlangt nur, dass irgendeine Route zur Quelle in der Tabelle existiert, wohin sie auch zeigt.

Die Zeile, auf die es hier ankommt, ist die lockere, und das, was sie weiterhin zurückweist. Eine gefälschte Quelle, die irgendwo in Ihrer Tabelle geroutet werden kann, kommt durch, während eine Quelle ohne jede Route weiterhin abgelehnt wird. Auf einem Laptop ist das ein enges Zugeständnis; auf einem Router, der Verkehr für andere weiterleitet, ein weites. Der Modus gehört zum Host, also trägt dieselbe Zahl an den beiden Orten unterschiedliches Gewicht.

Welche Zeile diese Topologie braucht, folgt aus der Tabelle und nicht aus Gewohnheit. Das Paket ist legitim und seine Quelle ist routbar, also nimmt die lockere es an und die strenge nicht. Nichts in diesem Fall verlangt nach Null, und Null zu wählen würde eine Prüfung entfernen, die hier nichts kostet.

Wählen Sie die kleinste Änderung, die die Mehrdeutigkeit beseitigt

Der lockere Modus ist die kleinste passende Änderung, und er ist eine echte Absenkung der Strenge, kein harmloser Schalter. Eine bessere Option gibt es, wann immer die Topologie es erlaubt: Beseitigen Sie die Überlappung, und die Mehrdeutigkeit verschwindet.

Wo das Büropräfix nur über Ethernet gebraucht wird, nehmen Sie es aus den Routen, die das Profil zieht, und die Adresse wird über einen Pfad erreichbar. Wenn beide Pfade wirklich nebeneinander bestehen müssen, nageln Sie Quelle und Gerät mit einer Policy-Regel fest, statt die Validierung auf jeder Schnittstelle zu lockern. Das behält die strenge Filterung für alles andere auf der Maschine bei und dokumentiert die Ausnahme dort, wo der nächste Ingenieur sie suchen wird.

Welchen Weg Sie auch wählen, halten Sie ihn in einem sysctl-Drop-in fest und nicht in einem Live-Befehl. Setzen Sie die Schlüssel all und default gemeinsam, damit ein Wiederverbinden den strengen Modus nicht still zurückholen kann.

# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --system

Was der lockere Modus aufgibt, und wo

Der lockere Modus weist weiterhin eine Quelle zurück, die keine Route erreichen könnte, und er hört auf, eine gefälschte Quelle zurückzuweisen, die zufällig routbar ist. Auf einem Laptop ist das ein enges Zugeständnis. Auf einem Gerät, das Verkehr weiterleitet, der ihm nicht gehört, ist dieselbe Wahl eine viel weitere. Dieselbe Einstellung trägt daher zwei sehr verschiedene Bedeutungen, je nachdem, wo sie läuft.

Die Prüfung ganz abzuschalten, auf einem Host, der Verkehr für andere weiterleitet, ist die eine Reparatur, die man vermeiden sollte. Null wirft die Validierung weg, die der lockere Modus sorgfältig behält. Wenn der Host für andere weiterleitet, plädieren Sie stattdessen für die Policy-Regel-Option aus dem vorigen Abschnitt.

Hinterlassen Sie eine Notiz, die beide Schnittstellen, das überlappende Präfix und die genaue Probe nennt, die jetzt gelingt. Das ist für den nächsten Ingenieur nützlicher als eine Zeile, die sagt, die Filterung sei angepasst worden.