Dvigubas NAT ir jūsų VPN: klientas veikia, serveris ne
Du adresus verčiantys maršrutizatoriai retai sustabdo išeinantį VPN klientą. Serverį už jų talpinti sunkiau, ypač kai išorinis sluoksnis yra operatoriaus lygio NAT.
Jūsų maršrutizatorius stovi už kito maršrutizatoriaus, WAN adresas privatus, o VPN klientas vis tiek prisijungia. Šis derinys nustebina tuos, kurie tikisi, kad dvigubas NAT sulaužys tunelius, tačiau būtent išeinančius ryšius vertimas tvarko geriausiai. Serverio VPN talpinimas už tų pačių dviejų sluoksnių yra atvejis, kuris paprastai nepavyksta. Prieš ką nors keisdami nubrėžkite ryšio kryptį.
Pirmiausia nubrėžkite ryšio kryptį
Atidarykite vidinio maršrutizatoriaus būsenos puslapį ir užsirašykite jo WAN adresą, tada palyginkite jį su adresu, kurį jums praneša kokia nors viešoji paslauga. Jei abu skiriasi, tarp jūsų maršrutizatoriaus ir interneto yra bent vienas vertėjas. Jei WAN adresas patenka į 100.64.0.0/10 intervalą, išorinis vertėjas greičiausiai priklauso jūsų tiekėjui, ir jūs jo nekontroliuojate. Šie du faktai lemia, kuris iš vėlesnių žingsnių apskritai gali veikti.
curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1
Dvigubas NAT nėra dvigubas VPN. Vertimas perrašo adresus ir prievadus; jis neprideda antro šifruoto tunelio ir nieko nešifruoja. Šias dvi idėjas svarbu atskirti, nes sprendimai visiškai skirtingi, o vienas jų reikalauja pokalbio su tiekėju, o ne nustatymų puslapio.
Išeinanti kryptis: klientas klausia, vertėjai susieja
Išeinantis tunelis prasideda paketu iš jūsų mašinos, todėl kiekvienas vertėjas gali sukurti susiejimą ir įleisti atsakymą atgal. Protokolas, prievadas ir neveikimo laikmačiai lemia, ar tas susiejimas išgyvens pakankamai ilgai, kad būtų naudingas. Dauguma vartotojų maršrutizatorių tai sutvarko be jokios konfigūracijos.
Trikdžiai, kurie iš tikrųjų pasitaiko, paprastai susiję su laiko limitu ir protokolų palaikymu, o ne su maršrutizatorių skaičiumi. Tunelis, kuris nukrenta po kelių minučių tylos, yra pasibaigiantis susiejimas, o keepalive yra įprastas atsakymas. IPsec turi standartinius NAT-traversal plėtinius, todėl teiginys, kad jis negali pereiti vertimo, yra tiesiog klaidingas. Jei tunelis visai nesudaromas, pažiūrėkite į galinį tašką ir prisijungimo duomenis, prieš kaltindami topologiją.
wg show
ping -c3 10.8.0.1
Sustokite, jei išeinantis tunelis veikia iš vieno tinklo, o iš kito ne. Tas palyginimas apie tinklus, o ne apie maršrutizatorių skaičių.
Įeinanti kryptis: persiuntimas apima tik jums priklausančią įrangą
Serverio talpinimas yra priešinga kryptis: naujas ryšys ateina iš interneto ir turi pasiekti jūsų mašiną per kiekvieną sluoksnį. Prievado persiuntimo taisyklė vidiniame maršrutizatoriuje padeda tik tada, kai išorinis vertėjas tą srautą taip pat pristato jums. Vietinės taisyklės kartojimas nesuteikia kontrolės tiekėjo įrangai.
nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'
Palyginkite vidinio maršrutizatoriaus WAN adresą su viešu adresu, kurį pastebėjote, ir užrašykite, iš kur atsirado kiekviena reikšmė. Jei WAN adresas privatus arba bendrame diapazone, išorinis sluoksnis atlieka vertimą, kurio negalite sukonfigūruoti. Paklauskite tiekėjo, kokį įeinantį pasiekiamumą jis palaiko, prieš praleisdami visą vakarą prie taisyklių, kurios negali įsigalioti. Maršrutizatoriaus pašalinimas ar ugniasienės išjungimas plačiai nėra diagnozė, ir tai blogas mainas už vieną atvirą prievadą.
Sustokite, jei išorinis sluoksnis priklauso tiekėjui ir jis nepersiunčia. Tada palaikomi atsakymai yra kitas prieigos būdas arba relė, o ne dar viena taisyklė jūsų pusėje.
Tikrinkite po vieną kintamąjį
Keiskite po vieną dalyką kiekviename bandyme ir užrašykite rezultatą, nes dvigubo NAT kelias turi daugiau kintamųjų nei vieno maršrutizatoriaus kelias. Laikykite profilį ir įrenginį fiksuotus, tada palyginkite kitą prieigos tinklą. Atkreipkite dėmesį, ar derybos nepavyksta, ar sesija nukrenta po neveikimo, ar nepavyksta tik privatūs tikslai. Šie trys pastebėjimai rodo tris skirtingus sluoksnius.
journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40
Persidengiantys privatūs potinkliai yra atskira spąstai, kurių joks vertimo kiekis nepataiso. Jei jūsų namų tinklas ir nuotolinis tinklas naudoja tą patį diapazoną, maršrutų konfliktas atsiranda nepaisant to, kiek vertėjų yra tarp jų. Vienos pusės pernumeravimas yra vienintelis ilgalaikis atsakymas.
Nuotolinis šliuzas nusipelno tokio pat dėmesio, nes jo persiuntimo taisyklės ir grįžimo maršrutai gali būti trūkstama dalis. Tunelis, kuris autentifikuojasi, vis tiek gali neturėti naudojamo programos kelio, ir tas gedimas iš kliento pusės atrodo vienodai. Apžvalga baigiasi, kai galite pasakyti, kuri kryptis nepavyksta ir kuris sluoksnis už tai atsakingas.