O segundo cliente VPN quebrou o primeiro: encontre o recurso compartilhado

Ontem o cliente original funcionava. Hoje o recém-chegado exige uma conexão enquanto o perfil antigo para num estágio que antes atravessava sem queixa. As credenciais raramente estão envolvidas, e o gateway costuma ser inocente. O que mudou é que duas pilhas VPN agora querem o mesmo recurso exclusivo, e o reparo depende de nomeá-lo. Percorra as camadas em vez de reinstalar os dois.

Percorra as quatro camadas em ordem

Um produto VPN precisa de quatro recursos que podem colidir: um serviço em segundo plano que muitas vezes se recusa a rodar duas vezes, uma porta fixa, um adaptador virtual ou filtro de kernel que vê o tráfego antes da tabela de roteamento, e o direito de instalar rotas à frente da padrão. Saber qual cedeu transforma um conflito vago numa única pergunta com resposta testável.

Mapeie o sintoma para uma camada antes de tocar em qualquer coisa. Um cliente que não inicia aponta para o serviço; um que inicia e nunca negocia aponta para a porta; um que conecta enquanto o outro perde toda a conectividade aponta para o filtro ou para a rota padrão. Anote esse mapeamento, porque economiza uma hora de reinstalar aplicativos na esperança.

Comece pelo serviço que não roda duas vezes

No Windows um cliente corporativo costuma ser mais que um túnel, porque instala um serviço, um driver de filtro e às vezes um provedor de credenciais junto com o perfil. Anote quais serviços rodam antes da mudança e de novo depois, e então compare as duas listas em vez de reiniciar até algo funcionar. Os serviços também podem se excluir por dependências, em que iniciar um para o outro, e o mesmo padrão aparece no macOS com tarefas launchd e um daemon compartilhado. Um cliente que inicia e sai em segundos está relatando propriedade, não configuração.

Leia o estado do serviço e o log antes de ler o perfil. Um serviço que iniciou e parou no mesmo minuto é o padrão a procurar, e o próprio log de eventos nomeia a dependência que o deslocou. Um perfil não pode reparar um processo que não está rodando, e o tempo gasto editando-o é tempo não gasto no conflito real.

Depois pergunte quem é o dono da porta

A posse da porta é a evidência mais clara que você vai obter, porque uma falha de bind nomeia o conflito diretamente. Duas implementações IKE não podem ambas responder no mesmo endereço local e porta UDP, e nenhuma quantidade de novas tentativas muda isso.

Get-NetUDPEndpoint -LocalPort 500,4500 | Select-Object LocalAddress,LocalPort,OwningProcess
netstat -ano | findstr :500
sudo lsof -nP -iUDP:500
ss -lunp | grep -E ':500|:4500'

Qualquer que seja a linha que corresponda à sua plataforma, a resposta que você quer é um processo e o serviço que o gerou. Se o ouvinte é o serviço IKE embutido, o segundo cliente é o intruso; se é um agente de fornecedor, o cliente embutido é o intruso. Decida qual pode iniciar no login e desative a inicialização automática do outro em vez de matá-lo a cada sessão.

O driver de filtro fica abaixo das suas rotas

Um driver de filtro de rede intercepta o tráfego entre o adaptador e a pilha de protocolos, então pode reescrever ou bloquear pacotes independentemente do que diz a tabela de roteamento. É assim que uma rota que parece correta é ignorada, e por isso um ping bem-sucedido pode conviver com um navegador que não carrega nada.

Os componentes do fornecedor também se ligam a conexões específicas. Um filtro antigo ligado a um adaptador pode impedir um perfil de outra forma correto de concluir o handshake, e desligar esse componente das propriedades do adaptador é mais estreito e mais reversível do que remover o produto por completo. Como a ligação é por conexão, compare os adaptadores em vez de toda a pilha.

Decida qual produto é dono do boot, depois registre isso

A coexistência só é realista quando os dois clientes ocupam camadas diferentes por projeto, como uma pilha IPsec ao lado de um proxy que só trata do tráfego de aplicativos. Onde ambos querem a mesma porta, a mesma camada de filtro ou o direito de publicar uma rota padrão, eles vão continuar se alternando e cada falha vai parecer um novo defeito.

Escolha o dono deliberadamente. As formas que sobrevivem a uma reinicialização incluem executar o segundo cliente dentro de uma máquina virtual, mantê-lo em hardware dedicado ou padronizar um único cliente que fale os dois protocolos. Desativar a inicialização automática e o serviço do perdedor é uma mudança menor do que reconstruir a tabela de roteamento após cada início, e isso se reverte com uma única edição de configuração.