Fișier hosts contra filtrului routerului: blocarea unui site prin VPN

O intrare în fișierul hosts și un filtru al routerului blochează același site din motive complet diferite, de aceea unul continuă să funcționeze sub un VPN, iar celălalt se oprește în liniște. Fișierul hosts răspunde la un nume înainte ca vreun pachet să părăsească mașina. Filtrul routerului inspectează traficul care îl traversează. Puneți un tunel între aceste două puncte și al doilea își pierde vederea, în timp ce primul nu observă nimic.

Unde este rezolvat numele decide totul

Fiecare blocare începe cu o întrebare: cine transformă numele într-o adresă? Pe un desktop obișnuit răspunde resolverul sistemului, care urmează ordinea configurată și de obicei citește fișierul hosts înainte de a interoga DNS. Într-o rețea filtrată răspunsul poate veni de la router, care vede interogarea doar dacă clientul o trimite prin el fără protecție. Schimbați calea și schimbați cine are voie să răspundă.

Un VPN face aici două lucruri deodată: mută ruta implicită și poate impune propriul server DNS. Oricare dintre cele două schimbări este suficientă pentru a muta rezolvarea numelor departe de dispozitivul care aplica blocarea.

Acesta este mecanismul din spatele plângerii cunoscute că filtrul funcționează până când se conectează VPN-ul.

O intrare hosts răspunde înainte ca tunelul să existe

O linie precum 127.0.0.1 www.example.com este citită de resolverul local, așa că răspunsul este produs pe mașină fără rețea. Conectați un tunel, schimbați serverul DNS, schimbați rețelele: intrarea returnează în continuare loopback. De aceea o blocare hosts este singura dintre cele două care nu depinde de locul unde se termină VPN-ul.

Punctele sale oarbe sunt la fel de locale. O aplicație care își aduce propriul resolver, vorbește DNS over HTTPS sau se conectează la o adresă literală nu întreabă niciodată sistemul, așa că intrarea nu este consultată. O adresă din cache într-un proces care rulează are același efect până când procesul repornește.

Confirmați răspunsul cu getent ahosts pe Linux sau Resolve-DnsName pe Windows în loc să vă bazați pe o filă de browser.

Un filtru al routerului vede doar ce îl traversează

Un filtru de conținut sau URL pe un router de acasă potrivește numele și cererile care îl traversează într-o formă lizibilă. Când clientul construiește un tunel criptat către un server în altă parte, routerul vede un singur flux către acel server și nimic în interior. Filtrul nu are niciun nume de potrivit, așa că lasă traficul să treacă, iar asta arată ca o defecțiune a filtrului, nu ca o ocolire.

Topologia care funcționează este cealaltă: routerul ține tunelul el însuși, decriptează la capăt și aplică filtrul acolo. În acel design filtrul stă acolo unde apare textul clar.

Dacă tunelul se termină pe laptop, routerul este prin definiție în afara căii protejate, indiferent cum este scrisă regula.

Patru puncte de aplicare și ce ratează fiecare

Patru locuri pot aplica o blocare și fiecare eșuează altfel. Citiți lista ca o hartă de acoperire, nu ca un clasament.

• Fișier hosts sau resolver local: funcționează offline și sub orice tunel, dar este ocolit de un resolver încorporat sau de o adresă codificată fix.
• Filtrarea DNS la gateway-ul VPN: acoperă clienții care folosesc resolverul impus și ratează clienții care suprascriu DNS.
• Reguli de ieșire ale gateway-ului după adresă sau SNI: independente de DNS-ul clientului, dar oarbe la numele pe care nu le pot citi și la adresele pe care nu le-au învățat.
• Politică gestionată de browser sau dispozitiv: puternică pe hardware gestionat, absentă pe dispozitive personale.

Niciuna dintre acestea nu este o graniță de securitate împotriva unui utilizator hotărât pe un dispozitiv negestionat. Sunt controale de politică, iar o descriere onestă spune ce trafic acoperă fiecare.

Alegeți stratul care corespunde intenției: confortul casnic aparține dispozitivului, iar o regulă organizațională aparține gateway-ului.

Testați ambele stări înainte de a-l numi terminat

Rulați aceleași trei comenzi cu VPN-ul conectat și deconectat: getent ahosts pentru a vedea răspunsul resolverului, nslookup pentru a vedea ce returnează interogarea și curl -I către site pentru a vedea dacă o conexiune se mai finalizează. Dacă prima returnează loopback în timp ce a treia se conectează la adresa reală, ceva a ocolit resolverul, iar intrarea hosts nu este controlul pe care îl credeți.

Pe router, citiți contoarele filtrului înainte și după o cerere. Un contor care nu se mișcă niciodată înseamnă că traficul nu a ajuns niciodată la filtru, iar asta este un răspuns de rutare, nu de regulă.

Notați rezultatul împreună cu topologia, pentru că următoarea schimbare de VPN va muta din nou calea.