Kaksi VPN:ää yhdessä puhelimessa: valitse järjestely, älä sovellusten määrää
Vaihtaminen, profiilien erottelu ja sisäkkäinen ketju ovat kolme eri mallia. Valitse sen mukaan, mitä sovellus tarvitsee samalla hetkellä, ja tarkista sitten MTU ja reitti.
Kahden VPN:n käyttäminen ei ole yksi pyyntö. Se voi tarkoittaa kahden organisaation tavoittamista peräkkäin, työ- ja henkilökohtaisten sovellusten erottamista toisistaan tai yhden tunnelin ajamista toisen sisällä. Android käsittelee nämä kolme tapausta täysin eri tavoin, eikä puhelimeen asennettujen VPN-sovellusten määrä ole arkkitehtuuri. Kysymys, joka erottaa ne, on yksinkertainen: onko kahden polun oltava olemassa samalla hetkellä samalle sovellukselle?
Kolme järjestelyä, yksi kysymys
Jos vastaus on ei, koska kahta verkkoa käytetään eri aikoina, haluat tarkoituksellisen vaihdon. Jos vastaus on ei, koska sovellukset itsessään ovat erillisiä, haluat profiilien erottelun, jossa jokainen sovellus istuu siinä kontekstissa, joka omistaa sen tunnelin. Jos vastaus on kyllä ja toisen polun on fyysisesti kuljetettava toista, haluat ketjun, ja se on ainoa kolmesta, jossa järjestys on osa mallia.
Kaikki muu seuraa tästä valinnasta. Vaihdolla on siirtymäikkuna, erottelulla on politiikan raja, ja ketjulla on ylimääräisiä kuluja ja riippuvuuskustannus. Väärän valitseminen ei epäonnistu puhtaasti; se tuottaa puhelimen, joka näyttää yhdistetyltä, ja sovelluksen, joka ei tavoita mitään.
Vaihtaminen yhdessä käyttäjäkontekstissa
Android sallii yhden aktiivisen VPN-palvelun käyttäjää kohden. Toisen VPN-sovelluksen käynnistäminen samassa kontekstissa korvaa ensimmäisen tai se hylätään suoraan; se ei koskaan yhdistä kahta reittijoukkoa, eikä varmasti pinosta niiden salausta. Yhden käyttäjän sisällä kaksi tunnelia on peräkkäisyys, ei summa.
Tämä on käytännöllistä, kun pääsy on aidosti peräkkäistä. Nimeä profiilit niin, että aktiivinen on ilmeinen, lopeta kaikki arkaluonteinen ennen vaihtamista ja odota lyhyttä ikkunaa, jossa kumpikaan polku ei ole täysin muodostettu. Selaimen välilehden sulkeminen ei ole sama kuin istunnon päättäminen: välilehti voi säilyttää tilinsä tilan ja yksinkertaisesti lähettää seuraavan pyynnön juuri valitun verkon kautta, ja juuri se on se vuoto, jonka ihmiset huomaavat jälkeenpäin.
Mitä vaihtaminen ei voi antaa, on kone, joka on molemmissa verkoissa samanaikaisesti. Jos sovellus tarvitsee yksityisen osoitteen kummaltakin puolelta, mikään asiakkaan kurinalaisuus ei tuota sitä.
Erottelu profiilin mukaan
Hallittu työprofiili on erillinen käyttäjä, jolla on omat sovelluksensa, avainsäilönsä ja verkkopolitiikkansa. Työsähköpostiasiakas voi käyttää organisaation tunnelia, kun taas henkilökohtainen selain käyttää henkilökohtaista, ja molemmat voivat olla yhteydessä samanaikaisesti, koska ne eivät ole samassa kontekstissa kilpailemassa paikasta.
Erottelu on myös raja. Henkilökohtainen selain ei lainaa työtunnelia, ei näe työn DNS-liitteitä eikä tavoita työverkkoa vain siksi, että molemmat palvelut näkyvät yhdistettyinä. Kun joku ilmoittaa, ettei linkki aukea, tarkista, mikä sovelluksen kopio sitä käsitteli ja mikä profiili omistaa sen tilin, ennen kuin kosket kumpaankaan VPN:ään.
Kohtele rajaa kiinteänä. Toisen profiilin luominen tai työprofiilin poistaminen työnantajan reitityspäätöksen kiertämiseksi tuhoaa juuri sen erottelun, joka sai järjestelyn toimimaan, ja hallitulla laitteella se on yleensä politiikan rikkomus eikä kokoonpanon muutos.
Ketju, jossa järjestys on malli
Ketju on järjestely, jota ihmiset yleensä tarkoittavat sanoessaan molemmat yhtä aikaa: puhelimen tunneli kulkee reitittimen tunnelin sisällä. Se voi toimia, ja rajoitukset ovat konkreettisia. Ulkoisen tarjoajan on sallittava toimiva polku puhelimen VPN-päätepisteeseen, mikä UDP-pohjaisten protokollien kohdalla tarkoittaa, ettei ulkoinen palvelu saa estää tai rajoittaa sitä liikennettä.
Ymmärrä, kuka näkee mitä. Ulkoinen tarjoaja näkee yhteyden sisempään päätepisteeseen. Sisempi tarjoaja vastaanottaa puhelimen liikenteen ulkoisesta ulostulosta ja välittää sen eteenpäin. Lopullinen kohde näkee yleensä sisemmän palvelun ulostulon, eikä mikään tarjoaja ketjussa ole sokea; sovellusten tilit tunnistavat käyttäjän reitistä riippumatta.
Odota käytännön kustannuksia. Jokainen kerros lisää kapselointia, joten tehollinen MTU laskee ja yhdelle tunnelille sopinut arvo pirstoutuu tai juuttuu nyt, kunnes sisemmän tunnelin MTU asetetaan varovaisesti. Kaksi kerrosta tarkoittaa myös kahta vikariippuvuutta ja kahta keepalive-viestisarjaa, ja TCP-pohjainen sisempi tunneli häviöllisen ulkoisen linkin yli voi juuttua tavalla, joka näyttää kuolleelta palvelimelta.
Tärkeintä: ketju ei yhdistä kahta yksityistä verkkoa. Reitit, päällekkäiset etuliitteet, DNS-selvitys ja pääsysäännöt pysyvät erillisinä päätöksinä, eikä reititin, joka kuljettaa yhtä VPN:ää samalla kun puhelin kuljettaa toista, anna puhelimelle molempia osoiteavaruuksia.
Tarkista malli ennen kuin alat debugata sitä
Kirjoita järjestely yhdellä lauseella ja testaa sitä sovelluksella, joka epäonnistui. Peräkkäisen pääsyn pitäisi näyttää yksi tunneli kerrallaan; profiilien erottelun pitäisi näyttää jokainen sovellus omassa käyttäjässään; ketjun pitäisi näyttää sisemmän tunnelin muodostuminen ulkoisen rajapinnan yli fyysisen sijaan.
adb shell ip -br addr
adb shell ip route get 10.20.0.8
adb shell dumpsys connectivity | grep -i vpnJos reittihaku nimeää fyysisen rajapinnan, kun sovellus odottaa tunnelia, malli ja sovelluksen konteksti ovat eri mieltä, eikä mikään ylimääräinen VPN-sovellus sovita niitä yhteen. Hallittujen profiilien dokumentaatio kattaa erottelusäännöt, jos tarvitset politiikan yksityiskohdan reitityksen sijaan.