Ein VPN-Peer pingt andere Schnittstellen an, weil sie lokal sind

Ein WireGuard-Client verbindet sich und pingt eine Adresse auf einer völlig anderen Schnittstelle an, und die Antwort kommt an. Mitschnitte zeigen die Anfrage nur auf dem Tunnel. Nichts ist kaputt, und die sorgfältig deaktivierte Weiterleitungseinstellung hat damit nichts zu tun. Dies ist ein Vergleich zwischen zwei Pfaden, die im Diagramm gleich aussehen und im Kernel völlig verschieden sind.

Der eine Pfad leitet Pakete für jemand anderen weiter; der andere liefert sie an den Host selbst aus.

Ein an den Host adressiertes Paket bleibt im Host

Der entfernte Client sendet ein IP-Paket an eine Adresse, die der Host besitzt. Das Routing stellt eine Frage zu diesem Paket: Ist dieses Ziel lokal? Jede Adresse, die der Host hält, erscheint in der lokalen Routing-Tabelle, und diese Tabelle wird vor der Haupttabelle konsultiert, sodass das Paket in den eigenen Stack des Hosts geht, statt über eine andere Schnittstelle hinauszugehen. Die Antwort wird lokal erzeugt, und sie reist durch den Tunnel zurück, weil die Abfrage von dort kam.

Das ist der ganze Mechanismus. Es findet keine Weiterleitung statt, keine Änderung des Schnittstellenzustands ist beteiligt, und die fragliche Adresse muss von nirgendwo sonst erreichbar sein.

Warum ip_forward nicht greift

Weiterleitung regelt Pakete, die über eine andere Schnittstelle hinausgehen müssen als die, auf der sie angekommen sind. Ein Ping an den Host selbst nimmt diesen Pfad nie: Das Paket wird lokal verbraucht und die Antwort lokal erzeugt. Das Setzen von net.ipv4.ip_forward=0 ändert hier daher nichts, und eine Regel in der Forward-Kette sieht den Verkehr nie. Die richtige Kontrolle sitzt auf dem Eingangspfad, begrenzt durch eingehende Schnittstelle oder Quelle.

Deshalb erzeugt das Abschalten der Weiterleitung und die Annahme, der Host sei isoliert, ein falsches Sicherheitsgefühl.

Lesen Sie die lokale Tabelle, die entschieden hat

ip rule show meldet normalerweise eine Regel mit Priorität null, die alle Abfragen zuerst an die lokale Tabelle schickt, und ip route show table local listet die eigenen Adressen des Hosts mit lokalem Geltungsbereich auf. Diese Tabelle enthält Adressen auf Schnittstellen, die administrativ abgeschaltet, aber noch konfiguriert sind. Statisch zugewiesene IPv4-Adressen überleben normalerweise einen Linkausfall, und so kann ein Ping an eine abgeschaltete Bridge weiterhin gelingen und den Betreiber überraschen.

IPv6 widerspricht genau an diesem Punkt. Seine Adressen werden beim Linkausfall normalerweise zurückgezogen, sofern keep_addr_on_down nicht gesetzt ist. Vergleichen Sie die Familien, statt anzunehmen, eine Regel decke beide ab.

Was ein Peer tatsächlich erreicht

Eine Antwort von der eigenen Adresse des Routers auf einem Segment sagt nichts über die Maschinen hinter diesem Segment. Der Peer kann einen Host hinter der anderen Schnittstelle über diesen Pfad nicht erreichen; er erreicht nur Adressen, die der Router selbst besitzt. Einen Dienst auf einem separaten LAN-Host zu testen, statt die Adresse des Routers anzupingen, ist das, was klärt, ob Weiterleitung überhaupt erlaubt ist.

Einen Peer auf Dienste zu beschränken, die an die Tunneladresse gebunden sind, ist eine Frage der Eingangsrichtlinie. Erlauben Sie den gewünschten Dienst auf der Tunnelschnittstelle und beschränken Sie die Quellen, die ihn nutzen dürfen, denn das Paket kommt tatsächlich dort an.

Prüfen Sie auch Adressen, die Sie außer Betrieb nehmen wollten. Eine Adresse von einer Schnittstelle zu entfernen ist zuverlässiger, als Firewall-Regeln über eine veraltete Adresse zu stapeln.