NAT dublu și VPN-ul tău: clientul funcționează, serverul nu

Routerul tău stă în spatele altui router, adresa WAN este privată, iar clientul VPN se conectează totuși. Această combinație îi surprinde pe cei care se așteaptă ca NAT-ul dublu să strice tunelurile, dar exact conexiunile de ieșire sunt cele pe care traducerea le gestionează cel mai bine. Găzduirea unui server VPN în spatele acelorași două straturi este cazul care eșuează de obicei. Desenează direcția conexiunii înainte de a schimba ceva.

Desenează mai întâi direcția conexiunii

Deschide pagina de stare a routerului interior și notează adresa lui WAN, apoi compară-o cu adresa pe care ți-o raportează un serviciu public. Dacă cele două diferă, între routerul tău și internet se află cel puțin un traducător. Dacă adresa WAN se încadrează în 100.64.0.0/10, traducătorul exterior aparține probabil furnizorului tău, iar tu nu îl controlezi. Aceste două fapte decid care dintre pașii următori poate funcționa.

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

NAT dublu nu este VPN dublu. Traducerea rescrie adrese și porturi; nu adaugă un al doilea tunel criptat și nu criptează nimic. Separarea celor două idei contează pentru că soluțiile sunt complet diferite, iar una dintre ele presupune o discuție cu furnizorul în loc de o pagină de setări.

Ieșire: clientul întreabă, traducătorii mapează

Un tunel de ieșire începe cu un pachet de la mașina ta, așa că fiecare traducător poate crea o mapare și poate lăsa răspunsul să intre înapoi. Protocolul, portul și temporizatoarele de inactivitate decid dacă acea mapare supraviețuiește suficient pentru a fi utilă. Majoritatea routerelor de consum se descurcă fără nicio configurare.

Defecțiunile care apar efectiv țin de obicei de expirări de timp și de suportul protocoalelor, nu de numărul de routere. Un tunel care cade după câteva minute de liniște este o mapare care expiră, iar un keepalive este răspunsul standard. IPsec are extensii NAT-traversal standard, așa că afirmația că nu poate traversa o traducere este pur și simplu greșită. Dacă tunelul nu se stabilește deloc, uită-te la punctul final și la credențiale înainte de a da vina pe topologie.

wg show
ping -c3 10.8.0.1

Oprește-te dacă tunelul de ieșire funcționează dintr-o rețea și nu din alta. Acea comparație este despre rețele, nu despre numărul de routere.

Intrare: redirecționarea acoperă doar echipamentul pe care îl deții

Găzduirea unui server este direcția inversă: o conexiune nouă sosește din internet și trebuie să ajungă la mașina ta trecând prin fiecare strat. O regulă de redirecționare de port pe routerul interior ajută doar dacă traducătorul exterior îți livrează și el acel trafic. Repetarea regulii locale nu îți dă control asupra echipamentului furnizorului.

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

Compară adresa WAN a routerului interior cu adresa publică pe care ai observat-o și notează de unde provine fiecare valoare. Dacă adresa WAN este privată sau în intervalul partajat, stratul exterior face o traducere pe care nu o poți configura. Întreabă furnizorul ce accesibilitate de intrare acceptă înainte de a petrece o seară întreagă pe reguli care nu pot intra în vigoare. Scoaterea unui router sau dezactivarea largă a unui firewall nu este un diagnostic și este un schimb prost pentru un singur port deschis.

Oprește-te dacă stratul exterior aparține furnizorului și nu redirecționează. Atunci răspunsurile acceptate sunt o altă metodă de acces sau un releu, nu încă o regulă de partea ta.

Testează o singură variabilă deodată

Schimbă un singur lucru pe test și notează rezultatul, pentru că o cale cu NAT dublu are mai multe variabile decât una cu un singur router. Ține profilul și dispozitivul fixe, apoi compară o altă rețea de acces. Observă dacă negocierea eșuează, dacă sesiunea cade după inactivitate sau dacă doar destinațiile private eșuează. Aceste trei observații indică trei straturi diferite.

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

Subrețelele private suprapuse sunt o capcană separată pe care nicio cantitate de traducere nu o repară. Dacă rețeaua ta de acasă și rețeaua la distanță folosesc același interval, apare un conflict de rute indiferent câți traducători sunt între ele. Renumerotarea unei părți este singurul răspuns durabil.

Gateway-ul la distanță merită aceeași atenție, pentru că regulile lui de redirecționare și rutele de întoarcere pot fi piesa lipsă. Un tunel care se autentifică poate să nu aibă totuși nicio cale de aplicație utilizabilă, iar acea defecțiune arată identic din partea clientului. Turul se termină când poți spune care direcție eșuează și care strat este responsabil.