Un VPN comercial de ieșire în internet vă ascunde adresa; nu vă conectează la propria casă. Ajungerea la NAS sau la imprimanta dintr-o rețea de acasă necesită un gateway aflat în acea rețea și un client care construiește un tunel către el. Apoi pachetul trebuie să treacă cinci verificări, iar orice eșec al vreuneia arată la fel din exterior.

Poarta 1: clientul trebuie să selecteze tunelul

Verificați dacă prefixul de destinație este într-adevăr rutat în tunel pe client. Un profil de tunel divizat care împinge doar subrețeaua proprie a VPN-ului va trimite 192.168.x.x direct pe interfața locală, unde nu ajunge nicăieri. Uitați-vă la tabelul de rutare al clientului, nu la numele profilului.

Aceasta este cea mai frecventă defecțiune la clienții de telefon, care adesea implicit trimit doar DNS sau doar un prefix. Dacă ruta lipsește, strângerea de mână poate fi perfectă și dispozitivul tot inaccesibil.

Confirmați că adresa pool-ului clientului și subrețeaua de acasă nu se suprapun înainte de a continua.

Poarta 2: gateway-ul trebuie să redirecționeze

VPN-ul se termină pe un host care trebuie să redirecționeze pachetul decriptat către LAN. Aceasta cere redirecționarea IP activată și o politică de firewall care permite fluxul de la interfața VPN la interfața LAN. Pe un aparat router acest lucru este de obicei integrat; pe o cutie Linux cu strongSwan sau WireGuard sunt două setări pe care oamenii le uită. Verificați ambele înainte de a testa serviciul, deoarece fiecare singură produce același timeout.

Testați cu o captură pe interfața LAN, deoarece un pachet care nu apare niciodată acolo a fost aruncat sau nu a fost niciodată redirecționat.

Este o defecțiune diferită de cea a unui serviciu care refuză conexiunea, iar distincția economisește mult timp. Păstrați permisiunea îngustă, limitată la serviciu și la pool-ul VPN, nu la întreaga subrețea.

Poarta 3: calea de răspuns decide totul

Ținta răspunde la adresa sursă pe care a văzut-o, care este fie adresa pool-ului clientului, fie gateway-ul, în funcție de faptul dacă traduceți. Dacă gateway-ul implicit al țintei este routerul de acasă și acel router nu are rută către pool-ul VPN, răspunsul iese prin internet și moare. Aceasta este clasica conexiune unidirecțională.

Există două soluții legitime: adăugarea unei rute pentru pool pe gateway-ul LAN, sau source-NAT pe gateway-ul VPN pentru ca ținta să vadă mereu doar adresa gateway-ului. A doua este mai simplă și pierde identitatea originală a sursei.

Alegeți una în mod deliberat și notați care, deoarece regulile de firewall și jurnalele depind de ea. Ghidul de redirecționare strongSwan parcurge partea Linux a acelei decizii.

Poarta 4: nume și suprapunerea prefixelor

Numele de descoperire locale nu traversează o frontieră rutată, așa că un dispozitiv care în casă apare cu un nume prietenos poate fi invizibil prin tunel. Furnizați DNS pentru zona privată sau documentați adresa. Orice nume ați folosi, acesta trebuie să se rezolve în ceva ce clientul de la distanță poate ruta. De aceea un dispozitiv poate fi accesibil după adresă și invizibil după nume în același timp.

Prefixele suprapuse sunt cealaltă capcană: dacă pool-ul clientului este 192.168.1.0/24 și rețeaua de acasă la fel, clientul tratează destinația ca locală și nu o trimite niciodată prin tunel.

Renumerotați o parte, sau folosiți un pool dintr-un interval pe care nu îl veți întâlni acasă.

Poarta 5: testați din afara casei

Un test din bucătărie nu dovedește nimic, deoarece traficul poate să nu părăsească niciodată LAN-ul. Conectați-vă de la un hotspot mobil sau altă rețea, apoi parcurgeți porțile în ordine: rută pe client, captură pe interfața LAN, răspunsul serviciului, captura răspunsului și rezolvarea numelor. Prima poartă care nu produce dovezi este locul unde este munca.

Dacă serviciul răspunde dar numele nu, aveți o problemă de DNS și nu una de tunel.

Păstrați configurația care funcționează într-o notă cu pool-ul, ruta și alegerea NAT, deoarece următoarea schimbare a routerului le va reseta pe toate trei.

Articole similare