Always-on VPN nebo kill switch: co jste vlastně zapnuli?

Always-on a kill switch stojí na stejné obrazovce nastavení dvě řádky od sebe, takže je lidé čtou jako dvě jména jedné funkce. Nejsou. Always-on je politika opětovného připojení: spustí tunel při bootu, vrátí ho po pádu nebo změně sítě a zkouší to dál, dokud se nedaří. Kill switch je politika provozu: pojmenovává pakety, které ještě mohou opustit stroj, když tunel neběží. První můžete zapnout bez druhého a na většině platforem výchozí výsledek během mezery provoz stále pustí.

Kontrola 1: je blokace vlastní přepínač?

Na Androidu 10 a novějším otevře uložený profil VPN za ikonou ozubeného kola dva nezávislé přepínače: Always-on VPN a Blokovat připojení bez VPN. Jen druhý je kill switch. S pouhým always-on se tunel po výpadku vrátí, ale kterákoli aplikace uprostřed požadavku se do té doby dostane na síť přes Wi-Fi nebo mobilní data.

Spravovaná zařízení drží stejné rozdělení v API zásad. setAlwaysOnVpnPackage() bere název balíčku a příznak lockdownEnabled; kdo balíček nastaví a příznak nechá nepravdivý, postavil trvalý tunel, ne uzavřené zařízení. Formulace v konzoli ten rozdíl málokdy ukáže.

Čtěte stav ze zařízení, ne z konzole: adb shell settings get global always_on_vpn_app a adb shell settings get global always_on_vpn_lockdown. Vrátí-li první null, není na úrovni platformy vynucen žádný balíček; vrátí-li druhý 0, platforma nic neblokuje. Průvodce VPN pro Android popisuje tyto jako oddělené schopnosti, ne jeden režim.

Kontrola 2: která vrstva blokaci vlastní?

Označení žijí v klientu a blokace obvykle ve firewallu, proto stejné slovo na každé platformě znamená něco jiného. Řádky níže stojí za potvrzení, než některému uvěříte.

Windows je nejjasnější příklad označení, které neblokuje. Always On tam popisuje trvalost tunelu: tunel zařízení pro autentizaci stroje, uživatelský tunel pro přihlášený účet, konfigurované přes XML profilu nebo Add-VpnConnection. Nic v tom profilu nezastaví odchozí paket, když tunel chybí, a odchozí filtrování není ve výchozím stavu zapnuté, takže notebook na Wi-Fi pracuje dál, i když je VPN dole.

WireGuard se dělí stejně, ale podle klienta. WireGuard pro Windows má volbu pro každý tunel Blokovat provoz mimo tunel, která instaluje pravidla filtru; linuxové nástroje takový přepínač nemají. wg-quick přidá trasu pro každý záznam AllowedIPs plus pravidlo fwmark a wg-quick down obojí odstraní, takže fyzická výchozí trasa převezme znovu bez ztraceného paketu mezi tím.

Na platformách Apple přichází always-on jako funkce profilu správy pro sledovaná zařízení a vyjadřuje se pravidly na vyžádání, ne zaškrtávacím políčkem. Otázka z obsahu zní, zda neúspěšný tunel provoz odmítá, nebo jen žádá jiné připojení. Nadpis nabídky to neřekne.

Kontrola 3: měřte mezeru, ne ikonu

Čtyři přechody jsou důležité a selhávají různě: start, než se někdo přihlásí, spánek a probuzení, změna z Wi-Fi na mobilní data a pád klienta, který nechá rozhraní tunelu napůl nakonfigurované. Čisté opětovné připojení u jednoho nic nedokazuje o ostatních třech.

Nejlevnější test tunel schválně zastaví a pak zkusí odejít. Když tunel neběží, curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com s návratem 200 znamená, že zásada je fail-open; vypršení nebo odmítnuté spojení znamená, že něco ještě blokuje. ip route get 1.1.1.1 pojmenuje rozhraní, které by paket neslo, což obvykle řekne víc než ikona v oznamovací oblasti, a systemctl status wg-quick@wg0 ukáže, zda bylo rozhraní čistě odstraněno.

Pusťte stejnou zkoušku v druhém okně, zatímco se síť mění, ne až potom. Interval mezi výpadkem a novým pokusem je to podstatné a přeložení jména je nejrychlejší způsob, jak si všimnout uniklého provozu: odpovídá-li lokální resolver, když je tunel dole, blokace není úplná.

Kontrola 4: rozhodněte výjimky, než zamknete

Dvě výjimky jsou strukturální. Klient musí dosáhnout samotného serveru VPN, takže sada pravidel, která zahodí vše, brání i opětovnému připojení, jež by obnovilo ochranu. Captive portál také není dostupný tunelem, který nestojí, takže zamčené zařízení na hotelové Wi-Fi potřebuje zdokumentovanou cestu k otevření portálu, ne improvizovanou.

Minimální tvar, koncový bod povolen a vše ostatní zahozeno:

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
  }
}

Berte ten řádek koncového bodu jako proměnnou, ne konstantu. Poskytovatelé rotují adresy a zastaralá výjimka je obvyklý důvod, proč se funkční kill switch změní v zařízení, které se nedokáže připojit. Místní tiskárny, sdílení NAS a vývojové služby patří do stejného psaného seznamu, jinak se objevují po jednom tiketu podpory.

Kontrola 5: zapište, co jste skutečně prokázali

Veďte tabulku se čtyřmi sloupci a plňte ji testováním: stav, očekávané chování, pozorované chování, důkaz. Řádky jsou přechody z kontroly 3 plus jeden úmyslný neúspěch. Řádek, který neumíte vyplnit výstupem příkazu, je řádek, který jste netestovali, a zařízení, které projde řádkem opětovného připojení a selže na řádku startu, je dost časté, aby stálo za těch deset minut navíc.

Než to prohlásíte za hotové:

• Potvrďte, že nastavení blokace je oddělené od nastavení opětovného připojení, a přečtěte jeho hodnotu na zařízení.
• Vězte, která vrstva blokaci vynucuje - volba klienta, zásada zařízení nebo firewall - a kde se ta vrstva konfiguruje.
• Držte jeden zkušební příkaz, který blokaci prokáže, a spouštějte ho během přechodu, ne po něm.
• Zapište seznam výjimek, včetně koncového bodu, a poznamenejte, kdo ho obnovuje.
• Na spravovaném hardwaru nechte vynucenou zásadu být; odebrání blokace mění požadavek, místo aby opravilo tunel.