Always-on VPN ili kill switch: što ste zapravo uključili?

Always-on i kill switch stoje dvije linije jedan od drugoga na istom zaslonu postavki, pa ih ljudi čitaju kao dva naziva za jednu značajku. Nisu. Always-on je politika ponovnog spajanja: pokreni tunel pri podizanju sustava, vrati ga nakon pada ili promjene mreže i nastavi pokušavati dok ne uspije. Kill switch je prometna politika: imenuje pakete koji ipak smiju napustiti računalo dok je tunel pao. Prvi možete uključiti bez drugoga, a na većini platformi zadani rezultat i dalje pušta promet van tijekom te praznine.

Provjera 1: je li blokada zaseban prekidač?

Na Androidu 10 i novijem spremljeni VPN profil otvara dva neovisna prekidača iza ikone zupčanika: Always-on VPN i Block connections without VPN. Samo je drugi kill switch. Uz samo always-on tunel se doista vraća nakon pada, a svaka aplikacija usred zahtjeva može doći na mrežu preko Wi-Fi ili mobilnih podataka dok se to ne dogodi.

Upravljani uređaji zadržavaju istu podjelu u API-ju politike. setAlwaysOnVpnPackage() prima naziv paketa i zastavicu lockdownEnabled; administrator koji postavi paket i ostavi zastavicu na false izgradio je trajni tunel, a ne zatvoren uređaj. Tekst u konzoli rijetko pokazuje tu razliku.

Stanje čitajte s uređaja, ne iz konzole: adb shell settings get global always_on_vpn_app i adb shell settings get global always_on_vpn_lockdown. Ako prvi vrati null, nijedan paket nije nametnut na razini platforme; ako drugi vrati 0, platforma ništa ne blokira. Androidov vodič za VPN opisuje to kao odvojene mogućnosti, a ne jedan način rada.

Provjera 2: koji sloj drži blokadu?

Oznake žive u klijentu, a blokade obično u vatrozidu, zato ista riječ na svakoj platformi znači nešto drugo. Donji su redci oni koje vrijedi potvrditi prije nego povjerujete bilo kojemu.

Windows je najjasniji primjer oznake koja ne blokira. Tamo Always On opisuje postojanost tunela: tunel uređaja za provjeru identiteta stroja i korisnički tunel za prijavljeni račun, postavljen kroz XML profila ili Add-VpnConnection. Ništa u tom profilu ne zaustavlja odlazni paket kad tunela nema, a odlazno filtriranje nije uključeno po zadanome, pa prijenosnik na Wi-Fi mreži nastavlja raditi dok je VPN pao.

WireGuard se dijeli na isti način, ali po klijentu. WireGuard for Windows ima opciju Block untunneled traffic po tunelu koja postavlja pravila filtriranja; Linux alati nemaju takav prekidač. wg-quick dodaje rutu za svaki unos AllowedIPs plus pravilo fwmark, a wg-quick down uklanja oboje, pa fizička zadana ruta ponovno preuzima bez ijednog ispuštenog paketa.

Na Appleovim platformama always-on dolazi kao značajka profila upravljanja za nadzirane uređaje i izražava se pravilima on-demand, a ne potvrdnim okvirom. Pitanje na koje treba odgovoriti iz korisnog tereta jest zabranjuje li neuspjeli tunel promet ili samo traži drugu vezu. Naslov izbornika to vam neće reći.

Provjera 3: mjerite prazninu, ne ikonu

Četiri prijelaza su važna i padaju na različite načine: podizanje prije nego se bilo tko prijavi, spavanje i buđenje, prelazak s Wi-Fi na mobilne podatke i pad klijenta koji ostavlja sučelje tunela napola konfigurirano. Čisto ponovno spajanje na jednom od njih ne dokazuje ništa o ostala tri.

Najjeftiniji test namjerno zaustavlja tunel i zatim pokušava izaći. Dok je tunel pao, curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com koji vrati 200 znači da je politika fail-open; istek vremena ili odbijena veza znači da nešto još blokira. ip route get 1.1.1.1 imenuje sučelje koje bi nosilo paket, što je obično informativnije od ikone u traci, a systemctl status wg-quick@wg0 pokazuje je li sučelje uredno uklonjeno.

Pokrenite istu provjeru u drugom prozoru dok se mreža mijenja, ne samo nakon što se smiri. Razmak između pada i ponovnog pokušaja je ono što je važno, a razrješavanje naziva najbrži je način da primijetite da je promet pobjegao: ako lokalni razrješivač odgovara dok je tunel pao, blokada nije potpuna.

Provjera 4: odlučite o iznimkama prije nego zaključate

Dvije su iznimke strukturalne. Klijent mora doći do samog VPN poslužitelja, pa skup pravila koji odbacuje sve sprječava i ponovno spajanje koje bi vratilo zaštitu. Ni captive portal nije dostupan kroz tunel koji nije podignut, pa zaključan uređaj na hotelskom Wi-Fi-ju treba dokumentiran način otvaranja portala, a ne improviziran.

Minimalni oblik, krajnja točka dopuštena i sve ostalo odbačeno:

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

Tu liniju krajnje točke tretirajte kao varijablu, a ne konstantu. Davatelji mijenjaju adrese, a zastarjela iznimka uobičajen je razlog zašto funkcionalan kill switch postane uređaj koji se ne može ponovno spojiti. Lokalni pisači, NAS dijeljenja i razvojne usluge pripadaju istom zapisanom popisu, inače se otkrivaju jedan po jedan zahtjev podrške.

Provjera 5: zapišite što ste doista dokazali

Vodite tablicu s četiri stupca i punite je testiranjem: stanje, očekivano ponašanje, opaženo ponašanje, dokaz. Redci su prijelazi iz provjere 3 plus jedan namjerni kvar. Redak koji ne možete ispuniti izlazom naredbe redak je koji niste isprobali, a uređaj koji prolazi redak ponovnog spajanja i pada na retku podizanja dovoljno je čest da opravda dodatnih deset minuta.

Prije nego što to proglasite gotovim:

• Potvrdite da je postavka blokiranja odvojena od postavke ponovnog spajanja i pročitajte njezinu vrijednost na uređaju.
• Znajte koji sloj provodi blokadu - opcija klijenta, politika uređaja ili vatrozid - i gdje se taj sloj konfigurira.
• Zadržite jednu probnu naredbu koja dokazuje blokadu i pokrenite je tijekom prijelaza, a ne poslije.
• Zapišite popis iznimki, uključujući krajnju točku, i zabilježite tko ga osvježava.
• Na upravljanom hardveru ostavite nametnutu politiku na miru; uklanjanje blokade mijenja zahtjev umjesto da popravi tunel.