NAT entscheet, wéi Quelladress Äre VPN-Server tatsächlech gesäit
D'Adress vun Ärem Laptop erreecht den VPN-Server ni. NAT schreift se um leschte Sprong ëm, an d'Tunnel-IP gëtt méi spéit zougewisen. Wéi Dir béid Enner vergläicht.
Dir stellt Iech vir, datt den VPN-Server d'Adress vun Ärem Laptop aus dem Paket liest an se an engem Log schreift. Wat en liest, ass wat de leschte NAT-Sprong an den äusseren Header gesat huet, an op engem Telefon deen als Hotspot benotzt gëtt ass dat dacks eng Adress, déi mat Honnerte vun aneren Abonnenten gedeelt gëtt. D'Adress vun Ärer Maschinn selwer 192.168.x.x iwwerschreift an deem Header ni den Internet, an d'Tunneladress gëtt vum Server erausginn nodeems d'Verbindung schonn opgebaut ass. Wann de Server-Log an ip addr um Laptop also net iwwerenee stëmmen, ass keent vun deenen zwee falsch; si beschreiwen ënnerschiddlech Schichte vun enger Sëtzung.
Dräi Adressen, an nëmmen eng ass am Log
D'Verwirrung entsteet doraus, datt dräi Adressen zu enger zesummegezunn ginn. Jiddereen huet en aneren Eegentemer, lieft an engem aneren Header an erreecht de Server op engem aneren Wee.
| Address | Who assigns it | Where it sits | Visible to the VPN server |
|---|---|---|---|
Device address, e.g. 192.168.1.24 | Your router via DHCP | Outer header, before translation | No, rewritten in place |
| Translated address and port | Router, ISP CGNAT, or both | Outer header, after translation | Yes, this is the tuple it logs |
Tunnel address, e.g. 10.8.0.6 | The VPN server itself | Inner header, after decapsulation | Yes, but it chose it |
Nëmmen déi mëttelst Rei ass beim Verbannen onbekannt. De Server schreift se jee no Daemon a seng Peer-Tabelle, seng Statusdatei oder säi Flow-Log: WireGuard nennt se den Endpunkt, eng OpenVPN-Statusdatei bezeechent se als Real Address, a strongSwan mellt se als deenen entfernten Host vun der IKE_SA. Dee Wäert gëtt all Kéier aktualiséiert, wann e Paket vun enger anerer Quell kënnt, also ännert en sech, ouni datt een eppes nei startet.
Déi ënnescht Rei ass dat, wat d'Leit fälschlecherweis als Identitéitsausso liesen. Si markéiert eng Plaz an der Serverkonfiguratioun, net eng Persoun, well de Server se aus sengem eegene Pool gewielt huet. Zwee Benotzer kënnen déiselwecht Tunneladress op verschiddenen Deeg kréien, an een kann der zwee vun zwou Apparater hunn.
Firwat sech den geloggten Tuple ännert, während den Tunnel steet
Adressiwwersetzung ass eng Tabell mat engem Timer, keng permanent Bindung. En Heemrouter hält seng UDP-Mapping nach eng Zäit no dem leschte Paket, en Operateur-Gateway recycléiert Porten no sengem eegene Plang, an en Telefon dee vu Wi-Fi op LTE wiesselt kënnt mat enger ganz anerer Quell zréck. D'Linux-conntrack-Standardwäerter sinn hei eng nëtzlech Mooss: nf_conntrack_udp_timeout ass 30 Sekonnen an d'Streaming-Variant ass 120, sou datt en rouegen Tunnel seng Mapping vill éischter verléiere kann, wéi de Benotzer et mierkt.
Den Tunnel iwwerlieft, well de Protokoll de Peer authentifizéiert, net d'Adress. WireGuard ass nom Handshake zoustanaustlos, also aktualiséiert all authentifizéierte Paket den gespäicherten Endpunkt an eng Neibindung heelt sech beim nächste Paket; dofir gëtt et persistent-keepalive = 25, fir d'Mapping waarm ze halen, wann et roueg ass. Den --float vun OpenVPN mécht déiselwecht Aarbecht a léisst en authentifizéierte Client vun enger neier Adress a Port weiderfueren. An de Builden 2.4 a 2.5, wou float standardméisseg aus ass, setzt eng Neibindung d'Sëtzung zréck an de Client verbënnt sech nees.
IPsec erreecht dat mat méi bewegende Deeler. IKEv2 erkennt d'Iwwersetzung andeems en d'Quell- an d'Destinatiounshashe in den NAT-Detektiounspayloaden vergläicht, wiesselt op UDP 4500-Encapsulation a follegt de Keepalives bis zum neien Tuple. Wann Keepalives blockéiert sinn, bleift d'SA um Pabeier stoen, während den Trafic an eng Richtung stëll stoppt.
Wat de Server zouschreiwe kann, a wat net
De Mythos deen et verdéngt ëmbruecht ze ginn ass, datt d'Iwwersetzung Iech virum Bedreiwer verstoppt. Si ännert de Label, net d'Observatioun. En Gateway hannert dem Carrier-NAT gesäit 100.64.0.0/10-Raum oder eng ëffentlech Adress déi vill Abonnenten deelen, a kann de Floss trotzdem mat engem Zertifikatssujet, engem WireGuard-ëffentleche Schlëssel, enger zougewisener Tunneladress, Byte-Zeiler an engem Zäitfënster verbannen. Nee vun deem brauch Är LAN-Adress.
D'Limiten lafen och an déi aner Richtung. Eng gedeelt Adress an engem Log weist op en Gateway, net op en Haushalt; zwou Sëtzungen vun der selwechter iwwersater Adress op verschiddene Porten sinn ënnerschiddlech Apparater; déiselwecht Adress op zwéin ënnerschiddlechen Deeg kënnen zwee onofhängeg Abonnente sinn, wann de Port recycléiert gouf. En Server deen nëmme Peer-Schlësselen opzeechent kann een ouni d'Kontendatebank net engem Client zouuerdnen, an en Server deen nëmmen Adressen opzeechent kann en Laptop net vun engem Telefon hannert dem selwechte Router ënnerscheeden.
Vergläicht béid Enner amplaz ze roden
Fir ze klären wat geschitt ass, hëlt déiselwecht Verbindung op béiden Enner am selwechte Moment op a vergläicht den Tuple, net d'Adress. Um Client, virun all Iwwersetzung:
ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints
Liest dann den Iwwersetzungsentrée um Router oder um CGNAT-Gateway, an dat wat schlussendlech um Server ukommt:
conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820
Dräi Mustere erklären déi meescht Ofwäichungen. De Quellport um Server ënnerscheet sech vum lokale Port, während d'Destinatioun entsprécht: gewéinlech Portiwwersetzung. D'Quelladress um Server gehéiert zu engem ISP-Block deen net Ären ass: op d'mannst eng zousätzlech NAT-Schicht. D'Pakete stoppen no enger Rouphase a fuere mat engem neie Port weider: d'Mapping ass ofgelaf, net en Routingsfehler. Wann d'Zäitstempel méi wéi eng oder zwou Sekonnen ausernee leien, vergläicht Dir zwou verschidden Versich.
Wou den Ënnerscheed Saachen zerbricht
Ënnerbriechungen déi wéi Serverfehler ausgesinn fänken normalerweis hei un. Eng Zougrëffsregel déi un Är Heemadress gebonne gouf fällt aus, nodeems sech den ISP-Lease ännert. Eng fail2ban-Regel déi op eng iwwersate Adress passt späert all Abonnenten hannert deem Gateway op eemol. En Site-zu-Site-Peer mat enger fixer entfernter Adress hält op d'Schlësselen z'erneieren, nodeems sech eng mobil Verbindung ännert. Den Tunnelprotokoll war an der Rei; d'Annam vum äusseren Tuple net.
Déiselwecht Verwirrung weist sech op der Serversäit. Wann d'VPN-Këscht selwer hannert NAT steet, braucht Dir eng Portforwarding an en funktionéierende Weiderleitungspad; de strongSwan-Weiderleitungsguide deckt dee Fall fir IPsec of. En Server deen nëmmen iwwer eng privat Adress erreechbar ass gesäit den iwwersaten Tuple vun senge Clienten ni, an dat ass en anere Problem wéi iwwersate Clienten.
Maacht dës véier Kontrollen an der Rei an hält bei der éischter déi feelt:
- Hëlt op béiden Enner gläichzäiteg op; bestätegt datt Quellport, Destinatiounsport an Zäitstempel iwwerenee stëmmen.
- Liest an der Peer-Lëscht vum Server d'Adress déi en aktuell huet, net déi Dir erwaart hutt.
- Préift d'conntrack- oder NAT-Tabell fir den Entrée a seng verbleiwen Liewensdauer.
- Bestätegt datt d'Adress vum Tunnelinterface um Client mat där vum Server zougewisener iwwerenee stëmmt, net mat der LAN-Adress.
Wann béid Opname um Tuple iwwerenee stëmmen an den Tunnel nach ëmmer feelt, ass d'Iwwersetzung net Äre Problem; geet weider zum Handshake an zu der Routingtabell am Tunnel.