A configuração VPN pública parou de funcionar? Leia o estágio da falha

O perfil funcionava na terça, e na sexta o cliente gira por trinta segundos e desiste. Nada mudou na sua máquina. É exatamente esse o ponto: uma configuração baixada descreve um host em um instante, e o operador do outro lado não tem obrigação de manter essa descrição verdadeira. A tentação é começar a editar configurações de segurança até o túnel voltar. É justamente esse impulso que leva as pessoas a acabar rodando um perfil com a verificação de certificados desativada, o que é pior do que não ter túnel nenhum.

O arquivo descreve um instante, não um contrato

Um arquivo de configuração é um conjunto de asserções: este nome de host escuta nesta porta com este protocolo, apresenta um certificado que corresponde a este nome e aceita estas credenciais. Quando qualquer uma delas deixa de ser verdadeira, o arquivo está desatualizado e a correção pertence ao lado do operador da fronteira, não às suas configurações.

Listas de nós públicas tornam isso explícito por natureza. Os nós são mantidos por voluntários, aparecem e desaparecem, endereços são reciclados e portas são bloqueadas pela rede atrás da qual estão. A lista é um instantâneo que é regenerado, e a cópia no seu disco é uma fotografia de um instantâneo mais antigo.

Serviços comerciais mudam mais devagar, mas não nunca. Autoridades certificadoras rotacionam, um ouvinte passa de um endereço compartilhado para um dedicado, um protocolo antigo é retirado e uma nova lista de cifras chega. Cada uma dessas mudanças é invisível até seu cliente tentar conectar e receber uma resposta diferente da que o arquivo espera.

Leia o estágio da falha antes de tocar em uma configuração

A mensagem de erro diz qual asserção falhou, e cada asserção tem uma correção completamente diferente. Editar cifras quando o nome do host não resolve mais desperdiça uma tarde e não ensina nada a ninguém.

dig +short vpn.example.net
curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect}\n' --max-time 8 https://vpn.example.net:443/
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

A linha do meio separa um caminho bloqueado de um handshake quebrado, e a terceira mostra o emissor e as datas de validade do certificado que é realmente apresentado. Se esse emissor não é o que o perfil fixou, o certificado mudou, e nenhuma opção do lado do cliente fará a fixação antiga voltar a estar correta.

As mudanças de certificado e de identidade são as silenciosas

A maioria das falhas se anuncia. As mudanças de identidade não, porque um cliente que fixa um nome de certificado recusará um certificado novo perfeitamente bom com uma mensagem que muita gente lê como um bug. O túnel está bem. A fixação está desatualizada.

Procure as opções de identidade antes de concluir qualquer coisa:

grep -nE '^(remote|proto|auth|verify-x509-name|tls-crypt|key-direction|ca) ' profile.ovpn
openssl x509 -in profile-ca.crt -noout -subject -dates

Se o perfil traz uma CA embutida e o operador migrou para uma nova autoridade, o arquivo antigo não consegue validar o servidor novo. Substituir o bloco de CA pelo publicado pelo operador é uma correção legítima. Apagar a diretiva de verificação não é, e são as mesmas teclas com um resultado muito diferente.

Uma atualização do cliente pode produzir o mesmo sintoma sem nenhuma mudança do operador. Opções que eram toleradas em silêncio agora são recusadas, ou um protocolo obsoleto é removido. É um limite de compatibilidade do seu software, e vale a pena testar um segundo perfil no mesmo cliente antes de culpar o servidor.

Só o operador pode publicar um substituto válido

Quando um nó desaparece, o substituto tem de vir da mesma fonte que publicou o original. Um perfil que chega em mensagem direta porque «usa o mesmo nome de servidor» é uma configuração não verificada de uma parte desconhecida, e importá-lo entrega a essa parte o controle do seu roteamento.

A checagem é barata. Busque o arquivo atual no local publicado, compare o endpoint e o protocolo com a lista, e confirme a impressão digital do material da CA em vez de confiar no nome do arquivo:

curl -sS -o current.ovpn https://example.org/nodes/current.ovpn
sha256sum current.ovpn profile.ovpn
grep -nE '^(remote|proto) ' current.ovpn

Se os dois hashes diferem apenas em espaços, você tem uma mudança de formatação. Se diferem nos endpoints, o operador moveu algo e o arquivo publicado é a autoridade. Se o arquivo publicado é mais antigo que o que você tem, provavelmente está olhando um cache, e a resposta desatualizada vai mandá-lo na direção errada.

Aposente a entrada antiga e registre o que aconteceu

Depois de verificar um substituto funcional, apague o perfil antigo em vez de guardá-lo como reserva. Uma entrada desatualizada que conecta pela metade é uma armadilha: será escolhida durante uma queda, falhará devagar, e quem depurar vai passar os primeiros dez minutos no arquivo errado.

Mantenha um registro curto fora da configuração: a data, o endpoint antigo, o estágio da falha e o que o substituiu. Os nós públicos mudam, e seis semanas depois a mesma pergunta chega com outra pessoa. Uma linha em um arquivo de notas responde em segundos.

Se a partir de uma rede todos os nós falham da mesma forma e a partir de outra nenhum falha, pare de editar perfis e olhe o caminho local. Um portal cativo, uma faixa de portas filtrada ou um proxy interceptador produzirão erros idênticos em provedores não relacionados, e esse padrão é o único sinal de que o problema nunca foi o arquivo.