Always-on en kill switch staan twee reels uitmekaar in dieselfde instellings, so mense lees hulle as twee name vir een funksie. Dit is nie. Always-on is n herverbindingsbeleid: begin die tonnel by selflaai, bring hom terug na n ineenstorting of netwerkverandering, en hou aan probeer terwyl dit misluk. n Kill switch is n verkeersbeleid: dit noem die pakkette wat die masjien nog mag verlaat terwyl die tonnel af is. Jy kan die eerste sonder die tweede aktiveer, en op meeste platforms laat die standaard steeds verkeer uit in die gaping.

Kontrole 1: is die blok n skakelaar op sy eie?

Op Android 10 en later open n gestoorde VPN-profiel twee onafhanklike skakelaars agter die rat-ikoon: Always-on-VPN en Blokkeer verbindings sonder VPN. Net die tweede is die kill switch. Met net always-on kom die tonnel wel terug na n onderbreking, en enige program midde in n versoek bereik die netwerk oor Wi-Fi of mobiele data tot dit gebeur.

Bestuurde toestelle hou dieselfde skeiding in die beleids-API. setAlwaysOnVpnPackage() neem die pakketnaam en n lockdownEnabled-vlag; n administrateur wat die pakket stel en die vlag onwaar laat, het n blywende tonnel gebou, nie n geslote toestel nie. Die konsol se bewoording maak dit selde sigbaar.

Lees die toestand op die toestel, nie in die konsol nie: adb shell settings get global always_on_vpn_app en adb shell settings get global always_on_vpn_lockdown. Gee die eerste null terug, is geen pakket op platformvlak afgedwing nie; gee die tweede 0 terug, blokkeer die platform niks. Die Android-VPN-gids beskryf dit as aparte vermoens, nie as een modus nie.

Kontrole 2: watter laag besit die blok?

Etikette leef in die kliënt en blokke gewoonlik in die firewall, daarom beteken dieselfde woord op elke platform iets anders. Die rye hieronder is die moeite werd om te bevestig voordat jy enigeen vertrou.

Where you see the labelWhat the label promisesWhat actually blocks
Android VPN profileAlways-on VPNBlock connections without VPN
Android device policyAlways-on packagelockdownEnabled flag
Windows built-in VPNAlways On tunnelOutbound firewall rules
WireGuard for WindowsTunnel serviceBlock untunneled traffic option
wg-quick on LinuxRoute via AllowedIPsYour own nftables or iptables rules

Windows is die duidelikste voorbeeld van n etiket wat nie blokkeer nie. Always On beskryf daar tonnelvolharding: n toesteltonnel vir masjienverifikasie, n gebruikerstonnel vir die aangemelde rekening, opgestel deur profiel-XML of Add-VpnConnection. Niks in daardie profiel stop n uitgaande pakket wanneer die tonnel ontbreek nie, en uitgaande filtering is nie by verstek aan nie, so n skootrekenaar op Wi-Fi werk voort terwyl die VPN af is.

WireGuard splits dieselfde, maar per kliënt. WireGuard vir Windows het n opsie per tonnel, Blokkeer ongetonnelde verkeer, wat filterreels installeer; die Linux-gereedskap het geen ekwivalent nie. wg-quick voeg n roete by vir elke AllowedIPs-inskrywing plus n fwmark-reel, en wg-quick down verwyder albei, so die fisiese standaardroete neem weer oor sonder dat n pakket val.

Op Apple-platforms kom always-on as n bestuursprofiel-funksie vir toesigtoestelle en word as op-aanvraag-reels uitgedruk, nie as n merkblokkie nie. Die vraag uit die vrag is of n mislukte tonnel verkeer weier of net nog n verbinding vra. Die kieslys se titel sal dit nie se nie.

Kontrole 3: meet die gaping, nie die ikoon nie

Vier oorgange tel, en hulle misluk anders: selflaai voordat iemand aanmeld, slaap en hervat, n Wi-Fi na mobiele data verandering, en n kliënt-ineenstorting wat die tonnelkoppeling half-opgestel laat. n Skoon herverbinding op een daarvan bewys niks oor die ander drie nie.

Die goedkoopste toets stop die tonnel opsetlik en probeer dan uitgaan. Met die tonnel af beteken curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com wat 200 teruggee dat die beleid fail-open is; n time-out of n geweierde verbinding beteken iets blokkeer nog. ip route get 1.1.1.1 noem die koppeling wat die pakket sou dra, wat gewoonlik meer se as die taakbalk-ikoon, en systemctl status wg-quick@wg0 wys of die koppeling skoon verwyder is.

Hardloop dieselfde toets in n tweede venster terwyl die netwerk verander, nie net daarna nie. Die interval tussen die onderbreking en die herprobeerslag is die deel wat saak maak, en n naamsoektog is die vinnigste manier om te merk dat verkeer ontsnap het: as die plaaslike oplosser antwoord terwyl die tonnel af is, is die blok nie volledig nie.

Kontrole 4: besluit die uitsonderings voordat jy toesluit

Twee uitsonderings is struktureel. Die kliënt moet die VPN-bediener self bereik, so n reelstel wat alles laat val verhinder ook die herverbinding wat beskerming sou herstel. n Captive portal is ook nie deur n tonnel wat nie op is bereikbaar nie, so n geslote toestel op hotel-Wi-Fi het n gedokumenteerde manier nodig om die portaal oop te maak, nie n geimproviserde een nie.

n Minimale vorm, eindpunt toegelaat en alles anders laat val:

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

Behandel daardie eindpunt-reel as n veranderlike, nie n konstante nie. Verskaffers roteer adresse, en n verouderde uitsondering is die gewone rede waarom n werkende kill switch n toestel word wat nie kan herverbind nie. Plaaslike drukkers, NAS-aandele en ontwikkelingsdienste hoort in dieselfde geskrewe lys, anders word hulle een steuntjie op n slag ontdek.

Kontrole 5: teken op wat jy werklik bewys het

Hou n tabel met vier kolomme en vul dit deur te toets: toestand, verwagte gedrag, waargeneemde gedrag, bewys. Die rye is die oorgange uit kontrole 3 plus een opsetlike fout. n Ry wat jy nie met opdraguitleg kan vul nie, is n ry wat jy nie getoets het nie, en n toestel wat die herverbinding-ry slaag en die selflaai-ry faal is algemeen genoeg om die ekstra tien minute werd te wees.

Voordat jy dit klaar noem:

  • Bevestig dat die blokkeer-instelling apart van die herverbinding-instelling is, en lees sy waarde op die toestel.
  • Weet watter laag die blok afdwing - kliënt-opsie, toestelbeleid of firewall - en waar daardie laag opgestel word.
  • Hou een toetsopdrag wat die blok bewys, en hardloop dit tydens n oorgang, nie daarna nie.
  • Skryf die uitsonderingslys neer, eindpunt ingesluit, en noteer wie dit verfris.
  • Op bestuurde hardeware, los die afgedwonge beleid alleen; die blok verwyder verander die vereiste eerder as om die tonnel reg te maak.

Verwante artikels