Kaksi iPhone-VPN:ää yhtä aikaa: kumpi kuljettaa liikennettäsi?

Kaksi VPN-sovellusta näyttävät molemmat Connected-tilaa, ja oletus on, että liikenne kulkee nyt molempien kautta, toinen toisen sisällä. Yleensä se ei pidä paikkaansa. iOS:llä on tietty rinnakkaiselomalli, eikä se ole ketju. Yksi kokoonpanoluokka rajoittuu yhteen käytössä olevaan ilmentymään, toinen voi toimia sen rinnalla, ja reittien prioriteetti ratkaisee ristiriidat. Kaksi päällä olevaa kytkintä ei ole kaksi hyppyä. Malli on dokumentoitu, eli polku voidaan ennustaa sen sijaan, että se arvattaisiin kuvakkeista.

Myytti: kaksi yhdistettyä VPN:ää on ketju

Kahden hypyn ketju tarvitsee määritellyn ulkoisen siirron, määritellyn sisäisen tunnelin, yhteensopivan päätepisteiden reitityksen ja suunnitelman siitä, mitä tapahtuu, kun jompikumpi pettää. Kaksi itsenäistä kokoonpanoa ei luo sitä pelkästään olemalla olemassa samanaikaisesti. Reitin prioriteetti ei ole sama kuin kapselointi, eikä yhden kokoonpanon voitto reittihaussa kerro mitään siitä, kuljettaako toinen syntyvät paketit.

Jos tarvitset sisäkkäisyyttä, suunnittele se sisäkkäisyytenä. Älä päättele sitä kahdesta yhteysindikaattorista. Tämä ero säästää paljon virheenetsintää.

Tuon myytin takana oleva dokumentoitu malli

Applen NETunnelProviderManager kuvaa tavalliset yritys-VPN-kokoonpanot ja toteaa, että niistä vain yksi voi olla käytössä kerrallaan. Sama viite sallii Personal VPN:n pysyä käytössä ja yhdistettynä sen rinnalla ja antaa yrityksen reiteille etusijan, kun ne menevät päällekkäin.

Tässä Personal VPN on API-termi sisäänrakennetulle IPsec- tai IKEv2-toteutukselle, jota hallitaan NEVPNManagerin kautta. NETunnelProviderManager on tunnelintarjoajamalli. Kuluttajasovellus voi käyttää tarjoajamallia, joten personal-sanan sisältävä tuotenimi ei luokittele sitä.

Apple dokumentoi yhden sallitun yhdistelmän, eikä lupa kerro, että kahden toimittajan profiilit ovat yhteensopivia, joten kysy kummaltakin toimittajalta, mitä paria tuetaan. Niiden kokoonpanotyypit, reitit ja käytännöt ratkaisevat silti tuloksen.

Myytti: henkilökohtainen VPN saa selailuliikenteen

Työprofiili, joka vaatii kaikki kohteet, voittaa reittihaun myös julkisessa selailussa, joten henkilökohtainen ulostulo ei kuljeta siitä mitään. Dokumentoidun etusijan mukaan yrityksen reitit voittavat, kun ne ovat ristiriidassa, joten julkinen selailu ei ota henkilökohtaista ulostuloa automaattisesti vain siksi, että kyseinen sovelluskin ilmoittaa yhteydestä. Kapeampi työkokoonpano voi muuttaa reitityskuvaa, mutta organisaation asiakasohjelma voi silti asettaa DNS-, estämis- tai laitevaatimuksia. Hanki tuettu järjestely sen omistajalta sen sijaan, että muokkaisit näitä vaatimuksia paikallisesti.

Hallitut sovelluskohtaiset kokoonpanot ovat omassa laajuudessaan. Älä laajenna laitetason sääntöä jokaiseen hallittuun käyttöönottoon.

Kirjoita kaksi virtausta ennen testiä: työpalvelun yksityinen nimi ja alue sekä tuore julkinen selailupyyntö. Molemmat ovat laillisia, ja ne tarvitsevat erilaiset tarkistukset.

Reittien prioriteetti jaetun tunnelin työprofiilissa

Jaetun tunnelin työprofiili vaatii luettelemansa yksityiset etuliitteet ja sisäisen DNS-liitteen, ja ne reitit voittavat jokaisen niihin sopivan haun. Julkiset kohteet, jotka eivät vastaa mitään yrityksen reittiä, putoavat fyysiseen linkkiin, ellei henkilökohtainen VPN vaadi niitä ensin. Etusijasääntö ratkaisee vain päällekkäiset osumat, siksi kaksi profiilia on luettava reittitauluina eikä kuvakkeina.

Kirjoita pari kahdeksi riviksi ja nimeä kunkin odotettu voittaja: työisäntänimi, joka ratkeaa osoitteeseen 10.x tai 172.16.x, pitäisi poistua yrityksen tunnelin kautta, ja julkisen osoitteen ilman vastaavaa etuliitettä pitäisi ottaa jäljelle jäävä oletusreitti. Jos molemmat rivit nimeävät saman ulostulon, jako ei tee sitä, mitä dokumentaatio kuvaa.

Kirjoita kaksi virtausta ja testaa kumpikin

Kirjaa jokaisesta virtauksesta, minkä hyväksytyn kokoonpanon pitäisi kuljettaa se ja mikä ratkaisija vastaanottaa kunkin nimityypin. Vahvista sitten tuoreilla pyynnöillä, älä välimuistiin tallennetulla työsivulla tai vanhalla IP-tuloksella.

Pysäytä yksi kokoonpano ja toista molemmat virtaukset. Virhetila on osa suunnittelua, ja se on osa, jonka käyttäjät huomaavat. Kun kaksi tarjoajaa ei voi tukea yhdistelmää, valitse yksi hyväksytty kokoonpano ja dokumentoi, minkä virtauksen se kuljettaa, tai siirry hallittuun yhden tunnelin suunnitteluun. NETunnelProviderManagerin dokumentaatio on rinnakkaiselosäännön lähde.