Iniciar unha segunda VPN substitúe o estado da primeira

Dous clientes, dúas iconas de conectado e a crenza de que o tráfico agora pasa por ambos. Compare esa crenza co que cada plataforma permite realmente. Un teléfono adoita ter exactamente unha ranura para un servizo VPN; un ordenador pode executar varios clientes que compiten polas mesmas rutas e o mesmo resolvedor. A diferenza entre esas dúas situacións explica a maioría dos informes dunha VPN que cae cando se inicia outra.

As iconas describen procesos, non unha cadea.

Unha ranura no teléfono, varios aspirantes no ordenador

En Android, a plataforma ofrece un modelo de servizo VPN cunha única VPN activa por perfil de usuario, así que iniciar unha segunda detén a primeira. É o sistema aplicando a súa propia regra, non un fallo de ningún dos clientes. Nun ordenador, varios clientes poden seguir executándose á vez e entón compiten pola táboa de enrutamento, as regras de política, a configuración do resolvedor e as interfaces virtuais. Ambos os resultados son a plataforma funcionando segundo o seu deseño.

Ningún dos dous resultados produce por si mesmo un túnel aniñado. Unha cadea require que un túnel transporte os paquetes cifrados do outro, e iso é unha arquitectura, non unha casualidade de orde.

Que sobrescribe o segundo cliente

O segundo cliente adoita instalar unha ruta predeterminada, engade as súas propias regras e impón o seu propio resolvedor. O primeiro pode sobrevivir como un proceso sen tráfico ou conservar unha ruta que xa non gaña. As rutas específicas de dominio son a vítima habitual, e por iso algúns destinos seguen funcionando mentres outros fallan. O síntoma visible é unha desconexión, e o estado real é unha substitución parcial.

Unha comprobación do IP de saída non revelará isto. Informa dun enderezo para un destino e non di nada sobre que rutas se sobrescribiron ou que resolvedor responde agora. Para ver o dano, lea a táboa de enrutamento e o estado do resolvedor.

A aniñación é un deseño, non unha orde de clics

Se a intención é a aniñación, documente o camiño exterior de cada extremo, a súa política de fallo e as consecuencias para a MTU. Decida que ocorre cando o túnel exterior cae mentres o interior aínda cre estar conectado. Iniciar os clientes nunha orde afortunada non é unha configuración, porque a seguinte actualización ou reconexión reordénaos. Un arranxo aniñado necesita o mesmo coidado que calquera outra topoloxía.

Cando unha conexión é para o traballo e outra é persoal, apóiase no illamento ou no arranxo xestionado que a plataforma admita. Arrancar os controis corporativos non é unha estratexia de separación.

Verifique coa aplicación, non coa icona

Exercite as aplicacións que de verdade importan, desde cada contexto que pense usar, e inclúa o comportamento do resolvedor e as reconexións na proba. Un enderezo de saída final non pode identificar cada ruta sobrescrita, e unha icona verde non pode identificar ningunha delas. Anote quen posúe a conexión e que combinación se admite realmente.

Se un produto non admite explicitamente a coexistencia con outro, un cambio aleatorio de ruta ou de permiso non producirá un despregamento mantible. Producirá un que funcione ata a próxima actualización.

Anote que cliente posúe a ruta predeterminada, que resolvedor responde e que ocorre cando cada un se detén.