Alkalmazásonkénti kill switch vagy teljes eszközzár: mi változik

Az alkalmazásonkénti kill switch óvatos választásnak hangzik: csak a munkaügyfél veszíti el a hálózatát, amikor a tunnel leesik, és minden más tovább működik. Aztán valaki észreveszi, hogy a személyes böngésző mégis betöltött egy oldalt, az ugyanabból a csomagból származó szinkronsegéd tovább próbálkozott, és egy gyorsítótárazott név továbbra is olyan címre oldódott fel, amely soha nem érte el a tunnelt. A funkció címkéje és a ténylegesen védett kapcsolatok halmaza két különböző dolog. Először a védett halmazt határozza meg, mert ez dönti el, hogy az alkalmazásonkénti kényszerítés vagy a teljes eszköz zárja-e a tisztességes leírás.

Kezdje a halmazzal, ne a címkével

Az alkalmazásonkénti szabályzat a kiválasztott alkalmazásokat védi. Az eszközzár szélesebb hálózati határra irányul, általában dokumentált kivételekkel a helyi nyomtatásra, a felügyeleti forgalomra vagy a captive portalokra. Egyik címke sem teljes, amíg három kérdésre nem tud válaszolni: mi történik a kizárt alkalmazásokkal, mi történik azokkal a segédekkel, amelyeket ezek az alkalmazások indítanak, és mi történik azokkal a kapcsolatokkal, amelyek akkor nyílnak, amikor a védelem nem elérhető.

Írja le ezeket a válaszokat, mielőtt bármelyik ügyfélbeállításhoz nyúl. Ha a követelmény az, hogy "ez a bérszámfejtő ügyfél soha ne beszéljen az internettel a tunnelen kívül, a böngészőm pedig igen", a halmaz kicsi, és az alkalmazásonkénti kényszerítés megfelel. Ha a követelmény az, hogy "ezen az eszközön semmi ne érje el az internetet védelem nélkül, kivéve a frissítési szolgáltatást", egyetlen alkalmazásonkénti szabályzat sem fogja ezt előállítani, mert a problémát azok az alkalmazások jelentik, amelyeket nem nevezett meg.

Az alkalmazásonkénti kényszerítés azonosítókkal egyezik, nem programnevekkel

Az Android csomagokon keresztül teszi elérhetővé az alkalmazásonkénti VPN-t, és a VpnService dokumentációja leírja, hogyan hat ez együtt a folyamatos működéssel és a blokkolással. Az iOS felügyeleti profilon keresztül állítja be az alkalmazásonkénti VPN-t, és alkalmazás vagy domain szerint egyeztet. A Windows és a Linux egyáltalán nem rendelkezik folyamatonkénti útvonallal, ezért ugyanezt az ötletet egy programra korlátozott tűzfal-szabállyal vagy a tulajdonos felhasználóra illeszkedő szabálysal közelítik.

A határ az azonosító, az azonosítókat pedig könnyű megkerülni. Egy alkalmazás, amely URL-t ad át a rendszerböngészőnek, vagy dokumentumot nyit meg egy nézegetőben, olyan folyamatba lép át, amelyet a szabályzata soha nem nevezett meg. A leálláskor történő leállítás opciója sem csomagszűrő: megöli a beállított alkalmazást, miközben egy gyermekfolyamat, egy sorfeldolgozó vagy egy böngészőlap életben tarthat egy meglévő socketet.

A zár azt fedi le, amit az alkalmazásonkénti szabályzat nem láthat

A teljes eszköz zárja elveszi a választást. Minden kimenő csomag eldobásra kerül, amely nem a tunnelhez tartozik, beleértve azoknak a folyamatoknak a forgalmát, amelyekről az alkalmazásszabályzata soha nem tudott. Androidon ez a folyamatosan bekapcsolt VPN és a kapcsolatok blokkolását beállító opció együttese, és a kényszerítés a rendszerben történik, nem az ügyfél ablakában. Asztali gépen ez állandó tűzfalszabály vagy elérhetetlen átjáróra mutató alapértelmezett útvonal.

Az ár az, hogy minden más leáll, így a kivételek a tervezés részévé válnak, nem utólagos ötletté. A helyi nyomtatók, a szolgáltatásfelderítés, a captive portal bejelentkezés, a felügyeleti ügynökök és az operációs rendszer frissítései mindegyike dokumentált lyukat igényel, mert mindegyik olyan útvonal, amely nyitva marad, amikor a tunnel nem működik. A zár csak annyira erős, mint a lista legrövidebb bejegyzése.

A DNS, az IPv6 és a háttérsegédek elrejtik a szivárgásokat

Az, hogy egy védett alkalmazás nem tud feloldani egy nevet, nem bizonyítja, hogy a gyorsítótárazott válaszok vagy a közvetlen IP-forgalom blokkolva vannak. Ha a feloldó a tunnelen kívül még elérhető, a név feloldódik, és a kapcsolat meghiúsul, ami működő kill switchnek látszik, és nem az. Ráadásul egy gyorsítótárazott rekord olyan címre mutathat, amelyet a tunnel nem visz, így a kapcsolat közvetlenül kimegy, miközben az alkalmazás VPN-hibát jelent.

Az IPv6-nak minden olyan platformon saját szabály kell, amely futtatja, mert a v4-es eldobási szabály nem fedi le a v6-os útvonalat. Mobilon egy privát DNS-beállítás titkosított csatornába viheti a feloldást, amelyet az eszközszabályzat nem vizsgál. A háttérsegédek pedig az asztali gép szokásos bűnösei: egy frissítő vagy szinkronizáló folyamat a VPN-ügyfél előtt indul, és megtartja a saját kapcsolatát, így soha nem látja a megváltozott útvonalat.

Teszteljen három alkalmazást és két átmenetet

Futtassa le minden sort kétszer, egyszer gazdanévvel és egyszer szó szerinti címmel, és még egyszer IPv6-on, ha a hálózat kínálja. Az átjutás azt jelenti, hogy a bevont alkalmazás leállt, a kizárt úgy viselkedett, ahogy leírta, és a segéd nem surrant ki. Rögzítse azt a közvetlen viselkedést, amelyet elfogadhatónak ítélt, hogy a következő rendszergazda meg tudja különböztetni a szándékos kivételt a hibától.

Ezután írja le az eredményt egyetlen mondatban, amely megnevezi az alkalmazásokat és a feltételeket, például: a bérszámfejtő ügyfélnek nincs útvonala a tunnelen kívül, a böngésző szándékosan közvetlen, és minden más leáll, amikor a tunnel nem működik. Ha ezt a mondatot nehéz megírni, a szabályzat továbbra is két egymással harcoló szabályzat.