Conectarea unui telefon la tunelul casei și deschiderea unei partajări de fișiere în LAN dovedește că tunelul funcționează. Nu dovedește că cererile de internet ale telefonului ies prin casă. Diferența dintre aceste două rezultate este o politică de redirecționare plus o rută, nu încă o casetă de bifat pe telefon. Este și diferența pe care majoritatea oamenilor presupun că au configurat-o deja.

Trei decizii produc calea de ieșire: ce trimite telefonul în tunel, încotro o redirecționează gateway-ul casei și ce se întâmplă când tunelul nu este acolo. Fiecare are un mod de eșec care, de pe ecranul telefonului, arată ca celelalte.

Două salturi, două politici

Conexiunea exterioară se termină la ascultătorul VPN al casei. Pachetul interior este un obiect separat care trebuie redirecționat undeva, iar redirecționarea este o decizie de firewall diferită de acceptarea tunelului de la bun început.

phone app -> encrypted tunnel -> home listener
          -> decrypted packet -> forward policy -> home uplink -> destination

Pe un router de casă obișnuit, acestea trăiesc în seturi de reguli diferite. Acceptarea tunelului este politică de intrare pe interfața VPN; trimiterea traficului telefonului spre internet este politică de redirecționare plus traducerea de sursă de care are nevoie uplink-ul. Un router care acceptă tunelul și nu redirecționează nimic produce un telefon care arată conectat și nu încarcă nicio pagină.

Dacă serviciul VPN rulează pe o mașină separată în casă, adaugă un salt. Acum routerul vede traficul care vine de la acea mașină, așa că regulile sale se aplică adresei serverului, nu adresei tunelului telefonului, iar traducerea de sursă poate face fiecare telefon să pară un singur host.

Ascultătorul nu este filtrul

Decide unde are loc aplicarea cât timp informația de care ai nevoie încă există. Pe router, adresa tunelului telefonului este vizibilă și poate fi potrivită direct. În spatele unei a doua traduceri a dispărut, iar regulile scrise pentru adresa telefonului nu se potrivesc cu nimic, în liniște.

Acesta este motivul obișnuit pentru care o politică funcționează pentru laptop și nu pentru telefon. Laptopul se conectează direct la router, telefonul se conectează la un server care redirecționează prin router, și doar prima cale păstrează adresa pe care o așteaptă regula. Regula nu este greșită; potrivește o valoare care nu mai există în acel punct.

Notează calea cu adresa de sursă așa cum apare în fiecare punct de aplicare. Acea singură diagramă rezolvă majoritatea acestor cazuri înainte de a fi editată vreo regulă.

Ce trebuie să trimită de fapt telefonul

Un telefon care primește doar o rută către subrețeaua casei trimite în tunel doar traficul acelei subrețele. Tot restul iese prin rețeaua mobilă, de aceea partajarea de fișiere funcționează, iar cererile de internet nu ajung niciodată la casă.

Acoperirea completă prin tunel este o decizie de rutare de partea clientului și trebuie stabilită cu mecanismul acceptat de platformă, nu presupusă din profilul care se instalează. Odată stabilită, ruta înapoi spre serverul VPN însuși trebuie să rămână în afara tunelului, altfel clientul nu își poate menține propriul transport.

DNS merită o decizie proprie, pentru că este partea cea mai predispusă să devieze de la restul traficului. O adresă de resolver în profil este o sugestie pe care clienții o tratează diferit, iar o aplicație cu propriul resolver criptat poate lua o cale complet separată. Dacă politica casei depinde de faptul că interogările ajung la un anumit resolver, aplică-o acolo unde traficul trece cu adevărat, sau acceptă că unele interogări nu o vor face. O interogare care ocolește resolverul tău nu ajunge niciodată la o regulă scrisă pentru ea.

IPv6 aparține aceluiași paragraf ca DNS, nu unei anexe. Un tunel IPv4 complet nu spune nimic despre traficul AAAA, iar un telefon într-o rețea mobilă cu stivă dublă va folosi bucuros calea nativă pentru asta. Alege transport sau blocare în mod explicit.

Ce poate și ce nu poate vedea firewall-ul

Gateway-ul poate acționa asupra a ceea ce expune punctul său de aplicare: adrese, porturi, protocol, interfață și metadatele conexiunii. O cerere HTTPS redirecționată nu predă corpul paginii sau parola doar pentru că traversează tunelul casei.

Merită spus această limită, pentru că expresia „treci-o prin firewall” implică mai multă inspecție decât face un router de casă. O regulă de destinație, o politică DNS și un proxy la nivel de aplicație sunt trei controale diferite cu trei costuri diferite de implementare.

Nu presupune că o funcție configurată pentru clienții LAN ai casei se aplică interfeței VPN. Apartenența la zonă este o alegere de configurare, iar o interfață VPN care nu este în zona corectă nu moștenește niciuna dintre regulile pe care le-ai testat de pe canapea.

Decide starea deconectată

Când tunelul nu este disponibil, telefonul fie revine la rețeaua mobilă, fie refuză să trimită traficul. Ambele sunt rezonabile, și doar una dintre ele corespunde cu ceea ce majoritatea oamenilor cred că au configurat.

Revenirea este comodă și scurge prin definiție: momentul în care cade tunelul este momentul în care cererile ies pe calea operatorului. Blocarea este mai puternică și face telefonul dependent de casă fiind accesibilă, ceea ce este un cost real de disponibilitate pentru cineva care călătorește. Niciunul dintre comportamente nu este un defect; ambele sunt produse, și alegi între ele fie că spui asta, fie că nu.

Testează alegerea în loc să o presupui. Oprește serviciul casei, apoi încearcă o cerere din browserul telefonului și una dintr-o aplicație care rulează în fundal. Reconectarea mai târziu nu anulează cererile care au ieșit deja.

Încheie cu două verificări controlate chiar de pe telefon: o operațiune permisă care ar trebui să traverseze casa, și o refuzare pe care politica casei ar trebui să o aplice. Confirmă că gateway-ul a înregistrat fluxul așteptat, în familia de adrese așteptată, după o reconectare. Un telefon care arată Conectat este începutul acelei verificări, niciodată sfârșitul.

Articole similare