Két iPhone VPN egyszerre: melyik viszi a forgalmat?

Két VPN-alkalmazás mindkettő Connected állapotot mutat, és a feltételezés az, hogy a forgalom most mindkettőn átmegy, az egyik a másikon belül. Általában mégsem így van. Az iOS-nek sajátos együttélési modellje van, és az nem lánc. Egy konfigurációs osztály egyetlen engedélyezett példányra korlátozódik, a másik futhat mellette, és az útvonal-prioritás dönti el az ütközéseket. Két felkapcsolt kapcsoló nem két ugrás. A modell dokumentált, ami azt jelenti, hogy az útvonal előre jelezhető, nem pedig az ikonokból kitalálható.

Tévhit: két csatlakoztatott VPN láncot alkot

A kétugrásos lánchoz meghatározott külső szállítás, meghatározott belső alagút, kompatibilis végponti útválasztás és terv kell arra, mi történik, ha valamelyik meghibásodik. Két független konfiguráció nem hozza létre ezt pusztán azzal, hogy egyszerre létezik. Az útvonal-prioritás nem ugyanaz, mint a beágyazás, és az, hogy az egyik konfiguráció megnyer egy útvonal-keresést, semmit sem mond arról, hogy a másik viszi-e a keletkező csomagokat.

Ha beágyazásra van szüksége, tervezze beágyazásként. Ne következtessen rá két kapcsolatjelzőből. Ez a megkülönböztetés sok hibakeresést megspórol.

A tévhit mögötti dokumentált modell

Az Apple NETunnelProviderManager osztálya a szokásos vállalati VPN-konfigurációkat írja le, és kimondja, hogy ebből a fajtából egyszerre csak egy engedélyezhető. Ugyanez a referencia engedi, hogy egy Personal VPN mellette engedélyezve és csatlakoztatva maradjon, és elsőbbséget ad a vállalati útvonalaknak ott, ahol a kettő átfed.

A Personal VPN itt az API-kifejezés a NEVPNManageren keresztül kezelt beépített IPsec- vagy IKEv2-megvalósításra. A NETunnelProviderManager az alagút-szolgáltatói modell. Egy fogyasztói alkalmazás használhatja a szolgáltatói modellt, ezért a personal szót tartalmazó terméknév nem sorolja be.

Az Apple egyetlen engedélyezett kombinációt dokumentál, és az engedély nem mondja meg, hogy két szállító profilja kompatibilis, ezért kérdezze meg mindegyik szállítót, melyik pár támogatott. A konfigurációtípusaik, útvonalaik és házirendjeik továbbra is eldöntik az eredményt.

Tévhit: a személyes VPN kapja a böngészési forgalmat

Egy munkaprofil, amely minden célállomást igényel, a nyilvános böngészés útvonal-keresését is megnyeri, így a személyes kijárat ebből semmit sem visz. A dokumentált elsőbbség szerint a vállalati útvonalak nyernek ott, ahol ütköznek, így a nyilvános böngészés nem veszi automatikusan a személyes kijáratot csak azért, mert az az alkalmazás is kapcsolódást jelent. Egy szűkebb munkakonfiguráció megváltoztathatja az útválasztási képet, de a szervezet kliense továbbra is előírhat DNS-, blokkolási vagy eszközkövetelményeket. A támogatott elrendezést a tulajdonosától kérje, ne ezeket a követelményeket szerkessze helyben.

Az alkalmazásonként kezelt konfigurációknak saját hatókörük van. Ne terjesszen ki egy eszközszintű szabályt minden kezelt telepítésre.

Teszt előtt írja le a két folyamot: a munkaszolgálat privát nevét és tartományát, valamint egy friss nyilvános böngészési kérelmet. Mindkettő legitim, és különböző ellenőrzéseket igényel.

Útvonal-prioritás megosztott alagútú munkaprofillal

A megosztott alagútú munkaprofil a felsorolt privát előtagokat és belső DNS-utótagot igényli, és ezek az útvonalak minden velük egyező keresést megnyernek. A nyilvános célállomások, amelyek egyetlen vállalati útvonallal sem egyeznek, a fizikai kapcsolatra esnek, hacsak a személyes VPN előbb nem igényli őket. Az elsőbbségi szabály csak az átfedő egyezéseket dönti el, ezért a két profilt útvonaltáblaként kell olvasni, nem ikonként.

Írja le a párt két sorban, és nevezze meg mindegyik várható nyertesét: a 10.x vagy 172.16.x címre feloldódó munka-gazdanévnek a vállalati alagúton kell kijutnia, a megfelelő előtag nélküli nyilvános címnek pedig a fennmaradó alapértelmezett útvonalat kell vennie. Ha mindkét sor ugyanazt a kijáratot nevezi meg, a felosztás nem azt teszi, amit a dokumentáció leír.

Írjon le két folyamot, és tesztelje mindegyiket

Minden folyamnál jegyezze fel, melyik jóváhagyott konfigurációnak kell vinnie, és melyik feloldónak kell megkapnia az egyes névtípusokat. Ezután friss kérelmekkel ellenőrizze, nem gyorsítótárazott munkalappal vagy régi IP-eredménnyel.

Állítson le egy konfigurációt, és ismételje meg mindkét folyamot. A hiba viselkedése a tervezés része, és ez az a rész, amit a felhasználók észrevesznek. Amikor a két szolgáltató nem tudja támogatni a kombinációt, állapodjon meg egy jóváhagyott konfigurációban, és dokumentálja, melyik folyamot viszi, vagy térjen át kezelt egységes alagútú kialakításra. A NETunnelProviderManager dokumentációja az együttélési szabály forrása.