Kaksi VPN-sovellusta yhtä aikaa: mikä kill switch oikeastaan pätee?
Toinen VPN-asiakasohjelma ei koskaan peri ensimmäisen kill switchiä. Kolme ehtoa ratkaisee, mikä käytäntö pätee, ja miten omasi tarkistat.
Kaksi VPN-asiakasohjelmaa voi pyöriä rinnakkain, mutta niiden kill switchit eivät sulaudu yhdeksi käytännöksi. Kukin asiakasohjelma asentaa säännöt omalle tunnelilleen, eikä kumpikaan tiedä toisen olemassaolosta. Törmäsin tähän, kun työasiakasohjelma oli yhdistetty ensin: toinen sovellus ei saanut kättelyään valmiiksi, jäi ”Connecting”-tilaan kymmeneksi minuutiksi ja ensimmäinen tunneli kuljetti kaiken hiljaa. Se, suojataanko toinen sovellus, riippuu kolmesta ehdosta – ei siitä, sanovatko molemmat kuvakkeet Yhdistetty.
Mihin kill switch oikeastaan rajautuu
Millään käyttöjärjestelmällä ei ole yhtä kill switch -lippua. Asiakasohjelma, joka mainostaa sellaista, asentaa sääntöjoukon: pudota kaikki, mikä ei lähde tunnelini kautta, ja usein fail closed, kun tunneli katoaa. Linuxissa se on yleensä nftables- tai iptables-ketju, Windowsissa joukko Windows Filtering Platform -suodattimia, Androidissa ja iOS:ssa tunnelipalvelun oma reititys sekä järjestelmäasetus, joka estää yhteydet ilman VPN:ää. Androidin VPN-opas kuvaa tämän palvelumallin, jos haluat alustan näkökulman.
Laajuus on se osa, jolla on väliä. Sääntö kuten ”salli vain paketit lähtörajapinnalla wg0” ei välitä siitä, onko toista tunnelia olemassa. Jos toinen asiakasohjelma nostaa wg1:n, ensimmäisen asiakasohjelman säännöt kohtelevat näitä paketteja tavallisena liikenteenä: yleensä pudotetaan, joskus sallitaan. Kummassakin tapauksessa päättää ensimmäinen asiakasohjelma, eikä sillä ole aavistustakaan, että toinen sovellus odottaa.
Kolme ehtoa, jotka ratkaisevat, kuka tulee katetuksi
Kaikkia yhdistelmiä ei tarvitse luetella. Kolme kysymystä selvittää asian muutamassa minuutissa.
- Salliiko alusta ylipäätään toisen tunnelin? Useimmat Android-puhelimet ja iPhonet hyväksyvät vain yhden aktiivisen VPN-palvelun käyttäjäprofiilia kohden, joten toisella sovelluksella ei ole koskaan tunnelia eikä se valvo mitään. Saat yhden käytännön – siltä sovellukselta, joka voitti paikan.
- Mikä prosessi omistaa oletusreitin? Windows, macOS ja Linux kantavat mielellään kaksi tunnelia. Oletusreitti kuuluu asiakasohjelmalle, joka määritti sen viimeksi tai parhaalla metriikalla, ja toinen asiakasohjelma on yhdistetty mutta joutilaana. Linuxissa wg-quickin oletusreittitila käyttää käytäntöpohjaista reititystä yksityisellä taululla ja fwmark-säännöllä, joten toinen wg-quick-tunneli lisää kilpailevan säännön sen sijaan, että korvaisi ensimmäisen.
- Pääseekö toinen asiakasohjelma omaan palvelimeensa? Jos ensimmäinen kill switch on default-deny, toisen sovelluksen ulompi päätepiste on vain yksi pudotettu kohde lisää. Se yrittää uudelleen hiljaa eikä koskaan raportoi virhettä.
Lyhyt versio tukiketjuihin:
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
Kaksi noista riveistä näyttää samalta ilmaisinalueen kuvakkeessa, ja siksi kuvake on huonoin saatavilla oleva todiste tässä.
Mikä pettää ensin, ja miltä se näyttää
Asiakasohjelma, joka jumittuu ”Connecting”-tilaan toisen ollessa kunnossa, tarkoittaa lähes aina päätepisteen nälkää: käynnissä oleva kill switch pudottaa toisen asiakasohjelman kättelyn sen omaan palvelimeen. Vahvista se halvalla keskeyttämällä ensimmäisen asiakasohjelman estosäännöt yhden yrityksen ajaksi. Jos toinen yhdistyy heti, kysymys on vastattu.
DNS on toinen vikaantuminen. Asiakasohjelmat asettavat resolveriasetukset omalle rajapinnalleen, ja jotkin kirjoittavat globaalin resolveriluettelon suoraan yli. Kun molemmat tunnelit ovat ylhäällä, kyselyt voivat lähteä toisen puolen kautta, vaikka resolveri kuuluu toiselle. Katkaise kumman tahansa sovelluksen yhteys, ja jäljelle jäävä pitää tavoittamattoman nimipalvelimen: sivut jumittuvat minuutiksi ja ratkeavat sitten uudelleen, kun VPN näyttää yhä yhdistettyä.
Kolmas on reittien leiskahtelu. Uudelleenyhdistämiset järjestävät oletusreitin uudelleen, eikä rajapintaan sidottu kill switch seuraa sitä. Liikenne, joka hetki sitten oli tunnelissa, osuu nyt pudotussääntöön, mikä käyttäjän kannalta näyttää VPN:ltä, joka lakkaa satunnaisesti toimimasta.
Tarkista, mikä käytäntö on todella voimassa
Tee tämä vaarattomalla liikenteellä, älä sellaisella, jota jäisit kaipaamaan.
Kysy Linuxissa ytimeltä, kuka voittaa ja mihin palomuuri sitoutuu. ip -4 route show default nimeää tunnelin, joka omistaa uloslähdön. ip rule show näyttää, onko käytäntöpohjainen reititys pelissä. sudo nft list ruleset | grep -n oifname näyttää, sidotaanko pudotukset rajapinnan nimeen, merkintään vai koko lähtöketjuun.
Windowsissa sama tarina asuu reittimetriikassa ja suodatinluettelossa: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric ja Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". macOS:ssa netstat -rn -f inet | head -5 ja scutil --dns | head -20.
Tee sitten askel, jonka ihmiset ohittavat: pysäytä tunneli tarkoituksella ja vahvista, että liikenne, jonka odotat epäonnistuvan, todella epäonnistuu. Yhdistetty kuvake on käyttöliittymän tila, ei valvontaa.
Milloin kaksi asiakasohjelmaa on väärä suunnittelu
Jos toisen sovelluksen ainoa vaatimus on enemmän suojaa, poista se. Kaksi toisiinsa vaikuttavaa estokäytäntöä on vähemmän ennustettava kuin yksi, ja jokainen uudelleenyhdistäminen on mahdollisuus päätyä tilaan, jota kukaan toimittaja ei testaa.
Jos todella tarvitset ketjutusta, esimerkiksi yrityksen yhdyskäytävää kaupallisen hypyn kautta, valitse suunnittelu, jossa on yksi valvontapiste. Se tarkoittaa yleensä reititintä tai yhtä ketjua tukevaa asiakasohjelmaa – ei kahta työpöytäsovellusta kilpailemassa samasta oletusreitistä. Hallitulla laitteella pidä hyväksytty asiakasohjelma ja käsittele kaikkea muuta laajuuden ulkopuolisena, mitä se sitten ilmaisinalueellaan näyttääkin.
Tarkistuslista ennen kuin pidät molemmat
Käy lista järjestyksessä läpi; ensimmäinen pettävä kohta on se, joka pitää korjata.
- Vahvista, että täsmälleen yksi asiakasohjelma omistaa oletusreitin ja resolverin.
- Jos haluat toisen asiakasohjelman ylös, salli sen palvelimen päätepiste nimenomaisesti ja tarkista uudelleen jokaisen asiakasohjelmapäivityksen jälkeen.
- Kirjaa odotettu lopputulos, kun jompikumpi tunneli putoaa, ja testaa juuri se tapaus.
- Tarkista vikapolku uudelleenkäynnistyksen jälkeen, kun käynnistysjärjestys on erilainen.
- Hallitulla profiililla pysähdy ja kysy omistajalta ennen kuin lisäät mitään.
Jos kolmas askel pettää, rehellinen vastaus on, että vain yksi asiakasohjelma antaa sinulle käytännön. Päätä, kumpaan luotat, ja päästä toinen menemään.