Always-on VPN või kill switch: kumma te tegelikult sisse lülitasite?

Always-on ja kill switch asuvad samal seadete ekraanil kaks rida üksteisest, seega loevad inimesed neid ühe funktsiooni kahe nimega. Nad ei ole. Always-on on taasühenduse poliitika: käivitab tunneli alglaadimisel, toob selle tagasi krahhi või võrguvahetuse järel ja proovib edasi, kuni see ebaõnnestub. Kill switch on liikluspoliitika: nimetab paketid, mis tohivad masinast veel väljuda, kui tunnel on maas. Esimest saab sisse lülitada ilma teiseta ja enamikul platvormidel laseb vaikimisi tulemus lünga ajal liiklust siiski välja.

Kontroll 1: kas blokk on omaette lüliti?

Androidis 10 ja uuemas avab salvestatud VPN-profiil hammasratta taga kaks sõltumatut lülitit: Always-on VPN ja Blokeeri ühendused ilma VPN-ita. Ainult teine on kill switch. Ainult always-oniga tuleb tunnel pärast katkestust tagasi, kuid iga rakendus keset päringut jõuab seni võrku Wi-Fi või mobiilside kaudu.

Hallatavad seadmed hoiavad sama jaotust poliitika API-s. setAlwaysOnVpnPackage() võtab paketi nime ja lipu lockdownEnabled; administraator, kes määrab paketi ja jätab lipu valeks, on ehitanud püsiva tunneli, mitte suletud seadme. Konsooli sõnastus teeb selle vahe harva nähtavaks.

Lugege olekut seadmest, mitte konsoolist: adb shell settings get global always_on_vpn_app ja adb shell settings get global always_on_vpn_lockdown. Kui esimene tagastab null, ei ole platvormi tasandil ühtki paketti peale surutud; kui teine tagastab 0, ei blokeeri platvorm midagi. Androidi VPN juhend kirjeldab neid eraldi võimetena, mitte ühe režiimina.

Kontroll 2: milline kiht blokki omab?

Sildid elavad kliendis ja blokid tavaliselt tulemüüris, seega tähendab sama sõna igal platvormil muud. Allolevad read tasub kinnitada enne, kui ühtegi usaldate.

Windows on kõige selgem näide sildist, mis ei blokeeri. Always On kirjeldab seal tunneli püsivust: seadme tunnel masina autentimiseks, kasutaja tunnel sisselogitud kontole, seadistatud profiili XML-i või Add-VpnConnection kaudu. Miski selles profiilis ei peata väljuvat paketti, kui tunnel puudub, ja väljuv filtreerimine ei ole vaikimisi sees, seega Wi-Fi-s olev sülearvuti töötab edasi, kui VPN on maas.

WireGuard jaguneb samamoodi, kuid kliendi kaupa. WireGuard Windowsile kannab tunneli kohta valikut Blokeeri tunneliväline liiklus, mis paigaldab filtrireeglid; Linuxi tööriistadel sellist lülitit ei ole. wg-quick lisab marsruudi iga AllowedIPs kirje jaoks pluss fwmark reegli, ning wg-quick down eemaldab mõlemad, nii et füüsiline vaikemarsruut võtab taas üle ilma vahepeal kadunud paketita.

Apple’i platvormidel tuleb always-on hallatavate seadmete haldusprofiili funktsioonina ja väljendub nõudmisel reeglitena, mitte märkeruuduna. Koormusest tuleb vastata küsimusele, kas ebaõnnestunud tunnel keeldub liiklusest või palub lihtsalt teist ühendust. Menüü pealkiri ei ütle.

Kontroll 3: mõõtke lünka, mitte ikooni

Neli üleminekut loevad ja need ebaõnnestuvad erinevalt: alglaadimine enne, kui keegi sisse logib, uni ja ärkamine, üleminek Wi-Filt mobiilandmetele ning kliendi krahh, mis jätab tunneli liidese poolenisti seadistatuks. Puhas taasühendus ühel neist ei tõesta teiste kolme kohta midagi.

Odavaim test peatab tunneli meelega ja proovib siis välja minna. Kui tunnel on maas, tähendab curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com vastusega 200, et poliitika on fail-open; aegumine või tagasilükatud ühendus tähendab, et miski blokeerib veel. ip route get 1.1.1.1 nimetab liidese, mis paketi kannaks, mis ütleb tavaliselt rohkem kui salve ikoon, ja systemctl status wg-quick@wg0 näitab, kas liides eemaldati puhtalt.

Käivitage sama test teises aknas, kui võrk muutub, mitte alles pärast. Katkestuse ja uue katse vahe on oluline osa ning nime päring on kiireim viis märgata, et liiklus pääses välja: kui kohalik resolver vastab, kui tunnel on maas, ei ole blokk täielik.

Kontroll 4: otsustage erandid enne lukustamist

Kaks erandit on struktuursed. Klient peab jõudma VPN-serverini ise, seega kõike lõikav reeglistik takistab ka taasühendust, mis taastaks kaitse. Captive portal ei ole samuti kättesaadav tunnelist, mis ei ole püsti, seega hotelli Wi-Fi-s lukustatud seade vajab dokumenteeritud viisi portaali avamiseks, mitte improviseeritut.

Minimaalne kuju, lõpp-punkt lubatud ja kõik muu kõrvale heidetud:

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

Käsitlege seda lõpp-punkti rida muutujana, mitte konstandina. Pakkujad pööravad aadresse ja vananenud erand on tavaline põhjus, miks töötav kill switch muutub seadmeks, mis ei suuda uuesti ühenduda. Kohalikud printerid, NAS-i jagamised ja arendusteenused kuuluvad samasse kirjalikku nimekirja, muidu avastatakse need üks tugipilet korraga.

Kontroll 5: kirjutage üles, mida te tegelikult tõestasite

Pidage nelja veeruga tabelit ja täitke seda testides: olek, oodatud käitumine, täheldatud käitumine, tõend. Read on kontrolli 3 üleminekud pluss üks tahtlik ebaõnnestumine. Rida, mida te ei saa käsu väljundiga täita, on rida, mida te ei testinud, ja seade, mis läbib taasühenduse rea ja ebaõnnestub alglaadimise real, on piisavalt tavaline, et kümme lisaminutit väärib.

Enne kui nimetate selle valmis:

• Kinnitage, et blokeerimise seade on taasühenduse seadest eraldi, ja lugege selle väärtust seadmest.
• Teage, milline kiht blokki jõustab - kliendi valik, seadme poliitika või tulemüür - ja kus see kiht seadistatakse.
• Hoidke üht proovikäsku, mis bloki tõestab, ja käivitage seda ülemineku ajal, mitte pärast.
• Kirjutage erandite nimekiri üles, lõpp-punkt kaasa arvatud, ja märkige, kes seda uuendab.
• Hallataval riistvaral jätke pealesurutud poliitika rahule; bloki eemaldamine muudab nõuet, selle asemel et tunnelit parandada.