Quins protocols ofereix realment aquest node VPN públic?
Que el programari del servidor admeti un protocol no vol dir que aquest node l’hagi activat. Comprova el punt final, el perfil i l’etapa que realment falla.
El programari l’admet, per tant el node l’ofereix. Aquesta inferència és errònia amb prou freqüència per ser una regla: un desplegament de SoftEther pot activar qualsevol subconjunt dels seus mètodes de connexió compatibles, i un node públic és un desplegament amb un propietari i una configuració. Amb què pots connectar-te depèn d’aquell node, no de la llista de funcions del projecte que executa. La bretxa entre tots dos és on viuen realment la majoria de tiquets de “el protocol està trencat”.
Què promet realment la llista del projecte
Les funcions de protocol del projecte descriuen què és capaç de fer el servidor. Un node determinat activa alguns d’aquests oients i no altres, i l’operador pot canviar aquest conjunt sense tocar la versió del programari. Per tant, dos nodes de la mateixa compilació es comporten de manera diferent, i un perfil que funciona contra un no demostra res sobre el següent objectiu. La llista del propi node té més pes que la pàgina del projecte quan tries on connectar-te.
Llegeix la llista com cinc camps, no com un menú: punt final, port, transport, família de protocols i mètode d’autenticació. Un node públic que anuncia SSTP t’ha parlat d’un oient en un port; no t’ha dit quin certificat presenta ni si el teu compte hi funciona. Comparar aquests cinc camps amb el teu perfil és més ràpid que qualsevol quantitat de reinstal·lació del client, i produeix una expectativa escrita que pots provar més endavant.
Fes coincidir el perfil amb el punt final que anomena
Una entrada nativa de SoftEther no és automàticament una configuració d’OpenVPN, fins i tot quan totes dues apareixen en una pàgina de proveïdor sota un sol encapçalament. Quan un node publica tant un oient TCP com un UDP per a OpenVPN, tracta’ls com dos punts finals: un perfil editat d’un a l’altre apunta a un oient que ningú no ha activat. L’etiqueta de transport del fitxer forma part de l’adreça, no és un paràmetre estètic.
Que el client accepti un fitxer importat estableix que el fitxer s’analitza. No diu res sobre si un oient remot espera a l’altre extrem, i per això el primer intent de connexió és la prova real. Compara la línia remota del perfil amb l’amfitrió i el port anunciats del node abans de culpar el protocol.
Sondeja l’etapa que falla
Un amfitrió que respon al trànsit web encara pot no tenir el servei VPN previst, i un amfitrió que rebutja un protocol no està necessàriament caigut per a tots. Aquests dos errors envien la gent en direccions oposades la mateixa tarda. Un persegueix un tallafoc que està bé; l’altre reinstal·la un client que mai no va ser el problema. Sondeja cada camí per separat perquè la resposta descrigui un oient i no tot l’amfitrió.
Aquestes cinc comprovacions cobreixen els mètodes habituals dels nodes públics. Executa-les des de la mateixa xarxa que fa servir el client, perquè un port filtrat sembla idèntic a un oient absent des de lluny.
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| Resultat | Etapa | Què descarta |
|---|---|---|
| Connexió rebutjada o temps esgotat | Transport | Oient absent, filtrat o port incorrecte |
| Error de negociació TLS o d’identitat | Certificat | Disponibilitat del protocol; l’oient ha respost |
| AUTH_FAILED o rebuig del compte | Autenticació | El punt final; el problema són les credencials |
| UDP 500 i 4500 en silenci | Negociació IPsec | ESP i L2TP estan bloquejats abans de l’autenticació |
Assigna cada error observat a la seva fila abans de canviar res. Una fallada d’identitat TLS demostra que l’oient existeix, així que reescriure el perfil cap a un altre protocol descartaria una prova que funciona. Una connexió rebutjada només demostra que aquest port no ha respost, que és una afirmació molt més estreta que “el node no admet OpenVPN”.
Conserva l’error abans de canviar res
Anota el resultat exacte: un temps esgotat, una fallada d’identitat del certificat, un rebuig del compte i una denegació a nivell d’aplicació són quatre desenllaços diferents. Només el primer tracta d’un protocol no disponible, i només l’últim tracta de permisos després d’una connexió correcta. Reiniciar el client o canviar de protocol destrueix aquesta distinció, perquè la propera fallada arriba amb un historial diferent i sense línia base per comparar.
No debilitis la verificació per fer que un perfil incompatible sembli funcionar. Una comprovació de certificat desactivada converteix una fallada d’identitat clara en una connexió a una cosa a la qual no volies arribar, i l’èxit resultant és pitjor que l’error original perquè amaga quina etapa estava malament.
Torna a comprovar per cada node, cada vegada
Les opcions natives SSL, OpenVPN, L2TP/IPsec i SSTP d’una llista de node públic descriuen la configuració d’aquell node en aquell moment. El mateix programari en un altre lloc pot presentar un conjunt diferent, i un proveïdor pot retirar un oient entre el teu marcador i el teu proper intent. Les notes antigues descriuen desplegaments antics.
Anota el perfil verificat amb el seu punt final i mètode, i després repeteix la sonda quan el node canviï o la connexió comenci a fallar. L’especificació del protocol SoftEther és la referència del que pot fer el programari; la llista del propi node és la referència del que fa. Mantén els dos documents separats i el diagnòstic es fa més curt.