Always-on VPN alebo kill switch: čo ste vlastne zapnuli?

Always-on a kill switch sedia dve riadky od seba na tej istej obrazovke nastavení, preto ich ľudia čítajú ako dva názvy jednej funkcie. Nie sú. Always-on je politika opätovného pripojenia: spusti tunel pri štarte, vráť ho po páde alebo zmene siete a skúšaj ďalej, kým zlyháva. Kill switch je politika premávky: pomenúva pakety, ktoré ešte smú opustiť stroj, kým tunel chýba. Prvé môžete zapnúť bez druhého a na väčšine platforiem predvolený výsledok aj tak púšťa premávku von v tej medzere.

Kontrola 1: je blokovanie samostatný prepínač?

Na Androide 10 a novšom uložený profil VPN otvára za ikonou ozubeného kolesa dva nezávislé prepínače: Always-on VPN a Block connections without VPN. Kill switch je len druhý. S jediným always-on sa tunel po páde naozaj vráti, a každá aplikácia uprostred požiadavky sa do siete dostane cez Wi-Fi alebo mobilné dáta, kým sa tak stane.

Spravované zariadenia si držia rovnaké rozdelenie v API politík. setAlwaysOnVpnPackage() preberá názov balíka a príznak lockdownEnabled; správca, ktorý balík nastaví a príznak nechá na false, postavil trvalý tunel, nie uzavreté zariadenie. Formulácie v konzole túto rozdiely málokedy ukážu.

Stav čítajte zo zariadenia, nie z konzoly: adb shell settings get global always_on_vpn_app a adb shell settings get global always_on_vpn_lockdown. Ak prvé vráti null, na úrovni platformy nie je vynútený žiadny balík; ak druhé vráti 0, platforma nič neblokuje. Sprievodca VPN pre Android ich opisuje ako oddelené schopnosti, nie ako jeden režim.

Kontrola 2: ktorá vrstva blokovanie vlastní?

Označenia žijú v klientovi a blokovania zvyčajne vo firewalle, preto to isté slovo na každej platforme znamená niečo iné. Riadky nižšie sú tie, ktoré sa oplatí potvrdiť, kým uveríte ktorémukoľvek z nich.

Windows je najjasnejší príklad označenia, ktoré neblokuje. Tam Always On opisuje trvalosť tunela: tunel zariadenia na autentifikáciu stroja a používateľský tunel pre prihlásený účet, nastavené cez XML profilu alebo Add-VpnConnection. Nič v tom profile nezastaví odchádzajúci paket, keď tunel chýba, a odchádzajúce filtrovanie nie je predvolene zapnuté, takže prenosný počítač na Wi-Fi funguje ďalej, kým VPN leží.

WireGuard sa delí rovnako, ale podľa klienta. WireGuard for Windows má možnosť Block untunneled traffic pre každý tunel, ktorá inštaluje pravidlá filtra; nástroje Linuxu taký prepínač nemajú. wg-quick pridáva trasu pre každý záznam AllowedIPs a pravidlo fwmark, a wg-quick down odstráni oboje, takže fyzická predvolená trasa znova preberá úlohu bez jediného strateného paketu.

Na platformách Apple prichádza always-on ako funkcia profilu správy pre sledované zariadenia a vyjadruje sa pravidlami on-demand, nie zaškrtávacím poľom. Otázka, na ktorú treba odpovedať z payloadu, je, či zlyhaný tunel odmieta premávku, alebo iba žiada iné spojenie. Názov ponuky vám to nepovie.

Kontrola 3: merajte medzeru, nie ikonu

Štyri prechody sú dôležité a každý zlyháva inak: štart predtým, než sa niekto prihlási, spánok a prebudenie, prechod z Wi-Fi na mobilné dáta a pád klienta, ktorý nechá rozhranie tunela napoly nakonfigurované. Čisté opätovné pripojenie na jednom z nich nič nedokazuje o ostatných troch.

Najlacnejší test úmyselne zastaví tunel a potom sa pokúsi vyjsť. Keď tunel leží, curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com vracajúce 200 znamená, že politika je fail-open; časový limit alebo odmietnuté spojenie znamenajú, že niečo ešte blokuje. ip route get 1.1.1.1 pomenúva rozhranie, ktoré by paket nieslo, čo je zvyčajne informatívnejšie než ikona v lište, a systemctl status wg-quick@wg0 ukazuje, či bolo rozhranie čisto odstránené.

Spustite tú istú kontrolu v druhom okne, kým sa sieť mení, nie až keď sa ustáli. Interval medzi pádom a novým pokusom je to podstatné a preklad názvov je najrýchlejší spôsob, ako si všimnúť, že premávka unikla: ak lokálny resolver odpovedá, kým tunel leží, blokovanie nie je úplné.

Kontrola 4: rozhodnite o výnimkách pred uzamknutím

Dve výnimky sú štrukturálne. Klient sa musí dostať k samotnému serveru VPN, takže sada pravidiel, ktorá zhadzuje všetko, bráni aj opätovnému pripojeniu, ktoré by vrátilo ochranu. Ani captive portál nie je dostupný cez tunel, ktorý nie je hore, takže uzamknuté zariadenie na hotelovom Wi-Fi potrebuje zdokumentovaný spôsob otvorenia portálu, nie improvizovaný.

Minimálna podoba, koncový bod povolený a všetko ostatné zhodené:

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

Ten riadok koncového bodu berte ako premennú, nie konštantu. Poskytovatelia menia adresy a zastaraná výnimka je obvyklý dôvod, prečo sa fungujúci kill switch zmení na zariadenie, ktoré sa nedokáže znova pripojiť. Lokálne tlačiarne, zdieľania NAS a vývojové služby patria na ten istý písaný zoznam, inak sa nachádzajú po jednom tikete podpory.

Kontrola 5: zapíšte, čo ste naozaj dokázali

Veďte tabuľku so štyrmi stĺpcami a napĺňajte ju testovaním: stav, očakávané správanie, pozorované správanie, dôkaz. Riadky sú prechody z kontroly 3 plus jedna úmyselná porucha. Riadok, ktorý nedokážete vyplniť výstupom príkazu, je riadok, ktorý ste netestovali, a zariadenie, ktoré prejde riadkom opätovného pripojenia a zlyhá v riadku štartu, je dosť časté na to, aby ospravedlnilo desať minút navyše.

Kým to vyhlásite za hotové:

• Potvrďte, že nastavenie blokovania je oddelené od nastavenia opätovného pripojenia, a prečítajte jeho hodnotu v zariadení.
• Vedzte, ktorá vrstva blokovanie presadzuje - možnosť klienta, politika zariadenia alebo firewall - a kde sa tá vrstva konfiguruje.
• Ponechajte jeden kontrolný príkaz, ktorý blokovanie dokazuje, a spúšťajte ho počas prechodu, nie po ňom.
• Zapíšte zoznam výnimiek vrátane koncového bodu a poznačte, kto ho obnovuje.
• Na spravovanom hardvéri nechajte vynútenú politiku na pokoji; odstránenie blokovania mení požiadavku namiesto opravy tunela.