Dobbel NAT og VPN-en din: klienten verkar, serveren gjer det ikkje

Rutaren din står bak ein annan ruter, WAN-adressa er privat, og VPN-klienten koplar likevel til. Den kombinasjonen overraskar folk som ventar at dobbel NAT skal øydeleggje tunnelane, men nettopp utgåande samband er det omsetjinga handterer best. Å drifte ein VPN-server bak dei same to laga er tilfellet som vanlegvis feilar. Teikn retninga på sambandet før du endrar noko.

Teikn retninga på sambandet først

Opne statussida til den indre rutaren og skriv ned WAN-adressa, og samanlikn ho deretter med adressa ein offentleg teneste rapporterer til deg. Viss dei to er ulike, står det minst éin omsetjar mellom rutaren din og internett. Viss WAN-adressa ligg innanfor 100.64.0.0/10, høyrer den ytre omsetjaren truleg til leverandøren din, og du kontrollerer han ikkje. Desse to fakta avgjer kva av dei seinare trinna som i det heile kan verke.

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

Dobbel NAT er ikkje dobbel VPN. Omsetjinga skriv om adresser og portar; ho legg ikkje til ein andre kryptert tunnel, og ho krypterer ingenting. Å halde dei to ideane frå kvarandre er viktig fordi løysingane er heilt ulike, og ein av dei krev ein samtale med leverandøren din i staden for ei innstillingsside.

Utgåande: klienten spør, omsetjarane mappar

Ein utgåande tunnel byrjar med ein pakke frå maskinen din, så kvar omsetjar kan lage ein mapping og sleppe svaret inn att. Protokollen, porten og inaktivitetstimane avgjer om mappinga overlever lenge nok til å vere nyttig. Dei fleste forbrukarrutarar klarar dette heilt utan konfigurasjon.

Feila som faktisk dukkar opp handlar vanlegvis om tidsavbrot og protokollstøtte, ikkje om talet på rutarar. Ein tunnel som fell etter nokre minutt stillheit, er ei mapping som går ut, og ein keepalive er det vanlege svaret. IPsec har standard NAT-traversal-utvidingar, så påstanden om at det ikkje kan krysse ei omsetjing er rett og slett feil. Viss tunnelen ikkje blir etablert i det heile, sjå på endepunktet og påloggingsdetaljane før du gir topologien skulda.

wg show
ping -c3 10.8.0.1

Stopp viss den utgåande tunnelen verkar frå eitt nettverk og ikkje frå eit anna. Den samanlikninga handlar om nettverka, ikkje om talet på rutarar.

Inngåande: vidaresending dekkjer berre utstyr du eig

Å drifte ein server er motsett retning: eit nytt samband kjem frå internett og må nå maskinen din gjennom kvart lag. Ein portvidaresendingsregel på den indre rutaren hjelper berre viss den ytre omsetjaren òg leverer den trafikken til deg. Å gjenta den lokale regelen gir deg ikkje kontroll over utstyret til leverandøren.

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

Samanlikn WAN-adressa til den indre rutaren med den offentlege adressa du observerte, og noter kvar kvar verdi kom frå. Viss WAN-adressa er privat eller i det delte området, utfører det ytre laget ei omsetjing du ikkje kan konfigurere. Spør leverandøren kva inngåande tilgjenge han støttar før du brukar ein heil kveld på reglar som ikkje kan tre i kraft. Å fjerne ein ruter eller slå av ein brannmur breitt er ikkje ein diagnose, og det er eit dårleg byte for éin open port.

Stopp viss det ytre laget er leverandøren sitt og det ikkje vidaresender. Då er dei støtta svara ein annan tilgangsmetode eller eit relay, ikkje endå ein regel på di side.

Test éin variabel om gongen

Endre éin ting per test og noter resultatet, fordi ein dobbel-NAT-veg har fleire variablar enn ein veg med éin ruter. Hald profilen og eininga fast, og samanlikn deretter eit anna tilgangsnettverk. Noter om forhandlinga feilar, om økta fell etter inaktivitet, eller om berre private mål feilar. Dei tre observasjonane peikar på tre ulike lag.

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

Overlappande private subnett er ei eiga felle som inga mengd omsetjing rettar opp. Viss heimenettverket og fjernnettverket brukar same område, oppstår ein rutekonflikt uansett kor mange omsetjarar som står imellom. Å nummerere om den eine sida på nytt er det einaste varige svaret.

Fjernporten fortener same merksemd, fordi vidaresendingsreglane og returrutane kan vere den manglande brikka. Ein tunnel som autentiserer kan framleis mangl eit brukande applikasjonsveg, og den feilen ser identisk ut frå klientsida. Gjennomgangen sluttar når du kan seie kva retning som feilar og kva lag som eig henne.