Portweiterleitung gegen VPN-Zugang: wohin das Paket wirklich geht

Eine Portweiterleitung schreibt das Ziel um und hört dort auf; ein VPN packt das Paket zuerst ein. Sehen Sie, welche Schicht jeweils geändert wird und was das für HTTPS bedeutet.

Zwei Entwürfe, eine HTTPS-Anwendung, und das Paket nimmt in jedem einen anderen Weg. Eine Portweiterleitung ändert, wohin das Paket geliefert wird, und lässt den Rest unangetastet. Ein VPN trägt dieses Paket zuerst in einem anderen Paket, sodass der Listener der Anwendung eine andere Quelle und eine kleinere maximale Nutzlast sieht. Die Verschlüsselung, über die gestritten wird, ist in beiden Fällen vorhanden, weil die Anwendung weiterhin HTTPS ist; unterschiedlich ist, wer eine Verbindung öffnen darf und was das Netz dazwischen beobachten kann. Diese Unterscheidung entscheidet die meisten praktischen Fragen.

Die DNAT-Regel schreibt das Ziel um und hört dort auf

Auf einem Linux-Gateway bedeutet das Veröffentlichen eines Dienstes eine Regel in der PREROUTING-Kette der nat-Tabelle oder das Äquivalent in nftables. Die Regel passt auf die öffentliche Adresse und den Port und schreibt dann das Ziel auf die private Adresse der Anwendung um. Quelladresse, Quellport und Nutzlast bleiben unberührt, und conntrack zeichnet die Zuordnung auf, damit Antworten beim Hinausgehen zurückgeschrieben werden. Das Verhalten ist das traditionelle Adressübersetzungsmodell aus RFC 3022.

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

Der Listener der Anwendung erfährt nie, dass die Verbindung über eine Übersetzung ankam. Er sieht die echte Quelladresse des Clients, was für Zugriffsprotokolle und Ratenbegrenzungen nützlich ist, und antwortet an die private Adresse, weil conntrack die Zuordnung umkehrt. Nichts auf diesem Weg entschlüsselt oder verschlüsselt erneut: TLS läuft weiterhin zwischen dem Client und dem eigenen Zertifikat der Anwendung.

Die Regel legt auch die Fehlermodi fest, die Ihnen später begegnen. Wenn das Gateway weiterleitet, aber der Host der Anwendung keine Route zurück zum Client hat, gehen Antworten mit falscher Quelle hinaus, und der Handshake bleibt stehen. Wenn eine zweite Regel zuerst passt, entscheidet die Reihenfolge, und iptables -t nat -L -n -v zeigt die Zähler, die beweisen, welche Regel das Paket genommen hat.

Der Tunnel packt das Paket ein, bevor der Listener es sieht

Ein VPN veröffentlicht die Anwendung überhaupt nicht. Der Client baut ein äußeres Paket an die öffentliche Adresse des Gateways, verschlüsselt das innere Paket darin, und das Gateway entschlüsselt und leitet das innere Paket an das private Ziel. Bei WireGuard ist der äußere Transport UDP, meist auf einem hohen Port; bei OpenVPN über TCP 443 sieht das äußere Paket für alles, was den Weg beobachtet, wie TLS aus.

Im Tunnel behält das innere Paket private Adressen: die Tunneladresse des Clients, sagen wir 10.8.0.6, und die Anwendung unter 10.20.30.40. Der Listener sieht daher eine Quelle aus dem Tunnelpool, und jeder Client teilt dieses Gateway als nächsten Hop. Zugriffsprotokolle hinter einem VPN zeigen aus genau diesem Grund oft das Gateway statt des Benutzers, sofern das Gateway nicht die ursprüngliche Quelle bewahrt.

Das Einpacken kostet Header-Platz, und das ist der einzige Unterschied auf Mechanismenebene mit einer messbaren Folge. Ein äußerer IP-Header plus UDP plus WireGuards eigener Header zehren am MTU des Pfads, also müssen große Pakete fragmentiert werden oder der innere TCP-Stack muss sein MSS begrenzen. Eine Übertragung, die über den weitergeleiteten Pfad funktioniert, kann über dem Tunnel stocken, wenn eine Zwischenstation das ICMP verwirft, das den kleineren MTU signalisiert hätte.

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Die Exposition entscheidet sich am Eingang, nicht an der Chiffre

Beide Entwürfe enden am selben TLS-Listener, also erben beide dasselbe Zertifikat, dieselben Protokollversionen und dieselbe Anmeldefunktion. Geändert wird, wer einen Handshake beginnen darf. Bei einer öffentlichen Weiterleitung erhält jeder Host, der 203.0.113.10:443 erreicht, einen TCP-Handshake und ein TLS ClientHello, bevor die Autorisierung Ihrer Anwendung überhaupt geprüft wird. Bei reinem Tunnelzugang ist der Listener nur von Adressen erreichbar, die das Gateway in den Tunnel routet, und das SYN eines Fremden stirbt an der Gateway-Richtlinie.

Dieser Unterschied betrifft die Erreichbarkeit, nicht die Vertraulichkeit. Ein weitergeleiteter HTTPS-Dienst ist kein Klartext, und ein VPN beseitigt nicht die Notwendigkeit der Anwendungsauthentifizierung: Die Tunnelaufnahme beantwortet, ob ein Gerät Pakete in dieses Netz senden darf, während die Dateianwendung beantwortet, ob ein Benutzer ein Dokument lesen darf. Beides zu verwechseln, führt dazu, dass Teams ein VPN haben, das das ganze LAN freigibt, und eine Anwendung mit einem gemeinsamen Passwort.

Prüfen Sie Listener und Richtlinie getrennt, denn jedes von beiden kann weiter sein, als Sie annehmen:

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

Wenn ss zeigt, dass der Listener an 0.0.0.0 gebunden ist, ist die Anwendung von überall erreichbar, wo Routing und Firewall-Richtlinie es zulassen, und die Weiterleitung ist nur einer der Wege hinein. Die Bindung an die private Adresse oder die Einschränkung des Quellbereichs in der Firewall ist eine vom VPN getrennte Entscheidung, und sie ist die Entscheidung, die die Exposition tatsächlich verringert.

Messen Sie den Pfad, nicht das Etikett

Wenn jemand behauptet, die Weiterleitung sei schneller, hält der ehrliche Vergleich alles andere konstant: derselbe Client, dasselbe Zugangsnetz, dieselbe Datei, dieselbe TLS-Konfiguration, derselbe Anwendungshost. Führen Sie die Übertragung zweimal pro Pfad aus und notieren Sie Gesamtzeit, Fehleranzahl und Reaktionsfähigkeit, nicht die Ausgabe eines unabhängigen Geschwindigkeitstests.

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

Diese Zahlen trennen den Verbindungsaufbau von der Übertragungszeit, was wichtig ist, weil sich die beiden Pfade meist in der Umlaufzeit und im MTU unterscheiden, nicht in den Chiffrierkosten. TLS-Arbeit findet in beiden Entwürfen an den Endpunkten statt, und ein Tunnel fügt Kapselung, eine andere Route und möglicherweise ein stärker belastetes Gateway hinzu. Ist der Tunnelpfad länger oder sein Gateway ausgelastet, gehört der Unterschied zum Pfad und nicht zum Wort Verschlüsselung.

Wählen Sie die Eingangsrichtlinie, die der Dienst tatsächlich braucht, und entscheiden Sie dann, ob ein gemessener Unterschied es rechtfertigt, sie zu ändern. Eine öffentliche Weiterleitung passt zu einem Dienst für das offene Internet, mit Quellbeschränkungen, aktuellem TLS und Überwachung davor. Reiner Tunnelzugang passt zu einem internen Werkzeug, dessen Benutzer bereits registriert sind, sofern Gateway-Routing und Anwendungsberechtigungen beide enger als das gesamte LAN sind.

Bevor Sie das Design als fertig bezeichnen, bestätigen Sie vier Dinge: an welche Adresse der Listener gebunden ist, welche Regel oder Route das Paket hereinnimmt, ob der Rückweg von der echten Client-Adresse funktioniert und ob große Nutzlasten den MTU überstehen. Für jedes davon gibt es oben einen Befehl, und keines wird durch das Wort sicher oder durch ein Bandbreitendiagramm beantwortet.

Ähnliche Artikel