Que protocolos este nó VPN público oferece realmente?

O software suporta-o, logo o nó oferece-o. Essa inferência está errada com frequência suficiente para ser uma regra: uma implementação de SoftEther pode ativar qualquer subconjunto dos seus métodos de ligação compatíveis, e um nó público é uma implementação com um proprietário e uma configuração. Aquilo a que consegue ligar-se depende desse nó, não da lista de funcionalidades do projeto que ele executa. É na lacuna entre os dois que vivem realmente a maioria dos pedidos «o protocolo está avariado».

O que a lista do projeto promete realmente

As funções de protocolo do projeto descrevem aquilo de que o servidor é capaz. Um determinado nó ativa alguns desses ouvintes e não outros, e o operador pode alterar esse conjunto sem tocar na versão do software. Por isso dois nós da mesma compilação comportam-se de forma diferente, e um perfil que funciona contra um não prova nada sobre o alvo seguinte. A lista do próprio nó tem mais peso do que a página do projeto quando escolhe onde se ligar.

Leia a lista como cinco campos, não como um menu: ponto final, porta, transporte, família de protocolos e método de autenticação. Um nó público que anuncia SSTP falou-lhe de um ouvinte numa porta; não lhe disse que certificado apresenta nem se a sua conta funciona ali. Comparar esses cinco campos com o seu perfil é mais rápido do que qualquer quantidade de reinstalação do cliente, e produz uma expectativa escrita que pode testar mais tarde.

Faça corresponder o perfil ao ponto final que ele nomeia

Uma entrada nativa de SoftEther não é automaticamente uma configuração de OpenVPN, mesmo quando ambas aparecem numa página de fornecedor sob um único título. Quando um nó publica tanto um ouvinte TCP como um UDP para OpenVPN, trate-os como dois pontos finais: um perfil editado de um para o outro aponta para um ouvinte que ninguém ativou. A etiqueta de transporte no ficheiro faz parte do endereço, não é um ajuste cosmético.

O facto de o cliente aceitar um ficheiro importado estabelece que o ficheiro é analisado. Não diz nada sobre se um ouvinte remoto espera no outro extremo, e é por isso que a primeira tentativa de ligação é o teste real. Compare a linha remota do perfil com o anfitrião e a porta anunciados do nó antes de culpar o protocolo.

Sonde a fase que falha

Um anfitrião que responde ao tráfego web pode ainda não ter o serviço VPN pretendido, e um anfitrião que recusa um protocolo não está necessariamente em baixo para todos. Esses dois erros enviam as pessoas em direções opostas na mesma tarde. Um persegue uma firewall que está bem; o outro reinstala um cliente que nunca foi o problema. Sonde cada caminho separadamente para que a resposta descreva um ouvinte e não o anfitrião inteiro.

Estas cinco verificações cobrem os métodos habituais dos nós públicos. Execute-as a partir da mesma rede que o cliente utiliza, porque uma porta filtrada parece idêntica a um ouvinte ausente visto de longe.

nc -vz node.example 1194
nc -vz node.example 443
openvpn --config client.ovpn --verb 4
nmap -sU -p 500,4500 node.example
openssl s_client -connect node.example:443 -servername node.example

Associe cada erro observado à sua linha antes de mudar algo. Uma falha de identidade TLS prova que o ouvinte existe, pelo que reescrever o perfil para outro protocolo descartaria uma prova que funciona. Uma ligação recusada prova apenas que esta porta não respondeu, o que é uma afirmação muito mais estreita do que «o nó não suporta OpenVPN».

Preserve o erro antes de mudar algo

Anote o resultado exato: um tempo esgotado, uma falha de identidade do certificado, uma rejeição de conta e uma negação ao nível da aplicação são quatro desfechos diferentes. Só o primeiro diz respeito a um protocolo indisponível, e só o último diz respeito a permissão após uma ligação bem-sucedida. Reiniciar o cliente ou trocar de protocolo destrói essa distinção, porque a falha seguinte chega com outro historial e sem linha de base para comparar.

Não enfraqueça a verificação para fazer um perfil incompatível parecer funcionar. Uma verificação de certificado desativada transforma uma falha de identidade clara numa ligação a algo que não pretendia alcançar, e o sucesso resultante é pior do que o erro original porque esconde qual fase estava errada.

Verifique novamente por nó, todas as vezes

As opções nativas SSL, OpenVPN, L2TP/IPsec e SSTP numa lista de nó público descrevem a configuração desse nó naquele momento. O mesmo software noutro local pode apresentar um conjunto diferente, e um fornecedor pode retirar um ouvinte entre o seu marcador e a sua próxima tentativa. As notas antigas descrevem implementações antigas.

Registe o perfil verificado com o seu ponto final e método, e depois repita a sonda quando o nó mudar ou a ligação começar a falhar. A especificação do protocolo SoftEther é a referência para aquilo que o software pode fazer; a lista do próprio nó é a referência para aquilo que ele faz. Mantenha os dois documentos separados e o diagnóstico torna-se mais curto.