Die Antwort verlässt das LAN, nicht den Tunnel: warum und wie

Ein über ein Gateway veröffentlichter Dienst funktioniert aus dem größten Teil des Internets und scheitert aus einem Büro. Jemand prüft den Tunnel, sieht die Anfrage ankommen und schließt daraus, dass die Antwort denselben Weg zurücknehmen muss. Linux funktioniert nicht so, und keine noch so gründliche Untersuchung des Tunnels ändert die Antwort. Die Antwort wird nach Ziel geroutet, und dieser eine fehlschlagende Aufrufer sitzt in einem Subnetz, das der Host bereits direkt erreicht.

Was ein ausgehendes Paket tatsächlich entscheidet

Der Kernel sucht eine Route für das Ziel des Pakets, konsultiert Policy-Regeln in Prioritätsreihenfolge und dann die Tabelle, die eine passende Regel auswählt. Die Schnittstelle, auf der ein Paket ankam, spielt keine Rolle, es sei denn, eine Regel oder eine Markierung wurde geschrieben, um sie relevant zu machen. Das ist eine Routing-Tatsache über diesen Host, kein Fehler im Tunnel.

Eine über den Tunnel empfangene Anfrage kann daher eine Antwort erzeugen, die über die physische Schnittstelle hinausgeht, und der Fluss wird einseitig, ohne dass irgendein Gerät einen Fehler meldet. Prüfen Sie beide Richtungen, bevor Sie eine Schlussfolgerung über den Tunnel ziehen. Eine Antwort, die den falschen Weg nimmt, verschwindet aus den Tunnelzählern, weshalb die beiden Seiten uneins darüber sind, ob etwas gesendet wurde. Achten Sie darauf, welcher Zähler sich bewegt hat, bevor Sie eine Regel anfassen.

Warum das lokale Subnetz gewinnt

Ein Host mit einer Adresse in einem lokalen Netz hat in der Haupttabelle eine verbundene Route für dieses Präfix, und eine verbundene Route ist eine direkte Übereinstimmung. Wenn der Aufrufer aus demselben Subnetz kommt, findet die Suche die lokale Verbindung, bevor der Tunnel überhaupt in Betracht gezogen wird.

Gerade die Asymmetrie macht die Diagnose verwirrend. Aufrufer aus dem weiteren Internet funktionieren, weil sie auf keine lokale Route passen, während der eine Aufrufer, der das Büro-Präfix teilt, scheitert, und genau dieser Aufrufer ist der, mit dem jemand testet.

Peer-Abdeckung ist nicht dasselbe wie installierte Routen

Auf der Tunnelseite beschreiben die erlaubten Bereiche eines Peers, was in den Tunnel gesendet werden darf und welche Quellen daraus akzeptiert werden. Sie sagen nichts darüber, wohin die lokale Routing-Tabelle ein Paket senden wird.

Wenn das Tunnelwerkzeug eine Standardroute auf dem Host installiert, kann es fremden Verkehr als Kollateralschaden in den Tunnel ziehen. Wo stattdessen eine Policy-Regel die Entscheidung tragen sollte, existiert die Option zur Routeninstallation genau, um das zu verhindern, und die Adressen, Schlüssel und Endpunkt-Einstellungen bleiben exakt wie sie waren. Eine aus Bequemlichkeit hinzugefügte Standardroute ist ein häufiger Weg, auf dem ein Host sein eigenes lokales Netz verliert.

Wählen Sie die Tabelle nach der Quelladresse

Eine quellenbasierte Regel schickt Antworten von der Dienstadresse in eine private Tabelle, deren Standard der Tunnel ist, während alles andere weiter die Haupttabelle verwendet. Wählen Sie Tabellen- und Prioritätsnummern, die lokal unbenutzt sind, und lesen Sie die vorhandenen Regeln, bevor Sie etwas einfügen. Lesen Sie die laufenden Regeln statt einer gespeicherten Datei, denn die beiden können sich nach einem Neustart unterscheiden.

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

Die letzte Zeile lässt eine fehlende Route sichtbar scheitern, statt auf die lokale Verbindung zurückzufallen. Die Quelle muss dem Host wirklich zugewiesen sein, und die gewöhnlichen lokalen und Haupt-Suchen müssen an ihren früheren Positionen bleiben. Die Regel wählt eine Tabelle nach Quelle; sie vergleicht keine Präfixlängen zwischen Tabellen.

Bestätigen Sie den Pfad, dann den Dienst

Fragen Sie den Kernel, was er tun würde, statt aus einem Mitschnitt zu schließen, und verwenden Sie die Dienstadresse als Quellenselektor. Eine falsche Antwort hier spart eine ganze Paketverfolgung.

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

Die Ausgabe sollte den Tunnel nennen. Testen Sie dann eine Quelle, die Sie nicht angefasst haben, und bestätigen Sie, dass sie noch die lokale Verbindung nimmt, sodass die Änderung auf eine Adresse beschränkt blieb. Ein breiterer Selektor würde nichts über die ursprüngliche Beschwerde beweisen.

Was das nicht behebt

Lassen Sie Weiterleitung, Firewall-Regeln und ICMPv6-Verhalten am Gateway so, wie sie waren, denn eine Quellenroute ersetzt keines davon. Eine fehlende Packet-Too-Big-Nachricht bricht weiterhin große Antworten, egal welche Tabelle die Suche gewonnen hat. Beheben Sie das, bevor Sie Routing-Regeln hinzufügen, sonst überlebt das Symptom die Änderung.

Bestätigen Sie das Veröffentlichungsmodell, bevor Sie irgendetwas davon anwenden. Ein Reverse-Proxy, der seine eigene Backend-Verbindung öffnet, präsentiert seine eigene Quelle und bewahrt den Aufrufer nicht, daher kann dieser Fehler in diesem Design nicht auftreten. Die Regel dort anzuwenden würde eine Routing-Ausnahme hinzufügen, die nichts löst und die eigentliche Ursache verbirgt.

Schreiben Sie schließlich die Regelnummern und die Tabelle in die Konfigurationsverwaltung des Hosts. Eine von Hand hinzugefügte Policy-Regel verschwindet beim nächsten Neuaufbau, und der Büro-Aufrufer kommt mit derselben Beschwerde zurück.