hosts fájl kontra router szűrő: oldal blokkolása VPN-en át

A hosts fájl egy bejegyzése és egy routeren futó szűrő teljesen más okból blokkolja ugyanazt az oldalt, ezért az egyik tovább működik VPN alatt, a másik pedig csendben leáll. A hosts fájl még azelőtt válaszol egy névre, hogy bármely csomag elhagyná a gépet. A router szűrője a rajta áthaladó forgalmat vizsgálja. Tegyen alagutat a két pont közé, és a második elveszíti a rálátását, míg az első mit sem vesz észre.

Hogy hol oldódik fel a név, mindent eldönt

Minden blokkolás egy kérdéssel kezdődik: ki alakítja a nevet címmé? Egy átlagos asztali gépen a rendszer feloldója válaszol, amely a beállított sorrendjét követi, és általában a hosts fájlt olvassa el a DNS megkérdezése előtt. Szűrt hálózaton a válasz a router is lehet, amely csak akkor látja a kérést, ha az ügyfél védelem nélkül küldi át rajta. Változtassa meg az útvonalat, és megváltoztatja, ki válaszolhat.

A VPN itt két dolgot tesz egyszerre: elmozdítja az alapértelmezett útvonalat, és saját DNS-kiszolgálót is kényszeríthet. Bármelyik változás elég ahhoz, hogy a névfeloldás elkerüljön attól az eszköztől, amely a blokkolást érvényesítette.

Ez a mechanizmusa annak az ismert panasz mögött, hogy a szűrő addig működik, amíg a VPN csatlakozik.

A hosts bejegyzés azelőtt válaszol, hogy az alagút létezne

Egy 127.0.0.1 www.example.com alakú sort a helyi feloldó olvas, így a válasz a gépen keletkezik hálózat nélkül. Csatlakoztasson alagutat, változtassa meg a DNS-kiszolgálót, váltson hálózatot: a bejegyzés továbbra is loopbacket ad vissza. Ezért a hosts blokkolás az egyetlen a kettő közül, amelyet nem befolyásol, hol végződik a VPN.

A vakfoltjai ugyanolyan helyiek. Egy saját feloldót hordozó, DNS over HTTPS-t beszélő vagy literál címre csatlakozó alkalmazás soha nem kérdezi a rendszert, ezért a bejegyzés nem kerül szóba. Egy futó folyamatban gyorsítótárazott cím ugyanígy hat, amíg a folyamat újra nem indul.

Erősítse meg a választ Linuxon getent ahosts, Windowson Resolve-DnsName paranccsal, ahelyett hogy egy böngészőfülnek hinne.

A router szűrője csak azt látja, ami áthalad rajta

Egy otthoni router tartalom- vagy URL-szűrője azokat a neveket és kéréseket párosítja, amelyek olvasható formában haladnak át rajta. Amikor az ügyfél titkosított alagutat épít egy máshol lévő kiszolgálóhoz, a router egyetlen folyamot lát ahhoz a kiszolgálóhoz, és semmit a belsejében. A szűrőnek nincs neve, amelyhez párosíthatna, ezért átengedi a forgalmat, és ez úgy tűnik, mintha a szűrő hibázott volna, nem úgy, mintha megkerülték volna.

A működő topológia a másik: a router maga tartja az alagutat, a végponton fejt vissza, és ott alkalmazza a szűrőt. Ebben a kialakításban a szűrő ott ül, ahol a tiszta szöveg megjelenik.

Ha az alagút a laptopon végződik, a router definíció szerint a védett útvonalon kívül van, akárhogy is írják a szabályt.

Négy érvényesítési pont és mit hagy ki mindegyik

Négy hely érvényesíthet blokkolást, és mindegyik másképp hibázik. A listát lefedettségi térképként olvassa, nem rangsorként.

• hosts fájl vagy helyi feloldó: offline és bármely alagút alatt működik, de megkerüli egy beágyazott feloldó vagy egy keményen kódolt cím.
• DNS-szűrés a VPN-átjárón: lefedi azokat az ügyfeleket, amelyek a kényszerített feloldót használják, és kihagyja azokat, amelyek megkerülik a DNS-t.
• Átjáró kimenő szabályai cím vagy SNI szerint: függetlenek az ügyfél DNS-étől, de vakok azokra a nevekre, amelyeket nem tudnak olvasni, és azokra a címekre, amelyeket nem tanultak meg.
• Kezelt böngésző- vagy eszközszabályzat: erős kezelt hardveren, hiányzik a személyes eszközökön.

Egyik sem biztonsági határ egy elszánt felhasználóval szemben egy nem kezelt eszközön. Ezek szabályzati kontrollok, és egy őszinte leírás megmondja, melyik forgalmat fedi le valójában mindegyik.

Válassza azt a réteget, amely illik a szándékhoz: az otthoni kényelem az eszközhöz tartozik, a szervezeti szabály pedig az átjáróhoz.

Tesztelje mindkét állapotot, mielőtt késznek nyilvánítja

Futtassa ugyanazt a három parancsot a VPN csatlakoztatva és leválasztva: getent ahosts a feloldó válaszának megtekintéséhez, nslookup ahhoz, hogy mit ad vissza a kérés, és curl -I az oldal felé, hogy a kapcsolat még létrejön-e. Ha az első loopbacket ad, miközben a harmadik a valódi címre csatlakozik, valami megkerülte a feloldót, és a hosts bejegyzés nem az a kontroll, aminek gondolja.

A routeren olvassa le a szűrő számlálóit egy kérés előtt és után. Egy sosem mozduló számláló azt jelenti, hogy a forgalom sosem érte el a szűrőt, és ez útvonalválasz, nem szabályválasz.

Írja le az eredményt a topológiával együtt, mert a következő VPN-változás újra elmozdítja az útvonalat.