Dubbel-NAT en jou VPN: die kliënt werk, die bediener nie

Jou router sit agter nog ’n router, die WAN-adres is privaat, en die VPN-kliënt maak steeds verbinding. Daardie kombinasie verras mense wat verwag dat dubbel-NAT tonnels sal breek, maar uitgaande verbindings is juis wat vertaling die beste hanteer. Om ’n VPN-bediener agter dieselfde twee lae te huisves, is die geval wat gewoonlik misluk. Teken eers die rigting van die verbinding voordat jy enigiets verander.

Teken eers die rigting van die verbinding

Maak die binnerouter se statusbladsy oop en skryf sy WAN-adres neer, en vergelyk dit dan met die adres wat ’n publieke diens vir jou rapporteer. As die twee verskil, sit daar ten minste een vertaler tussen jou router en die internet. As die WAN-adres binne 100.64.0.0/10 val, is die buitenste vertaler waarskynlik jou diensverskaffer s’n, en jy beheer dit nie. Daardie twee feite bepaal watter van die latere stappe enigsins kan werk.

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

Dubbel-NAT is nie dubbel-VPN nie. Vertaling herskryf adresse en poorte; dit voeg nie ’n tweede geënkripteerde tonnel by nie, en dit enkripteer niks. Om die twee idees uitmekaar te hou, is belangrik omdat die oplossings heeltemal verskil, en een van hulle behels ’n gesprek met jou diensverskaffer eerder as ’n instellingsbladsy.

Uitgaande: die kliënt vra, die vertalers karteer

’n Uitgaande tonnel begin met ’n pakkie van jou masjien, so elke vertaler kan ’n kartering skep en die antwoord teruglaat inkom. Die protokol, die poort en die rus-tydhouers bepaal of daardie kartering lank genoeg oorleef om nuttig te wees. Die meeste verbruikersrouters hanteer dit sonder enige konfigurasie.

Die mislukkings wat wel voorkom, gaan gewoonlik oor tydverstrykings en protokolondersteuning eerder as oor die aantal routers. ’n Tonnel wat ná ’n paar minute se stilte val, is ’n kartering wat verval, en ’n keepalive is die standaard antwoord. IPsec het standaard NAT-traversal-uitbreidings, so om te beweer dat dit nie vertaling kan kruis nie, is eenvoudig verkeerd. As die tonnel glad nie tot stand kom nie, kyk na die eindpunt en die geloofsbriewe voordat jy die topologie blameer.

wg show
ping -c3 10.8.0.1

Stop as die uitgaande tonnel van een netwerk werk en van ’n ander nie. Daardie vergelyking gaan oor die netwerke, nie oor die aantal routers nie.

Inkomend: doorstuur dek net toerusting wat jy besit

Om ’n bediener te huisves, is die omgekeerde rigting: ’n nuwe verbinding kom van die internet en moet jou masjien deur elke laag bereik. ’n Poortdoorstuur-reël op die binnerouter help net as die buitenste vertaler daardie verkeer ook na jou lewer. Om die plaaslike reël te herhaal, gee jou nie beheer oor die diensverskaffer se toerusting nie.

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

Kontroleer die binnerouter se WAN-adres teen die publieke adres wat jy gesien het, en let op waar elke waarde vandaan kom. As die WAN-adres privaat is of in die gedeelde reeks lê, doen die buitenste laag vertaling wat jy nie kan konfigureer nie. Vra die diensverskaffer watter inkomende bereikbaarheid hy ondersteun voordat jy ’n hele aand spandeer op reëls wat nie in werking kan tree nie. Om ’n router te verwyder of ’n firewall breed te deaktiveer, is nie ’n diagnose nie, en dit is ’n swak ruil vir een oop poort.

Stop as die buitenste laag die diensverskaffer s’n is en dit nie doorstuur nie. Dan is die ondersteunde antwoorde ’n ander toegangsmetode of ’n relay, nie nog ’n reël aan jou kant nie.

Toets een veranderlike op ’n slag

Verander een ding per toets en teken die resultaat aan, want ’n dubbel-NAT-pad het meer veranderlikes as ’n enkelrouter-pad. Hou die profiel en die toestel vas, en vergelyk dan ’n ander toegangsnetwerk. Let op of onderhandeling misluk, of die sessie ná rus val, of net private bestemmings misluk. Daardie drie waarnemings wys na drie verskillende lae.

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

Oorvleuelende private subnetwerke is ’n aparte valstrik wat geen hoeveelheid vertaling regmaak nie. As jou tuisnetwerk en die afgeleë netwerk dieselfde reeks gebruik, verskyn ’n roetekonflik ongeag hoeveel vertalers tussenin sit. Om een kant te hernommer, is die enigste duursame antwoord.

Die afgeleë gateway verdien dieselfde aandag, want sy doorstuur-reëls en terugroetes kan die ontbrekende stuk wees. ’n Tonnel wat authentiseer, kan steeds geen bruikbare toepassingspad hê nie, en daardie mislukking lyk van die kliënt se kant identies. Die deurloop eindig wanneer jy kan sê watter rigting misluk en watter laag dit besit.