Dos VPN d’iPhone alhora: quin transporta el trànsit?

Dues aplicacions VPN mostren Connectat alhora, i se suposa que el trànsit ara passa per totes dues, una dins de l’altra. Normalment no és així. L’iOS té un model de coexistència específic, i no és una cadena. Una classe de configuració es limita a una sola instància activada, l’altra pot funcionar al costat, i la precedència de rutes decideix els conflictes. Dos interruptors encesos no són dos salts. El model està documentat, cosa que significa que el camí es pot predir en lloc d’endevinar-lo a partir de les icones.

Mite: dues VPN connectades són una cadena

Una cadena de dos salts necessita un transport exterior definit, un túnel interior definit, un encaminament d’extrems compatible i un pla per al que passa quan falla qualsevol dels dos. Dues configuracions independents no ho creen pel fet d’existir al mateix temps. La prioritat de ruta no és el mateix que l’encapsulament, i que una configuració guanyi una consulta de ruta no diu res sobre si l’altra transporta els paquets resultants.

Si necessiteu imbricació, dissenyeu-la com a imbricació. No la inferiu de dos indicadors de connexió. Aquesta distinció estalvia molta depuració.

El model documentat darrere d’aquest mite

El NETunnelProviderManager d’Apple descriu configuracions VPN empresarials habituals i afirma que només se’n pot activar una d’aquest tipus alhora. La mateixa referència permet que una Personal VPN continuï activada i connectada al costat, i dona precedència a les rutes empresarials on les dues se superposen.

Aquí Personal VPN és el terme de l’API per a la implementació integrada d’IPsec o IKEv2 gestionada mitjançant NEVPNManager. NETunnelProviderManager és el model de proveïdor de túnel. Una aplicació de consum pot utilitzar el model de proveïdor, així que un nom de producte que contingui personal no el classifica.

Apple documenta una combinació permesa, i el permís no us diu que els perfils de dos proveïdors siguin compatibles, així que pregunteu a cada proveïdor quina parella és compatible. Els seus tipus de configuració, rutes i polítiques encara decideixen el resultat.

Mite: la VPN personal rep el trànsit de navegació

Un perfil de feina que reclama totes les destinacions guanyarà també la consulta de ruta per a la navegació pública, així que la sortida personal no en transporta res. Segons la precedència documentada, les rutes empresarials guanyen on entren en conflicte, així que la navegació pública no agafa automàticament la sortida personal només perquè aquesta aplicació també informa que està connectada. Una configuració de feina més estreta pot canviar el panorama d’encaminament, però el client de l’organització encara pot imposar requisits de DNS, de bloqueig o de dispositiu. Obteniu l’arranjament suportat del seu propietari en lloc d’editar aquests requisits localment.

Les configuracions gestionades per aplicació tenen el seu propi abast. No extrapoleu una regla a nivell de dispositiu a cada desplegament gestionat.

Anoteu els dos fluxos abans de provar: el nom i el rang privats del servei de feina, i una petició nova de navegació pública. Tots dos són legítims, i necessiten comprovacions diferents.

Precedència de rutes amb un perfil de feina de túnel dividit

Un perfil de feina amb túnel dividit reclama els prefixos privats i el sufix DNS intern que llista, i aquestes rutes guanyen qualsevol consulta que hi coincideixi. Les destinacions públiques que no coincideixen amb cap ruta empresarial cauen a l’enllaç físic tret que la VPN personal les reclami primer. La regla de precedència només decideix les coincidències superposades, per això els dos perfils s’han de llegir com a taules de rutes i no com a icones.

Escriviu la parella en dues línies i nomeu el guanyador esperat per a cadascuna: un nom d’amfitrió de feina que es resolgui a 10.x o 172.16.x hauria de sortir pel túnel empresarial, i una adreça pública sense prefix coincident hauria d’agafar la ruta per defecte que quedi. Si totes dues línies nomeuen la mateixa sortida, la divisió no fa el que descriu la documentació.

Anoteu dos fluxos i proveu-ne cadascun

Per a cada flux, anoteu quina configuració aprovada l’ha de transportar i quin resolutor ha de rebre cada tipus de nom. Després verifiqueu-ho amb peticions noves, no amb una pàgina de feina en memòria cau ni amb un resultat d’IP antic.

Atureu una configuració i repetiu tots dos fluxos. El comportament en cas de fallada forma part del disseny, i és la part que els usuaris noten. Quan els dos proveïdors no poden suportar la combinació, decanteu-vos per una configuració aprovada i documenteu quin flux transporta, o passeu a un disseny gestionat d’un sol túnel. La documentació del NETunnelProviderManager és la font de la regla de coexistència.