Always-on VPN aŭ kill switch: kiun vi vere ebligis?

Always-on kaj kill switch staras du liniojn dise en la sama agorda ekrano, do homoj legas ilin kiel du nomojn de unu funkcio. Ili ne estas. Always-on estas politiko de rekonekto: startigi la tunelon ĉe lanĉo, revenigi ĝin post paneo aŭ reta ŝanĝo, kaj daŭre provi dum ĝi malsukcesas. Kill switch estas politiko de trafiko: ĝi nomas la pakaĵojn, kiuj ankoraŭ rajtas forlasi la maŝinon dum la tunelo estas malaktiva. Vi povas ŝalti la unuan sen la dua, kaj sur la plej multaj platformoj la defaŭlta rezulto ankoraŭ lasas trafikon eliri dum la paŭzo.

Kontrolo 1: ĉu la blokado estas propra ŝaltilo?

Sur Android 10 kaj poste, konservita VPN-profilo malfermas malantaŭ la dentrada ikono du sendependajn ŝaltilojn: Always-on VPN kaj Bloki konektojn sen VPN. Nur la dua estas la kill switch. Kun nur always-on la tunelo revenas post falo, sed iu ajn aplikaĵo meze de peto atingas la reton per Wi-Fi aŭ poŝaj datumoj ĝis tio okazos.

Administrataj aparatoj tenas la saman dividon en la politika API. setAlwaysOnVpnPackage() prenas la pakaĵan nomon kaj flagon lockdownEnabled; administranto, kiu starigas la pakaĵon kaj lasas la flagon malvera, konstruis daŭran tunelon, ne fermitan aparaton. La vortigo de la konzolo malofte montras tiun diferencon.

Legu la staton de la aparato, ne de la konzolo: adb shell settings get global always_on_vpn_app kaj adb shell settings get global always_on_vpn_lockdown. Se la unua redonas null, neniu pakaĵo estas trudata ĉe platforma nivelo; se la dua redonas 0, la platformo blokas nenion. La gvidilo pri VPN de Android priskribas ilin kiel apartajn kapablojn, ne kiel unu reĝimon.

Kontrolo 2: kiu tavolo posedas la blokadon?

Etikedoj vivas en la kliento kaj blokadoj kutime en la fajroŝirmilo, tial la sama vorto signifas malsamajn aferojn sur ĉiu platformo. La subaj vicoj indas konfirmon antaŭ ol fidi iun ajn el ili.

Windows estas la plej klara ekzemplo de etikedo, kiu ne blokas. Always On tie priskribas la daŭron de la tunelo: aparata tunelo por maŝina aŭtentigo, uzanta tunelo por la ensalutinta konto, agorditaj per profila XML aŭ Add-VpnConnection. Nenio en tiu profilo haltigas elirantan pakaĵon kiam la tunelo mankas, kaj elira filtrado ne estas ŝaltita defaŭlte, do tekkomputilo sur Wi-Fi daŭre funkcias dum la VPN estas malaktiva.

WireGuard dividiĝas same, sed laŭ kliento. WireGuard por Windows havas elekton por ĉiu tunelo, Bloki trafikon ekster la tunelo, kiu instalas filtrajn regulojn; la Linuxa ilaro havas nenian tian ŝaltilon. wg-quick aldonas itineron por ĉiu AllowedIPs-ero plus regulon fwmark, kaj wg-quick down forigas ambaŭ, do la fizika defaŭlta itinero denove transprenas sen perdita pakaĵo intere.

Sur Apple-platformoj always-on venas kiel funkcio de administra profilo por observataj aparatoj kaj esprimiĝas kiel reguloj laŭ postulo, ne kiel markobutono. La demando el la ŝarĝo estas, ĉu malsukcesa tunelo rifuzas trafikon aŭ nur petas alian konekton. La menuo ne diros tion.

Kontrolo 3: mezuru la paŭzon, ne la ikonon

Kvar transiroj gravas, kaj ili malsukcesas malsame: lanĉo antaŭ ol iu ensalutas, dormo kaj vekiĝo, ŝanĝo de Wi-Fi al poŝaj datumoj, kaj klienta paneo, kiu lasas la tunelan interfacon duonagordita. Pura rekonekto ĉe unu el ili pruvas nenion pri la aliaj tri.

La plej malmultekosta testo haltigas la tunelon intence kaj poste provas eliri. Kun la tunelo malsupre, curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com redonanta 200 signifas, ke la politiko estas fail-open; tempolimo aŭ rifuzita konekto signifas, ke io ankoraŭ blokas. ip route get 1.1.1.1 nomas la interfacon, kiu portus la pakaĵon, kio kutime diras pli ol la pleto-ikono, kaj systemctl status wg-quick@wg0 montras, ĉu la interfaco estis pure forigita.

Runu la saman teston en dua fenestro dum la reto ŝanĝiĝas, ne nur poste. La intervalo inter la falo kaj la nova provo estas la grava parto, kaj nom-serĉo estas la plej rapida rimedo rimarki, ke trafiko eskapis: se la loka solvilo respondas dum la tunelo estas malsupre, la blokado ne estas kompleta.

Kontrolo 4: decidu la esceptojn antaŭ ol ŝlosi

Du esceptoj estas strukturaj. La kliento devas atingi la VPN-servilon mem, do regularo, kiu forĵetas ĉion, ankaŭ malhelpas la rekonekton, kiu restarigus la protekton. Captive-pordego ankaŭ ne atingeblas tra tunelo, kiu ne staras, do ŝlosita aparato sur hotela Wi-Fi bezonas dokumentitan manieron malfermi la pordegon, ne improvizitan.

Minimuma formo, finpunkto permesita kaj ĉio alia forĵetita:

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

Traktu tiun finpunktan linion kiel variablon, ne kiel konstanton. Provizantoj ŝanĝas adresojn, kaj eksmoda escepto estas la kutima kaŭzo, ke funkcianta kill switch fariĝas aparato, kiu ne povas rekonekti. Lokaj printiloj, NAS-kunhavoj kaj evoluigaj servoj apartenas al la sama skribita listo, alie ili malkovriĝas unu subtenbileto post la alia.

Kontrolo 5: notu, kion vi vere pruvis

Tenu tabelon kun kvar kolumnoj kaj plenigu ĝin per testado: stato, atendata konduto, observita konduto, pruvo. La vicoj estas la transiroj el kontrolo 3 plus unu intenca malsukceso. Vico, kiun vi ne povas plenigi per komanda eligo, estas vico, kiun vi ne testis, kaj aparato, kiu pasas la rekonektan vicon kaj malsukcesas ĉe la lanĉa, estas sufiĉe ofta por meriti la kromajn dek minutojn.

Antaŭ ol nomi ĝin preta:

• Konfirmu, ke la bloka agordo estas aparta de la rekonekta agordo, kaj legu ĝian valoron sur la aparato.
• Sciu, kiu tavolo plenumas la blokadon - klienta elekto, aparata politiko aŭ fajroŝirmilo - kaj kie tiu tavolo agordiĝas.
• Tenu unu testan komandon, kiu pruvas la blokadon, kaj rulu ĝin dum transiro, ne poste.
• Skribu la esceptan liston, kun la finpunkto, kaj notu, kiu ĝisdatigas ĝin.
• Sur administrata aparataro lasu la truditan politikon; forigi la blokadon ŝanĝas la postulon anstataŭ ripari la tunelon.