Verschachteltes WireGuard: der mittlere Hop kann seinen eigenen Port nicht beantworten
Wenn der mittlere Hop alles in einen Tunnel schickt, verlassen Antworten auf seinen eingehenden Dienst den falschen Weg. Eine Quellport-Regel am Interface behebt das.
Drei WireGuard-Hops erreichen ein Netz ohne öffentliche Adresse, und dann antwortet die mittlere Maschine nicht mehr auf dem Port, auf dem sie lauschen sollte. Der Tunnel weiter funktioniert noch, der entfernte Host reagiert noch, und nur der mittlere Server selbst ist von außen verstummt. Diese Kombination ist gerade deshalb verwirrend, weil sie selbst verursacht ist: der mittlere Hop folgt seiner eigenen Routing-Tabelle, und die Tabelle schickt seine Antworten den falschen Weg.
Eine Kette, die funktioniert, bis man mit der mittleren Kiste spricht
Nehmen Sie eine illustrative Kette: Client A erreicht Server B auf UDP 500, und B geht weiter zu Server C auf UDP 500. C akzeptiert Verkehr nur von der Adresse seines einzigen Peers, was es zu einem Blatt macht und sein Verhalten einfach hält. B ist kein Blatt, und alles Interessante an diesem Fehler passiert dort.
Der Unterschied ist wichtig, weil Blatt- und Mittelrolle in entgegengesetzte Richtungen ziehen. Ein Blatt kann alles in einen Tunnel schicken, ohne Folgen, da nichts anderes davon abhängt. Ein mittlerer Hop ist gleichzeitig Endpunkt für Clients und Client zur fernen Seite, und diese beiden Aufgaben wollen unterschiedliches Routing.
Warum die Antwort durch den Tunnel hinausgeht
Auf B trägt das Interface Richtung C AllowedIPs = 0.0.0.0/0 zusammen mit der passenden Standardroute. Jedes Paket, das B erzeugt, geht daher in diesen Tunnel, es sei denn, etwas Spezifischeres hat Vorrang.
Ein Paket von A an B kommt an und wird akzeptiert, weil B das Ziel ist und lokale Zustellung zuerst geschieht. Die Antwort ist ein brandneues lokal erzeugtes Paket an die öffentliche Adresse von A, und dieses Ziel passt zur Standardroute in den Tunnel. C empfängt es, besitzt diese Adresse nicht und verwirft es.
Das Symptom liest sich wie ein Firewall-Problem oder eine Schlüsselabweichung, und beides stimmt hier nicht. Ein Mitschnitt am Tunnel Richtung C zeigt die Antworten in die falsche Richtung laufen. Diese eine Beobachtung spart mehr Zeit als jede Menge Lesen von Konfiguration, also schreiben Sie sie auf, bevor Sie Schlüssel ändern. Wer den Mitschnitt nicht gesehen hat, wird annehmen, der Tunnel selbst sei kaputt.
Die schmale Reparatur: Policy-Regeln, die auf einen Quellport passen
Antworten aus Bs lauschendem Socket verlassen ihn mit Quellport 500. Eine Policy-Regel kann darauf passen und diese Pakete zurück in die gewöhnliche Tabelle leiten:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101Policy-Regeln werden in Prioritätsreihenfolge geprüft, und die Haupttabelle liegt bei 32766, eine Regel bei 100 wird also gefragt, bevor die Standardroute des Tunnels etwas zu sagen hat. Fügen Sie einen Eintrag pro Port hinzu, der von außen erreichbar bleiben muss, und nichts weiter, damit weitergeleiteter Verkehr den Tunnel weiter nutzt, für den er gebaut wurde.
Kennen Sie die Grenze dieses Tricks. Der Selektor sport passt auf lokal erzeugte Pakete, was genau den Antwortfall abdeckt und bewusst keinen Verkehr abdeckt, den B lediglich für jemand anderen weiterleitet. Ein hinter B gehosteter Dienst braucht weiterhin seine eigene Antwort, und das Gegenteil vorzugeben erzeugt eine Lösung, die für den ersten Dienst funktioniert und für den zweiten scheitert.
Geben Sie der Regel einen Eigentümer
Eine an einer Eingabeaufforderung getippte Regel verschwindet beim nächsten Neuaufbau des Interfaces. Setzen Sie sie in einer WireGuard-Konfiguration dorthin, wo das Interface erstellt und entfernt wird:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100Wenn NetworkManager, ein Distributions-Hook oder ein Container-Einstiegspunkt das Interface besitzt, gehört das Paar zu diesem Eigentümer statt in eine handbearbeitete Datei. Prüfen Sie die wirksamen Regeln nach einer Neuverbindung, nicht nur nach dem ersten Start, denn der erste Start ist der Fall, der immer funktioniert.
Vergleichen Sie die Alternativen ehrlich
Die Quellport-Regel ist einer von vier Auswegen und der engste davon. Sie hat den Vorteil, die Tunnel-Policy überhaupt nicht anzutasten, weshalb sie spätere Änderungen meist überlebt. Enge Korrekturen scheitern auch laut, wenn sie nicht mehr greifen, während eine breite Ausnahme still weiterläuft, lange nachdem der Grund dafür verschwunden ist. Dieser Unterschied zählt mehr als Eleganz, wenn in zwei Jahren jemand anderes die Kiste besitzt.
| Approach | What it costs | Where it breaks |
|---|---|---|
| Source-port policy rule | One rule per exposed port | Anything B forwards rather than originates |
| Destination exception route | A route pinned to specific client addresses | Clients whose address changes |
| Stop full-tunnelling on B | Loses the catch-all path toward C | Designs that depend on it |
| Split into two tunnels | More interfaces and more policy | Nothing, at the cost of complexity |
Prüfen Sie nach der Wahl von beiden Enden aus. Starten Sie von A eine Verbindung zum Port von B und halten Sie sie eine Weile beschäftigt. Lassen Sie auf B den Kernel den Antwortpfad mit etwas wie ip route get <address-of-A> sport 500 begründen, und bestätigen Sie, dass er das WAN-Interface und nicht den Tunnel nennt. Prüfen Sie danach, dass etwas hinter C noch durch die Kette antwortet, was belegt, dass die Ausnahme schmal blieb, statt zu einem Bypass zu werden. Zuletzt halten Sie die Ports in den Designnotizen fest, sonst entdeckt der nächste Betreiber dies bei einem anderen Dienst neu.