Iniciar uma segunda VPN substitui o estado da primeira
Um telefone permite um serviço VPN de cada vez; num computador, os clientes disputam as mesmas rotas. Nenhum dos dois produz um túnel aninhado sem um projeto real.
Dois clientes, dois ícones conectados e a crença de que o tráfego agora passa pelos dois. Compare essa crença com o que cada plataforma realmente permite. Um telefone normalmente tem exatamente um espaço para um serviço VPN; um computador pode executar vários clientes que disputam as mesmas rotas e o mesmo resolvedor. A diferença entre essas duas situações explica a maioria dos relatos de VPN que cai quando outra começa.
Os ícones descrevem processos, não uma cadeia.
Um espaço no telefone, vários candidatos no computador
No Android, a plataforma oferece um modelo de serviço VPN com apenas uma VPN ativa por perfil de usuário, então iniciar uma segunda para a primeira. É o sistema aplicando sua própria regra, não um bug em nenhum dos clientes. Num computador, vários clientes podem continuar em execução ao mesmo tempo, e então competem pela tabela de roteamento, regras de política, configuração do resolvedor e interfaces virtuais. Ambos os resultados são a plataforma funcionando conforme o projeto.
Nenhum dos resultados produz por si só um túnel aninhado. Uma cadeia exige que um túnel carregue os pacotes criptografados do outro, e isso é arquitetura, não uma coincidência de ordem.
O que o segundo cliente sobrescreve
O segundo cliente normalmente instala uma rota padrão, adiciona suas próprias regras e impõe seu próprio resolvedor. O primeiro pode sobreviver como processo sem tráfego ou manter uma rota que já não vence. Rotas específicas de domínio costumam ser a vítima, e por isso alguns destinos continuam funcionando enquanto outros falham. O sintoma visível é uma desconexão, e o estado real é uma substituição parcial.
Uma verificação do IP de saída não revelará isso. Ela informa um endereço para um destino e não diz nada sobre quais rotas foram sobrescritas ou qual resolvedor responde agora. Para ver o dano, leia a tabela de roteamento e o estado do resolvedor.
Aninhamento é um projeto, não uma ordem de cliques
Se o aninhamento é a intenção, documente o caminho externo de cada extremidade, sua política de falha e as consequências para a MTU. Decida o que acontece quando o túnel externo cai enquanto o interno ainda acredita estar conectado. Iniciar clientes numa ordem de sorte não é uma configuração, porque a próxima atualização ou reconexão os reordena. Um arranjo aninhado exige o mesmo cuidado que qualquer outra topologia.
Quando uma conexão é para o trabalho e outra é pessoal, apoie-se no isolamento ou arranjo gerenciado que a plataforma suportar. Arrancar os controles corporativos não é uma estratégia de separação.
Verifique com o aplicativo, não com o ícone
Exercite os aplicativos que realmente importam, de cada contexto que pretende usar, e inclua o comportamento do resolvedor e as reconexões no teste. Um endereço de saída final não consegue identificar cada rota sobrescrita, e um ícone verde não consegue identificar nenhuma delas. Anote quem possui a conexão e qual combinação é realmente suportada.
Se um produto não suporta explicitamente a coexistência com outro, uma mudança aleatória de rota ou de permissão não produzirá uma implantação sustentável. Produzirá uma que funciona até a próxima atualização.
Anote qual cliente possui a rota padrão, qual resolvedor responde e o que acontece quando cada um para.