NAT bepaal watter bronadres jou VPN-bediener werklik sien

Jy stel jou voor dat die VPN-bediener jou skootrekenaar se adres van die pakket af lees en in 'n log skryf. Wat dit lees, is wat die laaste NAT-sprong in die buitenste kop gesit het, en op 'n telefoon wat as hotspot dien is dit dikwels 'n adres wat met honderde ander intekenare gedeel word. Jou masjien se eie 192.168.x.x steek nooit in daardie kop oor die internet nie, en die tonneladres word deur die bediener uitgedeel nadat die verbinding reeds op is. As 'n bedienerlog en ip addr op die skootrekenaar dus van mekaar verskil, is nie een verkeerd nie; hulle beskryf verskillende lae van een sessie.

Drie adresse, en net een daarvan is in die log

Die verwarring kom daaruit dat drie adresse in een saamgevat word. Elkeen het 'n ander eienaar, woon in 'n ander kop en bereik die bediener langs 'n ander pad.

Net die middelste ry is onbekend op die oomblik van koppel. Die bediener skryf dit in sy eweknie-tabel, statuslêer of vloeilog, afhangende van die daemon: WireGuard noem dit die eindpunt, 'n OpenVPN-statuslêer noem dit Real Address, en strongSwan rapporteer dit as die afgeleë gasheer van die IKE_SA. Daardie waarde word verfris wanneer 'n pakket van 'n ander bron aankom, so dit verander sonder dat iemand enigiets herbegin.

Die onderste ry is wat mense verkeerdelik as 'n identiteitsbewering lees. Dit merk 'n plek in die bedienerkonfigurasie, nie 'n persoon nie, want die bediener het dit uit sy eie poel gekies. Twee gebruikers kan op verskillende dae dieselfde tonneladres kry, en een kan twee daarvan van twee toestelle af hou.

Waarom die gelogde tupel verander terwyl die tonnel bly staan

Adresvertaling is 'n tabel met 'n tydhouer, nie 'n permanente binding nie. 'n Tuisroeteerder hou sy UDP-kaart 'n rukkie ná die laaste pakket, 'n operateur-gateway hergebruik poorte volgens sy eie skedule, en 'n telefoon wat van Wi-Fi na LTE oorskakel, kom met 'n heeltemal ander bron terug. Linux se conntrack-verstekke is 'n nuttige maatstaf hier: nf_conntrack_udp_timeout is 30 sekondes en die stroomvariante is 120, so 'n stil tonnel kan sy kaart verloor lank voordat die gebruiker dit agterkom.

Die tonnel oorleef omdat die protokol die eweknie authentiseer, nie die adres nie. WireGuard is na die handshake toestandloos, so enige geauthentiseerde pakket werk die gestoorde eindpunt by en 'n herbinding heel op die volgende pakket; daarom bestaan persistent-keepalive = 25, om die kaart warm te hou terwyl dit ledig is. OpenVPN se --float doen dieselfde werk en laat 'n geauthentiseerde kliënt van 'n nuwe adres en poort hervat. Op 2.4- en 2.5-weergawes waar float by verstek af is, stel 'n herbinding die sessie terug en die kliënt koppel weer.

IPsec kom daar met meer bewegende dele uit. IKEv2 merk vertaling op deur die bron- en bestemmingshashes in die NAT-opsporingslading te vergelyk, skakel oor na UDP 4500-enkapsulering en volg keepalives na die nuwe tupel. Wanneer keepalives geblokkeer word, bly die SA op papier staan terwyl verkeer in een rigting stilweg stop.

Wat die bediener kan toeskryf, en wat nie

Die mite wat doodgemaak moet word, is dat vertaling jou vir die operateur wegsteek. Dit verander die etiket, nie die waarneming nie. 'n Gateway agter operateur-NAT sien 100.64.0.0/10-ruimte of een openbare adres wat deur baie intekenare gedeel word, en kan die vloei steeds aan 'n sertifikaatonderwerp, 'n WireGuard-openbare sleutel, 'n toegewysde tonneladres, greptellers en 'n tydvenster koppel. Niks daarvan het jou LAN-adres nodig nie.

Die grense loop ook die ander kant toe. 'n Gedeelde adres in 'n log wys na 'n gateway, nie na 'n huishouding nie; twee sessies vanaf dieselfde vertaalde adres op verskillende poorte is verskillende toestelle; dieselfde adres op twee verskillende dae kan twee onverwante intekenare wees as die poort hergebruik is. 'n Bediener wat net eweknie-sleutels aanteken, kan nie een aan 'n kliënt koppel sonder die rekeningdatabasis nie, en 'n bediener wat net adresse aanteken, kan nie 'n skootrekenaar van 'n telefoon agter dieselfde roeteerder onderskei nie.

Vergelyk beide kante eerder as om te raai

Om uit te maak wat gebeur het, vang dieselfde verbinding aan beide kante op dieselfde oomblik vas en vergelyk die tupel, nie die adres nie. Aan die kliëntkant, voor enige vertaling:

ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints

Lees dan die vertalingsinskrywing op die roeteerder of CGNAT-gateway, en wat uiteindelik by die bediener aankom:

conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820

Drie patrone verduidelik die meeste mispassings. Die bediener se bronpoort verskil van die plaaslike poort terwyl die bestemming ooreenstem: gewone poortvertaling. Die bediener se bronadres hoort aan 'n ISP-blok wat nie joune is nie: ten minste een ekstra NAT-laag. Pakkette stop ná 'n ledige tydperk en hervat met 'n nuwe poort: die kaart het verval, nie 'n roeteerfout nie. As die tydstempels meer as 'n sekonde of twee uitmekaar is, vergelyk jy twee verskillende pogings.

Waar die verskil dinge breek

Onderbrekings wat soos bedienerfoute lyk, begin gewoonlik hier. 'n Toegangsreël wat aan jou tuisadres vasgepen is, misluk nadat die ISP se huur verander. 'n fail2ban-reël wat op 'n vertaalde adres pas, verban elke intekenaar agter daardie gateway tegelyk. 'n Werf-tot-werf-eweknie met 'n vaste afgeleë adres hou op om sleutels te hernu nadat 'n mobiele skakel verander. Die tonnelprotokol was reg; die aanname oor die buitenste tupel was nie.

Dieselfde verwarring wys hom by die bedienerkant. As die VPN-boks self agter NAT sit, het jy 'n poortaanstuur en 'n werkende aanstuurpad nodig; die strongSwan-aanstuurhandleiding dek daardie geval vir IPsec. 'n Bediener wat net op 'n private adres bereikbaar is, sien nooit die vertaalde tupel wat sy kliënte aanbied nie, en dit is 'n ander probleem as dat kliënte vertaal word.

Werk deur hierdie vier kontroles in volgorde en stop by die eerste een wat misluk:

• Vang aan beide kante op dieselfde tyd vas; bevestig dat bronpoort, bestemmingspoort en tydstempels ooreenstem.
• Lees die bediener se eweknie-lys vir die adres wat dit tans hou, nie die adres wat jy verwag het nie.
• Kontroleer die conntrack- of NAT-tabel vir die inskrywing en sy oorblywende leeftyd.
• Bevestig dat die tonnelkoppelvlakadres op die kliënt ooreenstem met wat die bediener toegewys het, nie die LAN-adres nie.

As beide opnames oor die tupel saamstem en die tonnel steeds misluk, is vertaling nie jou probleem nie; gaan voort na die handshake en na die roetetabel binne die tonnel.