Always-on VPN vagy kill switch: mit kapcsolt be valójában?

Az always-on és a kill switch két sorral van egymástól ugyanazon a beállítási képernyőn, ezért sokan egyetlen funkció két nevének hiszik őket. Nem azok. Az always-on újracsatlakozási szabály: indítsa el az alagutat rendszerindításkor, hozza vissza összeomlás vagy hálózatváltás után, és próbálkozzon tovább, amíg nem sikerül. A kill switch forgalmi szabály: megnevezi azokat a csomagokat, amelyek az alagút kiesésekor is elhagyhatják a gépet. Az elsőt bekapcsolhatja a második nélkül, és a legtöbb platformon az alapértelmezett eredmény a rés idején is engedi ki a forgalmat.

1. ellenőrzés: önálló kapcsoló-e a blokk?

Android 10 és újabb verziókon a mentett VPN-profil két független kapcsolót nyit a fogaskerék ikon mögött: Always-on VPN és Block connections without VPN. Csak a második a kill switch. Pusztán always-on mellett az alagút valóban visszatér kiesés után, és bármely kérése közben lévő alkalmazás elérheti a hálózatot Wi-Fi-n vagy mobiladaton, amíg ez meg nem történik.

A felügyelt eszközök ugyanezt a kettéválasztást tartják a házirend API-ban. setAlwaysOnVpnPackage() a csomag nevét és egy lockdownEnabled jelzőt vesz át; aki beállítja a csomagot, de a jelzőt false értéken hagyja, állandó alagutat épített, nem lezárt eszközt. A konzol szövege ritkán teszi láthatóvá ezt a különbséget.

Az állapotot az eszközről olvassa ki, ne a konzolról: adb shell settings get global always_on_vpn_app és adb shell settings get global always_on_vpn_lockdown. Ha az első null értéket ad, a platform szintjén nincs kikényszerített csomag; ha a második 0 értéket ad, a platform semmit nem blokkol. Az Android VPN útmutató ezeket külön képességekként írja le, nem egyetlen módként.

2. ellenőrzés: melyik réteg birtokolja a blokkot?

A címkék az ügyfélben élnek, a blokkok pedig többnyire a tűzfalban, ezért jelent ugyanaz a szó mást minden platformon. Az alábbi sorokat érdemes megerősíteni, mielőtt bármelyikükben megbízik.

A Windows a legvilágosabb példa a nem blokkoló címkére. Ott az Always On az alagút állandóságát írja le: eszközalagutat a gép hitelesítéséhez, felhasználói alagutat a bejelentkezett fiókhoz, profil XML-lel vagy Add-VpnConnection paranccsal beállítva. A profilban semmi nem állít meg egy kimenő csomagot, ha nincs alagút, a kimenő szűrés pedig alapból nincs bekapcsolva, így a Wi-Fi-n lévő laptop a VPN kiesésekor is működik tovább.

A WireGuard ugyanígy válik szét, de ügyfelenként. A WireGuard for Windows alagútonkénti Block untunneled traffic opciót kínál, amely szűrőszabályokat telepít; a Linux eszköztárban nincs ilyen kapcsoló. A wg-quick minden AllowedIPs bejegyzéshez útvonalat és egy fwmark szabályt ad, a wg-quick down pedig mindkettőt eltávolítja, így a fizikai alapértelmezett útvonal újra átveszi a szerepet, egyetlen csomag eldobása nélkül.

Az Apple platformjain az always-on felügyelt eszközök kezelési profiljának funkciójaként érkezik, és on-demand szabályokként fejeződik ki, nem jelölőnégyzetként. A hasznos terhelésből azt a kérdést kell megválaszolni, hogy a sikertelen alagút tiltja-e a forgalmat, vagy csak új kapcsolatot kér. A menü címe ezt nem mondja meg.

3. ellenőrzés: a rést mérje, ne az ikont

Négy átmenet számít, és mindegyik másképp hibázik: rendszerindítás, mielőtt bárki bejelentkezik, alvás és ébresztés, Wi-Fi-ről mobiladatra váltás, valamint ügyfél-összeomlás, amely félig konfigurálva hagyja az alagút interfészét. Egyikük tiszta újracsatlakozása semmit nem bizonyít a másik háromról.

A legolcsóbb teszt szándékosan leállítja az alagutat, majd megpróbál kijutni. Kiesett alagút mellett a curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com által visszaadott 200 azt jelenti, hogy a szabály fail-open; az időtúllépés vagy az elutasított kapcsolat azt, hogy valami még blokkol. A ip route get 1.1.1.1 megnevezi az interfészt, amely vinné a csomagot, ami általában többet mond a tálcai ikonnál, a systemctl status wg-quick@wg0 pedig megmutatja, tisztán eltávolították-e az interfészt.

Ugyanazt a próbát futtassa egy második ablakban, miközben a hálózat változik, ne csak utána. A kiesés és az újrapróbálkozás közötti idő a lényeg, és a névfeloldás a leggyorsabb módja annak észrevevésére, hogy a forgalom kiszökött: ha a helyi feloldó válaszol, miközben az alagút áll, a blokk nem teljes.

4. ellenőrzés: a kivételeket a lezárás előtt döntse el

Két kivétel szerkezeti. Az ügyfélnek magához a VPN-kiszolgálóhoz el kell jutnia, ezért a mindent eldobó szabálykészlet az újracsatlakozást is megakadályozza, amely helyreállítaná a védelmet. Captive portal sem érhető el olyan alagúton, amely nem áll, ezért a hotel Wi-Fi-jén lezárt eszköznek dokumentált módja kell a portál megnyitására, nem rögtönzött.

Minimális forma, a végpont engedélyezve, minden más eldobva:

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

A végpont sort változóként kezelje, ne állandóként. A szolgáltatók címeket cserélnek, és az elavult kivétel a szokásos oka annak, hogy egy működő kill switch olyan eszközzé válik, amely nem tud újracsatlakozni. A helyi nyomtatók, NAS-megosztások és fejlesztői szolgáltatások ugyanarra az írott listára tartoznak, különben egyenként, támogatási jegyek során derülnek ki.

5. ellenőrzés: jegyezze fel, mit bizonyított valójában

Vezessen négyoszlopos táblázatot, és teszteléssel töltse ki: állapot, elvárt viselkedés, megfigyelt viselkedés, bizonyíték. A sorok a 3. ellenőrzés átmenetei plusz egy szándékos hiba. Az a sor, amelyet nem tud parancskimenettel kitölteni, olyan sor, amelyet nem tesztelt, és az az eszköz, amely átmegy az újracsatlakozási soron, de elbukik a rendszerindításin, elég gyakori ahhoz, hogy megérje a plusz tíz percet.

Mielőtt késznek nevezi:

• Erősítse meg, hogy a blokkoló beállítás külön van az újracsatlakozási beállítástól, és olvassa ki az értékét az eszközön.
• Tudja, melyik réteg kényszeríti ki a blokkot - ügyfélopció, eszközházirend vagy tűzfal -, és hol konfigurálják azt a réteget.
• Tartson meg egy próbaparancsot, amely bizonyítja a blokkot, és átmenet közben futtassa, ne utána.
• Írja le a kivétellistát, a végponttal együtt, és jegyezze fel, ki frissíti.
• Felügyelt hardveren hagyja békén a kikényszerített házirendet; a blokk eltávolítása a követelményt változtatja meg, nem az alagutat javítja.