Dúas VPN de iPhone á vez: cal transporta o teu tráfico?

Dúas aplicacións VPN mostran ambas Conectado, e dáse por feito que o tráfico agora pasa polas dúas, unha dentro da outra. Normalmente non é así. iOS ten un modelo de coexistencia concreto, e non é unha cadea. Unha clase de configuración limítase a unha soa instancia activada, a outra pode executarse ao seu lado, e a precedencia de rutas decide os conflitos. Dous interruptores acendidos non son dous saltos. O modelo está documentado, o que significa que a ruta se pode prever en vez de adiviñar polas iconas.

Mito: dúas VPN conectadas son unha cadea

Unha cadea de dous saltos necesita un transporte exterior definido, un túnel interior definido, un enrutamento de extremos compatible e un plan para o que ocorre cando falla calquera dos dous. Dúas configuracións independentes non crean iso por existiren ao mesmo tempo. A prioridade de ruta non é o mesmo que a encapsulación, e que unha configuración gañe unha busca de ruta non di nada sobre se a outra transporta os paquetes resultantes.

Se necesitas aniñamento, proxéctao como aniñamento. Non o deduzas de dous indicadores de conexión. Esa distinción aforra moita depuración.

O modelo documentado detrás dese mito

NETunnelProviderManager de Apple describe configuracións VPN empresariais habituais e afirma que só unha dese tipo pode estar activada á vez. A mesma referencia permite que unha Personal VPN siga activada e conectada ao seu lado, e dá precedencia ás rutas empresariais onde as dúas se solapan.

Aquí Personal VPN é o termo da API para a implementación integrada de IPsec ou IKEv2 xestionada mediante NEVPNManager. NETunnelProviderManager é o modelo de provedor de túnel. Unha aplicación de consumo pode usar o modelo de provedor, así que un nome de produto que conteña personal non o clasifica.

Apple documenta unha combinación permitida, e o permiso non che di que os perfís de dous provedores sexan compatibles, así que pregunta a cada provedor que par está soportado. Os seus tipos de configuración, rutas e políticas seguen decidindo o resultado.

Mito: a VPN persoal recibe o tráfico de navegación

Un perfil de traballo que reclama todos os destinos gañará tamén a busca de ruta para a navegación pública, así que a saída persoal non transporta nada dela. Segundo a precedencia documentada, as rutas empresariais gañan onde entran en conflito, así que a navegación pública non toma automaticamente a saída persoal só porque esa aplicación tamén informe de conexión. Unha configuración de traballo máis estreita pode cambiar o panorama de enrutamento, pero o cliente da organización aínda pode impoñer requisitos de DNS, bloqueo ou dispositivo. Obtén o arranxo soportado do seu propietario en lugar de editar eses requisitos localmente.

As configuracións xestionadas por aplicación teñen o seu propio alcance. Non extrapoles unha regra de nivel de dispositivo a cada despregamento xestionado.

Anota os dous fluxos antes de probar: o nome e o rango privados do servizo de traballo, e unha solicitude nova de navegación pública. Ambos son lexítimos, e necesitan comprobacións distintas.

Precedencia de rutas cun perfil de traballo de túnel dividido

Un perfil de traballo con túnel dividido reclama os prefixos privados e o sufixo DNS interno que enumera, e esas rutas gañan calquera busca que coincida con eles. Os destinos públicos que non coinciden con ningunha ruta empresarial caen á ligazón física salvo que a VPN persoal os reclame primeiro. A regra de precedencia decide só as coincidencias solapadas, por iso os dous perfís deben lerse como táboas de rutas e non como iconas.

Escribe o par en dúas liñas e nomea o gañador esperado de cada unha: un nome de host de traballo que resolva a 10.x ou 172.16.x debería saír polo túnel empresarial, e un enderezo público sen prefixo coincidente debería tomar a ruta predeterminada que quede. Se ambas as liñas nomean a mesma saída, a división non fai o que describe a documentación.

Anota dous fluxos e proba cada un

Para cada fluxo, anota que configuración aprobada debe transportalo e que resolutor debe recibir cada tipo de nome. Despois verifica con solicitudes novas, non cunha páxina de traballo en caché nin cun resultado de IP antigo.

Detén unha configuración e repite ambos os fluxos. O comportamento ante fallos forma parte do deseño, e é a parte que os usuarios notan. Cando os dous provedores non poden soportar a combinación, queda cunha configuración aprobada e documenta que fluxo transporta, ou pasa a un deseño xestionado dun só túnel. A documentación de NETunnelProviderManager é a fonte da regra de coexistencia.