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

Always-on i kill switch stoje na dve linije razmaka na istom ekranu podešavanja, pa ih ljudi čitaju kao dva imena za jednu funkciju. Nisu. Always-on je politika ponovnog povezivanja: pokreni tunel pri podizanju sistema, vrati ga posle pada ili promene mreže i nastavi da pokušavaš dok ne uspe. Kill switch je politika saobraćaja: imenuje pakete koji ipak smeju da napuste mašinu dok je tunel dole. Prvo možete uključiti bez drugog, a na većini platformi podrazumevani rezultat i dalje pušta saobraćaj napolje u tom procepu.

Provera 1: da li je blokada poseban prekidač?

Na Androidu 10 i novijem sačuvani VPN profil otvara dva nezavisna 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 zaista vraća posle prekida, a svaka aplikacija usred zahteva može da dođe na mrežu preko Wi-Fi ili mobilnih podataka dok se to ne dogodi.

Upravljani uređaji zadržavaju istu podelu u API-ju politika. 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 retko pokazuje tu razliku.

Stanje čitajte sa 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 prva vrati null, nijedan paket nije nametnut na nivou platforme; ako druga vrati 0, platforma ništa ne blokira. Androidov vodič za VPN opisuje to kao odvojene mogućnosti, a ne jedan režim.

Provera 2: koji sloj drži blokadu?

Nalepnice žive u klijentu, a blokade obično u zaštitnom zidu, zato ista reč na svakoj platformi znači nešto drugo. Redovi ispod su oni koje vredi potvrditi pre nego što poverujete bilo kome od njih.

Windows je najjasniji primer nalepnice koja ne blokira. Tamo Always On opisuje postojanost tunela: tunel uređaja za proveru identiteta mašine i korisnički tunel za prijavljeni nalog, 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 podrazumevano, pa prenosnik na Wi-Fi-ju nastavlja da radi dok je VPN dole.

WireGuard se deli na isti način, ali po klijentu. WireGuard for Windows ima opciju Block untunneled traffic po tunelu koja instalira 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 podrazumevana ruta ponovo preuzima bez ijednog izgubljenog paketa.

Na Apple platformama always-on dolazi kao funkcija profila upravljanja za nadzirane uređaje i izražava se pravilima on-demand, a ne potvrdnim poljem. Pitanje na koje treba odgovoriti iz korisnog tereta je da li neuspeli tunel zabranjuje saobraćaj ili samo traži drugu vezu. Naslov menija vam to neće reći.

Provera 3: merite procep, ne ikonu

Četiri prelaza su važna i padaju na različite načine: podizanje pre nego što se bilo ko prijavi, spavanje i buđenje, prelazak sa Wi-Fi na mobilne podatke i pad klijenta koji ostavlja interfejs tunela napola konfigurisan. Čisto ponovno povezivanje na jednom od njih ne dokazuje ništa o ostala tri.

Najjeftiniji test namerno zaustavlja tunel i zatim pokušava da izađe. Dok je tunel dole, 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 interfejs koji bi nosio paket, što je obično informativnije od ikone u traci, a systemctl status wg-quick@wg0 pokazuje da li je interfejs uredno uklonjen.

Pokrenite istu proveru u drugom prozoru dok se mreža menja, ne samo posle njenog smirivanja. Razmak između pada i novog pokušaja je ono što je važno, a razrešavanje imena je najbrži način da primetite da je saobraćaj pobegao: ako lokalni razrešivač odgovara dok je tunel dole, blokada nije potpuna.

Provera 4: odlučite o izuzecima pre nego što zaključate

Dva izuzetka su strukturna. Klijent mora da dođe do samog VPN servera, pa skup pravila koji odbacuje sve sprečava i ponovno povezivanje 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 dokumentovan način da otvori portal, a ne improvizovan.

Minimalni oblik, krajnja tačka dozvoljena 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
  }
}

Tretirajte tu liniju krajnje tačke kao promenljivu, a ne konstantu. Provajderi menjaju adrese, a zastareo izuzetak je uobičajen razlog zašto funkcionalan kill switch postane uređaj koji ne može ponovo da se poveže. Lokalni štampači, NAS deljenja i razvojne usluge pripadaju istom zapisanom spisku, inače se otkrivaju jedan po jedan zahtev podrške.

Provera 5: zapišite šta ste zaista dokazali

Vodite tabelu sa četiri kolone i punite je testiranjem: stanje, očekivano ponašanje, opaženo ponašanje, dokaz. Redovi su prelazi iz provere 3 plus jedan namerni kvar. Red koji ne možete da ispunite izlazom komande je red koji niste isprobali, a uređaj koji prolazi red ponovnog povezivanja i pada na redu podizanja dovoljno je čest da opravda dodatnih deset minuta.

Pre nego što to proglasite gotovim:

• Potvrdite da je podešavanje blokade odvojeno od podešavanja ponovnog povezivanja i pročitajte njegovu vrednost na uređaju.
• Znajte koji sloj sprovodi blokadu - opcija klijenta, politika uređaja ili zaštitni zid - i gde se taj sloj konfiguriše.
• Sačuvajte jednu probnu komandu koja dokazuje blokadu i pokrenite je tokom prelaza, a ne posle.
• Zapišite spisak izuzetaka, uključujući krajnju tačku, i zabeležite ko ga osvežava.
• Na upravljanom hardveru ostavite nametnutu politiku na miru; uklanjanje blokade menja zahtev umesto da popravi tunel.