Feste UDP-Ports können Portweiterleitung überspringen, aber nicht jedes NAT

Eine zustandsbehaftete Firewall lässt das Paket des Peers als Rückverkehr durch, wenn beide Enden einen Port festnageln. Hier steht, wann das klappt und was es still beendet.

Zwei Heimrouter, keine weitergeleiteten Ports und ein VPN, das sich trotzdem manchmal verbindet. UDP erlaubt das, weil eine Firewall ein Paket durchlässt, das sie mit einem Fluss abgleichen kann, den der Rechner bereits begonnen hat. Es ist ein bedingter Trick und keine Funktion, und die Bedingungen lassen sich leicht nennen, sobald man weiß, was die Firewall vergleicht. Sie sind auch der Grund, warum identische Profile in verschiedenen Netzen unterschiedlich reagieren.

Der Vergleich, den eine Firewall anstellt

Jedes ausgehende Datagramm legt einen kurzlebigen Eintrag an: Quelladresse, Quellport, Zieladresse, Zielport. Alles, was ankommt und zum Eintrag passt, gilt als Antwort und wird durchgelassen. Regeln für eingehenden Verkehr spielen keine Rolle.

Die Frage ist also nicht, ob die Firewall den Peer hereinlässt. Sie ist, ob das Paket des Peers wie die Antwort aussieht, auf die der Eintrag wartet. Ändert man ein Feld dieses vierteiligen Tupels, wird das Paket ein Fremder. Deshalb kann eine funktionierende Einrichtung brechen, wenn sich nur die Portnummer ändert, und deshalb kann derselbe Port auf einem Router funktionieren und auf dem nächsten scheitern.

Fixiert man den lokalen Quellport, erscheint dieselbe Nummer auf beiden Seiten des Austauschs. Das ist der ganze Mechanismus, und er erklärt, warum der Trick zerbrechlich statt rätselhaft ist.

Einen Port an jedem Ende festnageln

OpenVPNs Standard-UDP-Port ist 1194, und lport legt den Quellport fest, von dem aus gesendet wird. Nagelt beide Peers fest, und das ausgehende Tupel jedes Peers zeigt auf einen Port, auf dem der andere lauscht:

# peer A
lport 1194
remote 198.51.100.20 1194
# peer B
lport 1194
remote 203.0.113.10 1194

Das funktioniert nur, solange kein Router dazwischen den Quellport umschreibt. Wenn Pakete in einem Mitschnitt auftauchen, aber kein Tunnel zustande kommt, ist das Umschreiben der erste Verdächtige.

Wo das Tupel nicht mehr passt

Ein NAT, das pro Ziel abbildet, gibt jedem Peer einen anderen externen Port. Die Adresse, die deinem Peer genannt wurde, ist nicht die Adresse, die ihn erreicht, also passt das eingehende Paket auf nichts und wird still verworfen.

Carrier-Grade-Übersetzung, gestapeltes NAT und Portrandomisierung enden alle gleich. Ebenso jede Middlebox, die Ports umschreibt und Adressen in Ruhe lässt.

Bei Stream-Transporten ist es schlimmer. Ein TCP-Handshake wird Schritt für Schritt verfolgt, also lässt sich ein TCP-basiertes VPN so überhaupt nicht durchstoßen und braucht irgendwo auf dem Pfad einen Listener.

Meist scheitert zuerst eine Seite

In der Praxis verhalten sich die beiden Netze selten gleich. Ein Router gibt vielleicht eine vorhersagbare Abbildung aus, während der andere Ports pro Ziel vergibt, und das Ergebnis ist eine Konfiguration, die zwischen zwei Haushalten funktioniert und aus einem Mobilfunknetz scheitert. Berichte, die sich widersprechen, beschreiben meist zwei verschiedene Routerpaare. Keiner der Autoren irrt, und keines der Ergebnisse lässt sich verallgemeinern.

Finde heraus, welche Seite das Paket verworfen hat, bevor du die Profile anfasst. Mitschnitte an beiden Enden klären das in einem Versuch: Datagramme, die A verlassen und B nie erreichen, bedeuten, dass der Fluss unterwegs umgeschrieben wurde, während Datagramme, die bei B ankommen, ohne dass eine Antwort zurückkommt, bedeuten, dass die Firewall sie nicht als zugehörig akzeptiert hat.

Zwei Peers mit öffentlichen IPv6-Adressen umgehen das ganze Problem. Ohne Übersetzung gibt es nichts abzugleichen, also genügt eine Firewallregel, die die Peers benennt, und das Design hängt nicht mehr vom Routerverhalten ab.

Wann man aufhören sollte

Ein Host mit öffentlicher Adresse ist die verlässliche Antwort. Er kann den Tunnel für beide Peers beenden oder ihnen einfach helfen, die aktuelle externe Adresse des anderen zu ermitteln, und beide Anordnungen funktionieren, egal was die NATs tun. Ein verwaltetes Overlay bietet dieselbe Koordination, wenn die Richtlinie es zulässt.

Nichts davon braucht eine abgeschaltete Firewall. Den Schutz abzuschalten, um die direkte Verbindung zu gewinnen, verwirft den Grund, warum der direkte Versuch attraktiv war, und lässt den Rechner für die Dauer des Tests offen.

Probiere zuerst die direkte Anordnung und notiere dann, was du gesehen hast. Das NAT-Verhalten und der Mitschnitt, der es zeigte, sind mehr wert als das Portpaar, bei dem du gelandet bist, denn das nächste Netz wird anders sein. Das OpenVPN-2.6-Handbuch dokumentiert lport und die remote-Optionen, von denen das abhängt.

Ähnliche Artikel