Como verificar o servidor de um perfil OpenVPN antes de importá-lo

Alguém lhe envia um perfil, você o importa e trinta segundos depois um cliente disca um destino que ninguém verificou. Leia primeiro o arquivo num editor de texto, porque tudo o que importa cabe num punhado de diretivas: remote, proto, port, ca, cert, tls-crypt e verify-x509-name. Todo o resto são valores padrão, e é aí que vivem as surpresas.

Liste cada endpoint que o arquivo pode usar

Comece pelos endpoints, porque um perfil pode conter vários. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn imprime cada candidato na ordem do arquivo, incluindo os aninhados em blocos <connection> em linha.

Quando uma diretiva omite a porta, o cliente recorre ao padrão do ouvinte, então apenas remote vpn.example.com significa porta 1194 com qualquer proto que apareça mais adiante no arquivo. Várias linhas remote simples são alternativas: o cliente tenta-as em ordem, a menos que remote-random as misture, e nunca substitui em silêncio o host de outro operador. Duas linhas remote em domínios não relacionados é o ponto onde você para e pergunta qual era a pretendida.

Observe também a grafia de proto. tcp é aceito como sinônimo do tcp-client do lado cliente, mas tcp-server num perfil de cliente é um erro de configuração que tende a travar em vez de falhar de forma limpa.

Confirme o nome, depois a porta

dig +short vpn.example.com diz se o nome existe e quais endereços devolve, e um endpoint com vários endereços ou atrás de um proxy pode devolver vários legitimamente. A resolução é um pré-requisito, não uma prova de propriedade; qualquer pessoa pode apontar um nome para um endereço, e um endereço pode responder por muitos nomes.

Depois verifique o ouvinte na porta que encontrou, de acordo com o transporte. Sobre TCP, openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com imprime a cadeia que o servidor apresenta. Sobre UDP você precisa de DTLS: openssl s_client -dtls1_2 -connect vpn.example.com:1194 executa o mesmo handshake por datagramas. Um handshake concluído prova que algo escuta e detém um certificado, o que é mais do que um ping mostra e menos do que as próprias configurações de confiança do perfil exigem.

Quando o handshake falha e o host responde ao ping, a porta provavelmente está errada ou filtrada. Tome isso como motivo para pedir a porta correta, não como convite para varrer as vizinhas. nc -vzu também relata sucesso em algumas pilhas sem que nada escute, então uma sonda UDP nua não significa nada sem um handshake por trás.

Leia os pinos de confiança separados do endereço

O endereço decide para onde o cliente vai; o bloco de confiança decide em quem ele acredita ao chegar. verify-x509-name "vpn.example.com" name fixa o nome comum do sujeito, e remote-cert-tls server exige o uso estendido da chave para a autenticação do servidor. Um perfil entregue por um operador deve trazer os dois.

Procure ca, um bloco <ca> em linha e tls-crypt ou tls-auth. Um perfil que usa tls-auth precisa de key-direction 1 no cliente quando o lado do servidor usa a direção 0, e uma incompatibilidade faz o handshake falhar com um erro TLS que se lê como defeito de certificado. Um CA em linha que não pertence ao operador cujo nome você acabou de resolver significa que o arquivo foi montado a partir de duas fontes, e esse é o caso que vale recusar de imediato.

verify-x509-name aceita os modos name, name-prefix ou subject, e o último espera um nome distinto completo na ordem exata em que o servidor o imprime. Escolha um modo que se ajuste à forma do valor, porque o cliente rejeita cada conexão em vez de avisar sobre um quase acerto. Para um arquivo que você não escreveu, name com um nome de host simples é a escolha menos surpreendente.

Verifique as opções que falham em silêncio

OpenVPN 2.6 negocia os cifradores por data-ciphers, e um perfil que traz apenas uma linha cipher AES-256-CBC antiga pode concluir o canal de controle e depois travar nos dados. Ler esse valor diz se o arquivo é anterior ao servidor a que você se junta; a página de manual da 2.6 lista a ordem de negociação se precisar citá-la ao operador.

auth-user-pass sem nome de arquivo significa que o cliente vai perguntar, então um perfil que parece autossuficiente ainda precisa de credenciais. auth-user-pass credentials.txt significa que espera um arquivo que provavelmente não lhe foi enviado. nobind e resolv-retry infinite são comuns e inofensivos, enquanto explicit-exit-notify é só para UDP e inútil por TCP.

Nada disso muda para onde o perfil se conecta, mas cada uma muda se ele se conecta sequer, e nenhuma é visível no diálogo de importação do cliente.

Decida e depois registre o que decidiu

Depois desta leitura há três desfechos, e só um é importação. Quando o endpoint e os pinos coincidem com instruções recebidas por um canal separado, importe-o. Quando o endpoint parece correto mas os pinos ou o CA não coincidem, peça um arquivo corrigido. Quando o arquivo mistura endpoints ou material de CA de fontes diferentes, apague-o e peça uma cópia nova.

Registre o hash que revisou, para que a próxima pessoa saiba se o arquivo mudou: sha256sum profile.ovpn, colado ao lado do endpoint nas suas notas. Um perfil é um arranjo inteiro, não uma lista de endereços, então nunca enxerte um remote que funciona no bloco de confiança de outra pessoa mantendo as credenciais dela.

Mantenha as chaves privadas e as palavras-passe fora de capturas de ecrã e de conversas enquanto compara notas. O endpoint e as opções não secretas bastam para fazer uma pergunta precisa, e o resto pertence ao arquivo.

Se acabar importando-o e a primeira tentativa falhar, execute o cliente com --verb 3 e leia as dez primeiras linhas: o endereço remote resolvido, o proto negociado e o erro TLS aparecem nessa ordem, o que diz qual das verificações acima saltou.