Always-on VPN eða kill switch: hvað virkjaðir þú í raun?

Always-on og kill switch standa tveimur línum hvor frá öðrum á sama stillingaskjánum, svo fólk les þau sem tvö nöfn á einni aðgerð. Þau eru það ekki. Always-on er stefna um endurtengingu: ræstu göngin við ræsingu, komdu þeim aftur eftir hrun eða netbreytingu og haltu áfram að reyna meðan þau mistakast. Kill switch er stefna um umferð: hún nefnir hvaða pakkar mega enn fara út af vélinni meðan göngin eru niðri. Þú getur virkjað hið fyrra án hins síðara, og á flestum kerfum sleppir sjálfgefna útkoman umferð út á meðan á bilinu stendur.

Athugun 1: er blokkin eigin rofi?

Í Android 10 og nýrri opnar vistað VPN-snið tvo óháða rofa bak við tannhjólið: Always-on VPN og Block connections without VPN. Aðeins sá síðari er kill switch. Með always-on einu sér koma göngin vissulega aftur eftir slit, og hvert forrit sem er mitt í beiðni getur náð netinu um Wi-Fi eða farsímagögn þar til það gerist.

Stýrð tæki halda sömu skiptingu í stefnulagi forritaskilsins. setAlwaysOnVpnPackage() tekur nafn pakkans og lockdownEnabled fána; stjórnandi sem setur pakkann og lætur fánann vera false hefur byggt varanleg göng, ekki lokað tæki. Orðalag í stjórnborðinu gerir sjaldan þann mun sýnilegan.

Lestu stöðuna úr tækinu en ekki stjórnborðinu: adb shell settings get global always_on_vpn_app og adb shell settings get global always_on_vpn_lockdown. Ef hið fyrra skilar null er enginn pakki framfylgt á stigi kerfisins; ef hið síðara skilar 0 er kerfið ekki að blokka neitt. Android VPN handbókin lýsir þessu sem aðskildum möguleikum en ekki einni stillingu.

Athugun 2: hvaða lag á blokkina?

Merkimiðarnir búa í biðlaranum og blokkirnar venjulega í eldveggnum, og þess vegna þýðir sama orð mismunandi hluti á hverju kerfi. Línurnar hér að neðan eru þær sem vert er að staðfesta áður en þú treystir einhverri þeirra.

Windows er skýrasta dæmið um merkimiða sem blokkar ekki. Þar lýsir Always On varanleika ganganna: tækjagöngum fyrir auðkenningu vélarinnar og notandagöngum fyrir innskráðan reikning, stillt með XML-sniði eða Add-VpnConnection. Ekkert í því sniði stöðvar útleiðandi pakka þegar gengin vantar, og útleiðandi síun er ekki virk sjálfgefið, svo fartölva á Wi-Fi heldur áfram að virka meðan VPN er niðri.

WireGuard skiptist á sama hátt, en eftir biðlara. WireGuard for Windows hefur Block untunneled traffic valkost fyrir hver göng sem setur síunarreglur; Linux-tólin hafa engan slíkan rofa. wg-quick bætir við leið fyrir hverja AllowedIPs færslu og fwmark reglu, og wg-quick down fjarlægir bæði, svo líkamlega sjálfgefna leiðin tekur við aftur án þess að nokkur pakki tapist.

Á Apple-kerfum kemur always-on sem eiginleiki stjórnunarsniðs fyrir tæki undir eftirliti og birtist sem on-demand reglur en ekki gátreitur. Spurningin sem svara þarf úr farminum er hvort misheppnuð göng meina umferð eða biðja bara um aðra tengingu. Valmyndarheitið segir þér það ekki.

Athugun 3: mældu bilið, ekki táknið

Fjögur umskipti skipta máli og mistakast á mismunandi vegu: ræsing áður en nokkur skráir sig inn, svefn og vakning, skipti úr Wi-Fi yfir á farsímagögn og hrun biðlarans sem skilur viðmót ganganna hálfstillt. Hrein endurtenging á einu þeirra sannar ekkert um hin þrjú.

Ódýrasta prófið stöðvar göngin viljandi og reynir svo að komast út. Með göngin niðri þýðir curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com sem skilar 200 að stefnan sé fail-open; tímamörk eða hafnað tenging þýðir að eitthvað blokki enn. ip route get 1.1.1.1 nefnir viðmótið sem myndi bera pakkann, sem er venjulega upplýsandi en táknmyndin í bakkanum, og systemctl status wg-quick@wg0 sýnir hvort viðmótið var fjarlægt hreint.

Keyrðu sama próf í öðrum glugga meðan netið er að breytast, ekki bara eftir að það kemst í jafnvægi. Bilið milli slits og endurtekinnar tilraunar er það sem skiptir máli, og nafnaleit er flýtileiðin að taka eftir því að umferð slapp út: ef staðbundni leysirinn svarar meðan göngin eru niðri er blokkin ekki fullkomin.

Athugun 4: ákveddu undantekningarnar áður en þú lokar

Tvær undantekningar eru byggingarlegar. Biðlarinn verður að ná í VPN-þjóninn sjálfan, svo reglusafn sem hendir öllu kemur einnig í veg fyrir endurtenginguna sem myndi endurheimta vernd. Captive portal er heldur ekki aðgengilegt í gegnum göng sem eru ekki uppi, svo læst tæki á hótel-Wi-Fi þarf skjalfesta leið til að opna gáttina en ekki óundirbúna.

Lágmarksform, endapunktur leyfður og öllu öðru hent:

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

Líttu á endapunktalínuna sem breytu en ekki fasta. Þjónustuveitendur skipta um vistföng, og úrelt undantekning er venjulega ástæðan fyrir því að kill switch sem virkar verður að tæki sem getur ekki endurtengst. Staðbundnir prentarar, NAS-deilingar og þróunarþjónustur eiga heima á sama skriflegu listanum, annars uppgötvast þau eitt og eitt með stuðningsbeiðnum.

Athugun 5: skráðu hvað þú sannaðir í raun

Haltu töflu með fjórum dálkum og fylltu hana með prófunum: staða, vænt hegðun, séð hegðun, sönnun. Línurnar eru umskiptin úr athugun 3 auk eins viljandi bilunar. Lína sem þú getur ekki fyllt með úttaki skipunar er lína sem þú hefur ekki prófað, og tæki sem stenst endurtengingarlínuna en fellur á ræsingarlínunni er nógu algengt til að réttlæta auka tíu mínúturnar.

Áður en þú kallar þetta búið:

• Staðfestu að blokkarstillingin sé aðskilin frá endurtengingarstillingunni og lestu gildi hennar í tækinu.
• Vitaðu hvaða lag framfylgir blokkinni - valkostur í biðlara, stefna tækis eða eldveggur - og hvar það lag er stillt.
• Haltu einni prófunarskipun sem sannar blokkina og keyrðu hana meðan á umskiptum stendur en ekki eftir.
• Skrifaðu undantekningalistann niður, endapunktinn með, og skráðu hver endurnýjar hann.
• Á stýrðum vélbúnaði skaltu láta framfylgdu stefnuna í friði; að fjarlægja blokkina breytir kröfunni í stað þess að laga göngin.