Que protocolos ofrece realmente este nodo VPN público?
Que o software do servidor admita un protocolo non significa que este nodo o activase. Comproba o punto de conexión, o perfil e a etapa que realmente falla.
O software admíteo, polo tanto o nodo ofréceo. Esa inferencia é errónea con suficiente frecuencia como para ser unha regra: un despregamento de SoftEther pode activar calquera subconxunto dos seus métodos de conexión compatibles, e un nodo público é un despregamento cun propietario e unha configuración. Con que podes conectarte depende dese nodo, non da lista de funcións do proxecto que executa. A fenda entre ambos é onde viven en realidade a maioría dos tíckets de «o protocolo está roto».
Que promete en realidade a lista do proxecto
As funcións de protocolo do proxecto describen do que é capaz o servidor. Un nodo determinado activa algúns deses escoitantes e non outros, e o operador pode cambiar ese conxunto sen tocar a versión do software. Por iso dous nodos da mesma compilación compórtanse de forma distinta, e un perfil que funciona contra un non demostra nada sobre o seguinte obxectivo. A lista do propio nodo pesa máis ca a páxina do proxecto cando elixes onde conectarte.
Le a lista como cinco campos, non como un menú: punto de conexión, porto, transporte, familia de protocolos e método de autenticación. Un nodo público que anuncia SSTP falouche dun escoitante nun porto; non che dixo que certificado presenta nin se a túa conta funciona alí. Comparar eses cinco campos co teu perfil é máis rápido ca calquera cantidade de reinstalación do cliente, e produce unha expectativa escrita que podes probar máis adiante.
Axusta o perfil ao punto de conexión que nomea
Unha entrada nativa de SoftEther non é automaticamente unha configuración de OpenVPN, mesmo cando ambas aparecen nunha páxina de provedor baixo un mesmo encabezado. Cando un nodo publica tanto un escoitante TCP coma un UDP para OpenVPN, trátaos como dous puntos de conexión: un perfil editado dun ao outro apunta a un escoitante que ninguén activou. A etiqueta de transporte do ficheiro forma parte do enderezo, non é un axuste estético.
Que o cliente acepte un ficheiro importado demostra que o ficheiro se analiza. Non di nada sobre se un escoitante remoto espera no outro extremo, e por iso o primeiro intento de conexión é a proba real. Compara a liña remota do perfil co host e o porto anunciados do nodo antes de culpar o protocolo.
Sonda a etapa que falla
Un host que responde ao tráfico web aínda pode carecer do servizo VPN previsto, e un host que rexeita un protocolo non está necesariamente caído para todos. Eses dous erros envían a xente en direccións opostas a mesma tarde. Un persegue un devasado que está ben; o outro reinstala un cliente que nunca foi o problema. Sonda cada ruta por separado para que a resposta describa un escoitante e non todo o host.
Estas cinco comprobacións cobren os métodos habituais dos nodos públicos. Execútaas desde a mesma rede que usa o cliente, porque un porto filtrado parece idéntico a un escoitante ausente desde lonxe.
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| Resultado | Etapa | Que descarta |
|---|---|---|
| Conexión rexeitada ou tempo esgotado | Transporte | Escoitante ausente, filtrado ou porto incorrecto |
| Erro de negociación TLS ou de identidade | Certificado | Dispoñibilidade do protocolo; o escoitante respondeu |
| AUTH_FAILED ou rexeitamento da conta | Autenticación | O punto de conexión; o problema son as credenciais |
| UDP 500 e 4500 en silencio | Negociación de IPsec | ESP e L2TP están bloqueados antes da autenticación |
Asigna cada erro observado á súa fila antes de cambiar nada. Un fallo de identidade TLS demostra que o escoitante existe, así que reescribir o perfil cara a outro protocolo descartaría unha proba que funciona. Unha conexión rexeitada só demostra que este porto non respondeu, o que é unha afirmación moito máis estreita ca «o nodo non admite OpenVPN».
Conserva o erro antes de cambiar nada
Anota o resultado exacto: un tempo esgotado, un fallo de identidade do certificado, un rexeitamento da conta e unha denegación a nivel de aplicación son catro desenlaces distintos. Só o primeiro trata dun protocolo non dispoñible, e só o último trata de permisos tras unha conexión correcta. Reiniciar o cliente ou cambiar de protocolo destrúe esa distinción, porque o seguinte fallo chega con outro historial e sen liña base coa que comparar.
Non debilites a verificación para que un perfil incompatible pareza funcionar. Unha comprobación de certificado desactivada converte un fallo de identidade claro nunha conexión a algo que non pretendías alcanzar, e o éxito resultante é peor có erro orixinal porque oculta que etapa estaba mal.
Volve comprobar por cada nodo, cada vez
As opcións nativas SSL, OpenVPN, L2TP/IPsec e SSTP dunha lista de nodo público describen a configuración dese nodo naquel momento. O mesmo software noutro lugar pode presentar un conxunto distinto, e un provedor pode retirar un escoitante entre o teu marcador e o teu seguinte intento. As notas antigas describen despregamentos antigos.
Anota o perfil verificado co seu punto de conexión e método, e despois repite a sonda cando o nodo cambie ou a conexión comece a fallar. A especificación do protocolo SoftEther é a referencia do que o software pode facer; a lista do propio nodo é a referencia do que fai. Mantén os dous documentos separados e o diagnóstico faise máis curto.