Etapas do handshake VPN: o que acontece antes do tráfego fluir

Pressionar Conectar inicia quatro tarefas separadas que têm sucesso ou falham de forma independente. O cliente precisa alcançar um listener, concordar quem é o par, derivar chaves e então entregar um túnel funcional ao restante do sistema. A maioria das conexões falhas é diagnosticada na tarefa errada. Por isso o primeiro erro importa mais que a terceira tentativa.

Alcance primeiro o listener

Antes de qualquer identidade ser trocada, o cliente resolve um nome, escolhe uma rota e abre um transporte para uma porta. Um portal cativo que responde a tudo, uma porta fechada e um nome de host errado falham aqui, e nenhum deles é um problema de autenticação. Trocar uma senha não corrige nenhum dos três. Leia a primeira linha do erro antes de mexer nas credenciais.

Um tempo limite, uma rejeição de certificado e uma conta rejeitada são três falhas diferentes com três verificações diferentes. Classificá-las primeiro é o que impede que um problema de rede seja depurado como problema de credenciais.

Prove o par e depois derive as chaves

Cada protocolo precisa de uma forma de reconhecer o servidor pretendido, seja por uma chave pública configurada ou por uma cadeia de certificados. O login do usuário é adicional a essa verificação, não um substituto dela. Um servidor que aceita sua senha não provou nada sobre a própria identidade. Por isso um segredo compartilhado digitado em um cliente não substitui a verificação de quem respondeu.

A troca então deriva as chaves de tráfego a partir das próprias entradas do protocolo, e a senha de login geralmente não é a chave estampada em cada pacote. O material de identidade de longa duração e as chaves de sessão de curta duração têm vidas e tarefas diferentes. É dessa separação que trata a confidencialidade para a frente.

Mantenha a verificação ativada enquanto investiga, porque um túnel que se conecta depois de você desativar uma verificação não provou nada além de que a verificação fazia algo. Anote o que mudou e restaure antes do próximo teste.

Três protocolos, três conversas

Em uma implantação de OpenVPN baseada em TLS o canal de controle negocia os parâmetros de segurança enquanto o canal de dados transporta o tráfego do túnel, então uma opção de canal de dados e um problema de certificado vivem em lugares diferentes. O IKEv2 autentica os dois participantes e então estabelece associações de segurança IPsec com suas próprias vidas. O WireGuard deriva chaves pelo seu intercâmbio baseado em Noise e mantém a máquina de estados deliberadamente pequena. Saber qual dos três você executa decide qual log vale a pena ler.

Clientes de aparência semelhante não implicam mensagens intercambiáveis por baixo, e um campo de configuração que existe em um produto pode não ter equivalente em outro. Copiar um perfil entre eles é um palpite e não uma migração.

O que o handshake não faz

Rotas, resolução de nomes e política de destino permanecem todas depois. Um site interno pode ficar inalcançável porque falta a rota da sua sub-rede, mesmo que o par tenha sido autenticado corretamente e o túnel esteja ativo. Tratar isso como criptografia fraca manda você procurar na camada errada, e normalmente termina com uma troca de cifra que não corrige nada.

A renovação de chaves e a reconexão também se parecem na maioria das telas de status, e nenhuma das duas diz se o tráfego comum foi bloqueado durante a interrupção. Só a política de falha do cliente responde a essa pergunta, então leia a política e não o ícone.

Trabalhe as etapas na ordem acima e pare na primeira que produzir um erro. Cada etapa posterior herda o estado das anteriores, então uma falha na terceira etapa não diz nada sobre a quarta.

ip -brief address show tun0
ip route get 10.60.7.15
resolvectl query intranet.corp.internal