Always-on VPN apo kill switch: çfarë aktivizuat në të vërtetë?
Always-on VPN rilidh tunelin; kill switch vendos çfarë mund të dalë pa të. Pesë kontrolle përpara se t'i besoni etiketës.
Always-on dhe kill switch ndodhen dy rreshta larg njëri-tjetrit në të njëjtin ekran cilësimesh, prandaj njerëzit i lexojnë si dy emra të një funksioni. Nuk janë. Always-on është një politikë rilidhjeje: nise tunelin gjatë boot-it, ktheje pas një rrëzimi ose një ndryshimi rrjeti dhe vazhdo të provosh sa kohë dështon. Kill switch është një politikë trafiku: emërton paketat që mund të largohen ende nga makina ndërsa tuneli është poshtë. Mund të aktivizosh të parin pa të dytin, dhe në shumicën e platformave rezultati i parazgjedhur lë akoma trafik të dalë në atë boshllëk.
Kontrolli 1: a është bllokimi një çelës më vete?
Në Android 10 e më pas, një profil VPN i ruajtur hap dy çelësa të pavarur pas ikonës së ingranazhit: Always-on VPN dhe Block connections without VPN. Vetëm i dyti është kill switch. Me vetëm always-on tuneli vërtet kthehet pas një ndërprerjeje, dhe çdo aplikacion në mes të një kërkese mund të arrijë rrjetin përmes Wi-Fi ose të dhënave celulare derisa kjo të ndodhë.
Pajisjet e menaxhuara e mbajnë të njëjtën ndarje në API-n e politikave. setAlwaysOnVpnPackage() merr emrin e paketës dhe një flag lockdownEnabled; një administrator që vendos paketën dhe e lë flagun false ka ndërtuar një tunel të përhershëm, jo një pajisje të mbyllur. Formulimi në konsolë rrallë e bën të dukshme atë dallim.
Lexo gjendjen nga pajisja, jo nga konsola: adb shell settings get global always_on_vpn_app dhe adb shell settings get global always_on_vpn_lockdown. Nëse i pari kthen null, asnjë paketë nuk imponohet në nivel platforme; nëse i dyti kthen 0, platforma nuk po bllokon asgjë. Udhëzuesi i VPN për Android i përshkruan këto si aftësi të veçanta, jo si një modalitet.
Kontrolli 2: cila shtresë e zotëron bllokimin?
Etiketat jetojnë në klient dhe bllokimet zakonisht në firewall, prandaj e njëjta fjalë do të thotë gjë tjetër në çdo platformë. Rreshtat më poshtë janë ata që ia vlen të konfirmohen përpara se t'i besosh ndonjërit prej tyre.
| Where you see the label | What the label promises | What actually blocks |
|---|---|---|
| Android VPN profile | Always-on VPN | Block connections without VPN |
| Android device policy | Always-on package | lockdownEnabled flag |
| Windows built-in VPN | Always On tunnel | Outbound firewall rules |
| WireGuard for Windows | Tunnel service | Block untunneled traffic option |
| wg-quick on Linux | Route via AllowedIPs | Your own nftables or iptables rules |
Windows është shembulli më i qartë i një etikete që nuk bllokon. Atje Always On përshkruan këmbënguljen e tunelit: një tunel pajisjeje për autentikimin e makinës dhe një tunel përdoruesi për llogarinë e hyrë, të konfiguruar përmes XML të profilit ose Add-VpnConnection. Asgjë në atë profil nuk ndalon një paketë dalëse kur tuneli mungon, dhe filtrimi dalës nuk është i aktivizuar si parazgjedhje, prandaj një laptop në Wi-Fi vazhdon të punojë ndërsa VPN-ja është poshtë.
WireGuard ndahet në të njëjtën mënyrë, por sipas klientit. WireGuard for Windows ka opsionin Block untunneled traffic për çdo tunel që instalon rregulla filtri; mjetet e Linux nuk kanë një çelës të tillë. wg-quick shton një rrugë për çdo zë AllowedIPs plus një rregull fwmark, dhe wg-quick down i heq të dyja, kështu që rruga fizike e parazgjedhur merr përsëri përsipër pa humbur asnjë paketë.
Në platformat Apple, always-on vjen si funksion i profilit të menaxhimit për pajisje të mbikëqyrura dhe shprehet si rregulla on-demand, jo si kuti shënimi. Pyetja që duhet përgjigjur nga payload-i është nëse një tunel i dështuar e mohon trafikun apo thjesht kërkon një lidhje tjetër. Titulli i menysë nuk do t'jua thotë.
Kontrolli 3: matni boshllëkun, jo ikonën
Katër kalime kanë rëndësi dhe secili dështon ndryshe: boot-i përpara se dikush të hyjë, gjumi dhe zgimi, kalimi nga Wi-Fi në të dhëna celulare dhe një rrëzim klienti që e lë ndërfaqen e tunelit gjysmë të konfiguruar. Një rilidhje e pastër në njërin prej tyre nuk provon asgjë për tre të tjerët.
Testi më i lirë e ndalon tunelin me qëllim dhe më pas provon të dalë. Kur tuneli është poshtë, curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com që kthen 200 do të thotë që politika është fail-open; një kohë e skaduar ose një lidhje e refuzuar do të thotë që diçka po bllokon ende. ip route get 1.1.1.1 emërton ndërfaqen që do të mbante paketën, që zakonisht është më informuese se ikona në tray, dhe systemctl status wg-quick@wg0 tregon nëse ndërfaqja u hoq pastër.
Vraponi të njëjtin kontroll në një dritare të dytë ndërsa rrjeti po ndryshon, jo vetëm pasi të qetësohet. Intervali midis rrëzimit dhe provës së re është pjesa që ka rëndësi, dhe zgjidhja e emrave është mënyra më e shpejtë për të vënë re se trafiku shpëtoi: nëse zgjidhësi lokal përgjigjet ndërsa tuneli është poshtë, bllokimi nuk është i plotë.
Kontrolli 4: vendosni përjashtimet përpara se të kyçni
Dy përjashtime janë strukturore. Klienti duhet të arrijë vetë serverin VPN, prandaj një grup rregullash që hedh gjithçka pengon edhe rilidhjen që do të kthente mbrojtjen. As captive portal nuk arrihet përmes një tuneli që nuk është ngritur, prandaj një pajisje e kyçur në Wi-Fi hoteli ka nevojë për një mënyrë të dokumentuar për të hapur portalin, jo të improvizuar.
Një formë minimale, pika fundore e lejuar dhe çdo gjë tjetër e hedhur:
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
}
}
Trajtojeni atë rresht të pikës fundore si ndryshore, jo si konstante. Ofruesit rrotullojnë adresa, dhe një përjashtim i vjetruar është arsyeja e zakonshme pse një kill switch që punon bëhet një pajisje që nuk rilidhet dot. Printerat lokalë, shpërndarjet NAS dhe shërbimet e zhvillimit i përkasin të njëjtës listë të shkruar, përndryshe zbulohen një biletë suporti në herë.
Kontrolli 5: shënoni çfarë provuat vërtet
Mbani një tabelë me katër kolona dhe mbushni duke testuar: gjendje, sjellje e pritur, sjellje e vëzhguar, provë. Rreshtat janë kalimet nga kontrolli 3 plus një dështim i qëllimshëm. Një rresht që nuk mund ta mbushni me daljen e komandës është një rresht që nuk e keni testuar, dhe një pajisje që kalon rreshtin e rilidhjes dhe dështon në rreshtin e boot-it është mjaft e zakonshme sa ia vlen dhjetë minutat shtesë.
Përpara se ta quani të kryer:
- Konfirmoni që cilësimi i bllokimit është i veçantë nga ai i rilidhjes dhe lexoni vlerën e tij në pajisje.
- Dijeni cila shtresë e zbaton bllokimin - opsioni i klientit, politika e pajisjes ose firewall-i - dhe ku konfigurohet ajo shtresë.
- Mbani një komandë kontrolli që provon bllokimin dhe vrapojeni gjatë një kalimi, jo pas tij.
- Shkruani listën e përjashtimeve, duke përfshirë pikën fundore, dhe shënoni kush e rifreskon.
- Në hardware të menaxhuar lini politikën e imponuar të qetë; heqja e bllokimit ndryshon kërkesën në vend që të rregullojë tunelin.