Portforwarding géint VPN-Zougang: wou de Paket wierklech hinnergeet

E Portforwarding schreift d'Zil ëm a stoppt do; eng VPN packt de Paket als éischt an. Kuckt wéi eng Schicht jiddweree ännert a wat dat fir HTTPS bedeit.

Zwou Designen, eng HTTPS-Applikatioun, an de Paket hëlt an all enger aneren Wee. E Portforwarding ännert, wou de Paket geliwwert gëtt, an léisst de Rescht onberéiert. Eng VPN dréit dee Paket als éischt an engem aneren Paket, sou datt de Listener vun der Applikatioun eng aner Quell an eng méi kleng maximal Notzlaascht gesäit. D'Verschlësselung, iwwer déi d'Leit diskutéieren, ass a béide Fäll dobäi, well d'Applikatioun nach ëmmer HTTPS ass; wat sech ënnerscheet, ass wien eng Verbindung opmaache kann a wat den Netz dertëschent observéiere kann. Dee Ënnerscheed entscheet déi meescht praktesch Froen.

D'DNAT-Reeg schreift d'Zil ëm a stoppt do

Op engem Linux-Gateway heescht e Service publizéieren eng Reeg an der PREROUTING-Kette vun der nat-Tabelle, oder dat Gläichwäertegtes an nftables. D'Reeg passt op déi ëffentlech Adress an de Port an schreift dann d'Zil op déi privat Adress vun der Applikatioun ëm. Quelladress, Quellport an Notzlaascht bleiwen onberéiert, an conntrack registréiert d'Mapéierung, sou datt Äntwerten um Ausgang zeréckgeschriwwe ginn. D'Verhalen ass dat traditionellt Adressiwwersetzungsmodell, dat an RFC 3022 beschriwwe gëtt.

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

De Listener vun der Applikatioun léiert ni, datt d'Verbindung duerch eng Iwwersetzung ukomm ass. Hie gesäit déi richteg Quelladress vum Client, wat nëtzlech fir Zougangslogs a Geschwindigkeitslimite ass, an hie äntwert op déi privat Adress, well conntrack d'Mapéierung ëmdréit. Näischt op deem Wee decryptéiert oder verschlësselt nei: TLS leeft nach ëmmer tëscht dem Client an dem Applikatiouns-eegene Zertifikat.

D'Reeg bestëmmt och d'Feelermodusen, déi Dir méi spéit begéint. Wann de Gateway weiderleet, awer den Host vun der Applikatioun kee Wee zréck zum Client huet, ginn d'Äntwerten mat der falscher Quell eraus an den Handshake stockt. Wann eng zweet Reeg als éischt passt, entscheet d'Reiefolleg d'Resultat, an iptables -t nat -L -n -v weist d'Zieler, déi beweisen, wéi eng Reeg de Paket geholl huet.

Den Tunnel packt de Paket an, ier de Listener en gesäit

Eng VPN publizéiert d'Applikatioun guer net. De Client baut en äusseren Paket, deen op d'ëffentlech Adress vum Gateway adresséiert ass, verschlësselt de bannenzege Paket dobannen, an de Gateway decryptéiert a routet de bannenzege Paket op dat privat Zil. Bei WireGuard ass den äusseren Transport UDP, meeschtens op engem héije Port; bei OpenVPN iwwer TCP 443 gesäit den äusseren Paket aus wéi TLS fir alles, wat de Wee observéiert.

Bannen am Tunnel behält de bannenzege Paket privat Adressen: d'Tunneladress vum Client, sot 10.8.0.6, an d'Applikatioun op 10.20.30.40. Den Listener gesäit dofir eng Quell aus dem Tunnelpool, an all Client deelt dee Gateway als nächsten Hop. Zougangslogs hannert enger VPN weisen dacks de Gateway amplaz vum Benotzer genee aus dësem Grond, ausser de Gateway conservéiert déi ursprénglech Quell.

D'Anpacke kascht Header-Plaz, an dat ass den eenzegen Ënnerscheed op Mechanismen-Niveau mat enger moossbarer Konsequenz. En äusseren IP-Header plus UDP plus dem WireGuard säin eegenen Header iessen vum MTU vum Wee, dofir mussen grouss Pakete fragmentéiert ginn oder de bannenzegen TCP-Stack muss säi MSS begrenzen. En Transfert, deen um weidergeluechten Wee funktionéiert, kann um Tunnel stocken, wann en Zwëschegerät deen ICMP verwërft, deen dee méi klenge MTU gemellt hätt.

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

D'Expositioun entscheet sech um Agang, net duerch de Chiffer

Béid Designen enden um selwechten TLS-Listener, also ierwen béid dat selwecht Zertifikat, déi selwecht Protokollversiounen an de selwechte Applikatiounslogin. Wat sech ännert, ass wien en Handshake däerf ufänken. Bei enger ëffentlecher Weiderleitung kritt all Host, deen 203.0.113.10:443 erreecht, en TCP-Handshake an en TLS ClientHello, ier Är Applikatiounsautorisatioun iwwerhaapt gekuckt gëtt. Bei Zougang nëmmen iwwer den Tunnel ass de Listener nëmme vun Adressen erreechbar, déi de Gateway an den Tunnel routet, an de SYN vun engem Frieme stierft un der Gateway-Politik.

Dee Ënnerscheed geet ëm d'Erreechbarkeet, net ëm d'Vertraulechkeet. En weidergeluechten HTTPS-Service ass keen einfachen Text, an eng VPN hëlt net d'Notwendegkeet vun der Applikatiounsauthentifizéierung ewech: den Tunnelufank äntwert, ob en Apparat Pakete kann an dëst Netz schécken, wärend d'Dateiapplikatioun äntwert, ob e Benotzer en Dokument däerf liesen. Béides ze verwiesselen ass de Wee, wéi Teamen zu enger VPN kommen, déi de ganzen LAN gëtt, an enger Applikatioun mat engem eenzegen gedeelte Passwuert.

Ënnersicht de Listener an d'Politik getrennt, well jiddweree vun béiden méi breet ka sinn, wéi Dir unhëlt:

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

Wann ss weist, datt de Listener un 0.0.0.0 gebonnen ass, ass d'Applikatioun vun iwwerall erreechbar, wou Routing a Firewallpolitik et erlaben, an d'Weiderleitung ass nëmmen ee vun de Weeër eran. Un déi privat Adress bannen, oder de Quellberäich an der Firewall aschränken, ass eng Entscheedung getrennt vun der Wiel vun enger VPN, an et ass déi Entscheedung, déi d'Expositioun wierklech verklengert.

Moosst de Wee, net d'Etikett

Wann een behaapt, d'Weiderleitung sief méi séier, hält den éierleche Verglach alles anescht konstant: dee selwechte Client, dee selwechten Zougangsnetz, déi selwecht Datei, déi selwecht TLS-Konfiguratioun, dee selwechten Applikatiounshost. Loosst den Transfert zweemol pro Wee lafen a notéiert Gesamtzäit, Zuel vun de Feeler a Reaktionsfäegkeet, net d'Ausgab vun engem onverbonnene Geschwindigkeitstest.

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

Dës Zuelen trennen de Verbindungsopbau vun der Transferzäit, wat wichteg ass, well sech déi zwee Weeër meeschtens an der Ëmlafzäit an am MTU ënnerscheeden, net am Chifferkäschtepunkt. TLS-Aarbecht geschitt a béiden Designen un den Endpunkten, an en Tunnel bäit Inkapselung, en aneren Itinéraire an eventuell en méi beschäftegte Gateway derbäi. Wann den Tunnelwee méi laang ass oder säi Gateway ausgelaaft ass, gehéiert den Ënnerscheed zum Wee an net zum Wuert Verschlësselung.

Wielt d'Agangspolitik, déi de Service wierklech brauch, a decidéiert dann, ob en gemoossenen Ënnerscheed et rechtfäerdeg, se z'änneren. Eng ëffentlech Weiderleitung passt zu engem Service fir den oppenen Internet, mat Quellaschränkungen, aktuellem TLS an Iwwerwaachung virdrun. Zougang nëmmen iwwer den Tunnel passt zu engem internen Instrument, deem seng Benotzer schonn ageschriwwe sinn, ugeholl datt de Gateway-Routing an d'Applikatiounsberechtegungen allebéid méi schmuel wéi de ganzen LAN sinn.

Ier Dir den Design als fäerdeg bezeechent, bestätegt véier Saachen: un wéi eng Adress de Listener gebonnen ass, wéi eng Reeg oder Route de Paket eraleesst, ob de Wee zréck vun der richteger Clientadress funktionéiert, an ob grouss Notzlaaschte vum MTU iwwerliewen. Jiddweree vun dësen huet uewen eng Kommando, an keen gëtt duerch d'Wort sécher oder duerch eng Bandbreetdiagramm beäntwert.

Ähnlech Artikelen