Duas VPN de iPhone ao mesmo tempo: qual transporta o seu tráfego?

Duas apps VPN mostram ambas Ligado, e assume-se que o tráfego agora passa pelas duas, uma dentro da outra. Normalmente não é assim. O iOS tem um modelo de coexistência específico, e não é uma cadeia. Uma classe de configuração está limitada a uma única instância ativada, a outra pode funcionar ao lado, e a precedência de rotas decide os conflitos. Dois interruptores acesos não são dois saltos. O modelo está documentado, o que significa que o caminho pode ser previsto em vez de adivinhado pelos ícones.

Mito: duas VPN ligadas são uma cadeia

Uma cadeia de dois saltos exige um transporte exterior definido, um túnel interior definido, um encaminhamento de extremos compatível e um plano para o que acontece quando um dos dois falha. Duas configurações independentes não criam isso por existirem ao mesmo tempo. A prioridade de rota não é o mesmo que a encapsulação, e o facto de uma configuração ganhar uma pesquisa de rota não diz nada sobre se a outra transporta os pacotes resultantes.

Se precisar de aninhamento, projete-o como aninhamento. Não o deduza de dois indicadores de ligação. Essa distinção poupa muita depuração.

O modelo documentado por detrás desse mito

O NETunnelProviderManager da Apple descreve configurações VPN empresariais normais e afirma que só uma desse tipo pode ser ativada de cada vez. A mesma referência permite que uma Personal VPN permaneça ativada e ligada ao lado, e dá precedência às rotas empresariais onde as duas se sobrepõem.

Aqui, a Personal VPN é o termo da API para a implementação integrada de IPsec ou IKEv2 gerida através do NEVPNManager. O NETunnelProviderManager é o modelo de fornecedor de túnel. Uma aplicação de consumo pode usar o modelo de fornecedor, por isso um nome de produto que contenha personal não o classifica.

A Apple documenta uma combinação permitida, e a permissão não lhe diz que os perfis de dois fornecedores são compatíveis, por isso pergunte a cada fornecedor qual o par suportado. Os tipos de configuração, as rotas e as políticas deles continuam a decidir o resultado.

Mito: a VPN pessoal recebe o tráfego de navegação

Um perfil de trabalho que reclama todos os destinos também ganhará a pesquisa de rota para a navegação pública, por isso a saída pessoal não transporta nada dela. Segundo a precedência documentada, as rotas empresariais ganham onde entram em conflito, por isso a navegação pública não toma automaticamente a saída pessoal só porque essa aplicação também comunica que está ligada. Uma configuração de trabalho mais estreita pode mudar o quadro de encaminhamento, mas o cliente da organização ainda pode impor requisitos de DNS, bloqueio ou dispositivo. Obtenha o arranjo suportado do proprietário em vez de editar esses requisitos localmente.

As configurações geridas por aplicação têm o seu próprio âmbito. Não extrapole uma regra ao nível do dispositivo para cada implementação gerida.

Anote os dois fluxos antes de testar: o nome e o intervalo privados do serviço de trabalho, e um novo pedido de navegação pública. Ambos são legítimos, e precisam de verificações diferentes.

Precedência de rotas com um perfil de trabalho de túnel dividido

Um perfil de trabalho com túnel dividido reclama os prefixos privados e o sufixo DNS interno que enumera, e essas rotas ganham qualquer pesquisa que corresponda a eles. Os destinos públicos que não correspondem a nenhuma rota empresarial caem na ligação física, a menos que a VPN pessoal os reclame primeiro. A regra de precedência decide apenas as correspondências sobrepostas, e é por isso que os dois perfis têm de ser lidos como tabelas de rotas e não como ícones.

Escreva o par em duas linhas e nomeie o vencedor esperado de cada uma: um nome de anfitrião de trabalho que resolva para 10.x ou 172.16.x deveria sair pelo túnel empresarial, e um endereço público sem prefixo correspondente deveria tomar a rota predefinida que restar. Se as duas linhas nomearem a mesma saída, a divisão não faz o que a documentação descreve.

Anote dois fluxos e teste cada um

Para cada fluxo, anote qual configuração aprovada o deve transportar e qual resolvedor deve receber cada tipo de nome. Depois verifique com pedidos novos, não com uma página de trabalho em cache nem com um resultado de IP antigo.

Pare uma configuração e repita os dois fluxos. O comportamento em caso de falha faz parte do projeto, e é a parte que os utilizadores notam. Quando os dois fornecedores não conseguem suportar a combinação, fique com uma configuração aprovada e documente que fluxo transporta, ou passe para um projeto gerido de túnel único. A documentação do NETunnelProviderManager é a fonte da regra de coexistência.