Always-on VPN vai kill switch: kumman oikeastaan otit käyttöön?

Always-on ja kill switch ovat samalla asetusnäytöllä kaksi riviä erillään, joten ihmiset lukevat ne yhden ominaisuuden kahdeksi nimeksi. Ne eivät ole. Always-on on uudelleenyhdistämiskäytäntö: käynnistää tunnelin bootissa, palauttaa sen kaatumisen tai verkon vaihtumisen jälkeen ja yrittää uudelleen niin kauan kuin se epäonnistuu. Kill switch on liikennekäytäntö: se nimeää paketit, jotka saavat vielä lähteä koneesta, kun tunneli on alhaalla. Voit ottaa ensimmäisen käyttöön ilman toista, ja useimmilla alustoilla oletustulos päästää liikennettä ulos aukon aikana.

Tarkistus 1: onko esto oma kytkin?

Android 10:ssä ja uudemmissa tallennettu VPN-profiili avaa hammasrattaan takaa kaksi riippumatonta kytkintä: Always-on VPN ja Estä yhteydet ilman VPN:ää. Vain toinen on kill switch. Pelkällä always-onilla tunneli palaa katkoksen jälkeen, mutta mikä tahansa sovellus kesken pyynnön tavoittaa verkon Wi-Fi:n tai mobiilidatan kautta siihen asti.

Hallitut laitteet säilyttävät saman jaon käytäntö-API:ssa. setAlwaysOnVpnPackage() ottaa paketin nimen ja lipun lockdownEnabled; ylläpitäjä, joka asettaa paketin ja jättää lipun epätodeksi, on rakentanut pysyvän tunnelin, ei suljettua laitetta. Konsolin sanamuoto tekee eron harvoin näkyväksi.

Lue tila laitteesta, älä konsolista: adb shell settings get global always_on_vpn_app ja adb shell settings get global always_on_vpn_lockdown. Jos ensimmäinen palauttaa null, alustatasolla ei ole pakotettua pakettia; jos toinen palauttaa 0, alusta ei estä mitään. Androidin VPN-opas kuvaa nämä erillisinä kykyinä, ei yhtenä tilana.

Tarkistus 2: mikä kerros omistaa eston?

Nimet elävät asiakkaassa ja estot yleensä palomuurissa, siksi sama sana tarkoittaa eri asiaa kullakin alustalla. Alla olevat rivit kannattaa vahvistaa ennen kuin luottaa yhteenkään.

Windows on selvin esimerkki nimestä, joka ei estä. Always On kuvaa siellä tunnelin pysyvyyttä: laitetunneli koneen todennukseen, käyttäjätunneli kirjautuneelle tilille, määritetty profiilin XML:llä tai Add-VpnConnection. Mikään siinä profiilissa ei pysäytä lähtevää pakettia, kun tunneli puuttuu, eikä lähtevä suodatus ole oletuksena päällä, joten Wi-Fi:ssä oleva kannettava jatkaa toimintaansa, kun VPN on alhaalla.

WireGuard jakautuu samoin, mutta asiakkaittain. WireGuard Windowsille sisältää tunnelikohtaisen vaihtoehdon Estä tunnelin ulkopuolinen liikenne, joka asentaa suodatussäännöt; Linuxin työkaluissa ei ole vastaavaa kytkintä. wg-quick lisää reitin jokaista AllowedIPs-merkintää kohden sekä fwmark-säännön, ja wg-quick down poistaa molemmat, joten fyysinen oletusreitti ottaa jälleen vallan ilman välissä pudonnutta pakettia.

Apple-alustoilla always-on tulee hallintaprofiilin ominaisuutena valvotuille laitteille ja ilmaistaan pyynnöstä- säännöinä, ei valintaruutuna. Hyötykuormasta vastattava kysymys on, kieltääkö epäonnistunut tunneli liikenteen vai pyytääkö vain toista yhteyttä. Valikon otsikko ei kerro.

Tarkistus 3: mittaa aukko, ei kuvaketta

Neljä siirtymää ratkaisee, ja ne epäonnistuvat eri tavoin: käynnistys ennen kuin kukaan kirjautuu, uni ja herätys, siirtymä Wi-Fistä mobiilidataan ja asiakkaan kaatuminen, joka jättää tunnelin rajapinnan puoliksi määritetyksi. Puhdas uudelleenyhdistäminen yhdessä niistä ei todista mitään kolmesta muusta.

Halvin testi pysäyttää tunnelin tahallaan ja yrittää sitten lähteä ulos. Kun tunneli on alhaalla, curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com palauttaa 200 tarkoittaa, että käytäntö on fail-open; aikakatkaisu tai hylätty yhteys tarkoittaa, että jokin estää yhä. ip route get 1.1.1.1 nimeää rajapinnan, joka kuljettaisi paketin, mikä yleensä kertoo enemmän kuin ilmaisinalueen kuvake, ja systemctl status wg-quick@wg0 näyttää, poistettiinko rajapinta puhtaasti.

Aja sama testi toisessa ikkunassa, kun verkko vaihtuu, älä vasta sen jälkeen. Katkoksen ja uuden yrityksen väli on ratkaiseva osa, ja nimikysely on nopein tapa huomata karannut liikenne: jos paikallinen selvittäjä vastaa tunnelin ollessa alhaalla, esto ei ole täydellinen.

Tarkistus 4: päätä poikkeukset ennen lukitsemista

Kaksi poikkeusta on rakenteellisia. Asiakkaan on päästävä itse VPN-palvelimeen, joten kaiken pudottava sääntö estää myös uudelleenyhdistämisen, joka palauttaisi suojan. Captive-portaaliin ei myöskään pääse tunnelin kautta, joka ei ole pystyssä, joten hotellin Wi-Fi:ssä lukittu laite tarvitsee dokumentoidun tavan avata portaali, ei improvisoitua.

Minimaalinen muoto, päätepiste sallittu ja kaikki muu pudotettu:

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

Kohtele tuota päätepisteriviä muuttujana, älä vakiona. Palveluntarjoajat vaihtavat osoitteita, ja vanhentunut poikkeus on tavallinen syy siihen, että toimiva kill switch muuttuu laitteeksi, joka ei voi yhdistää uudelleen. Paikalliset tulostimet, NAS-jakamiset ja kehityspalvelut kuuluvat samaan kirjoitettuun luetteloon, muuten ne löytyvät yksi tukipyyntö kerrallaan.

Tarkistus 5: kirjaa, mitä todella todistit

Pidä nelisarakkeista taulukkoa ja täytä se testaamalla: tila, odotettu käyttäytyminen, havaittu käyttäytyminen, todiste. Rivit ovat tarkistuksen 3 siirtymät plus yksi tahallinen epäonnistuminen. Rivi, jota et voi täyttää komennon tulosteella, on rivi, jota et testannut, ja laite, joka läpäisee uudelleenyhdistämisrivin ja epäonnistuu käynnistysrivillä, on tarpeeksi yleinen, jotta kymmenen lisäminuuttia kannattaa.

Ennen kuin kutsut sitä valmiiksi:

• Vahvista, että eston asetus on erillinen uudelleenyhdistämisen asetuksesta, ja lue sen arvo laitteesta.
• Tiedä, mikä kerros toteuttaa eston - asiakasasetus, laitekäytäntö vai palomuuri - ja missä se kerros määritetään.
• Pidä yksi testikomento, joka todistaa eston, ja aja se siirtymän aikana, ei sen jälkeen.
• Kirjoita poikkeusluettelo, päätepiste mukaan lukien, ja merkitse, kuka sen päivittää.
• Hallitulla laitteistolla jätä pakotettu käytäntö rauhaan; eston poistaminen muuttaa vaatimusta sen sijaan että korjaisi tunnelin.