Quali protocolli offre davvero questo nodo VPN pubblico?

Il software lo supporta, quindi il nodo lo offre. Questa deduzione è sbagliata abbastanza spesso da diventare una regola: un deployment SoftEther può attivare qualsiasi sottoinsieme dei suoi metodi di connessione compatibili, e un nodo pubblico è un deployment con un proprietario e una configurazione. Ciò a cui puoi connetterti dipende da quel nodo, non dall’elenco di funzionalità del progetto che esegue. È nel divario tra i due che vivono davvero la maggior parte dei ticket «il protocollo è rotto».

Cosa promette davvero l’elenco del progetto

Le funzioni di protocollo del progetto descrivono ciò di cui il server è capace. Un dato nodo attiva alcuni di quegli ascoltatori e non altri, e l’operatore può cambiare quell’insieme senza toccare la versione del software. Due nodi sulla stessa build si comportano quindi diversamente, e un profilo che funziona contro uno non dimostra nulla sul bersaglio successivo. L’elenco del nodo stesso ha più peso della pagina del progetto quando scegli dove connetterti.

Leggi l’elenco come cinque campi, non come un menu: endpoint, porta, trasporto, famiglia di protocolli e metodo di autenticazione. Un nodo pubblico che annuncia SSTP ti ha parlato di un ascoltatore su una porta; non ti ha detto quale certificato presenta né se il tuo account funziona lì. Confrontare quei cinque campi con il tuo profilo è più veloce di qualsiasi quantità di reinstallazione del client, e produce un’aspettativa scritta che puoi verificare in seguito.

Fai combaciare il profilo con l’endpoint che nomina

Una voce SoftEther nativa non è automaticamente una configurazione OpenVPN, anche quando entrambe compaiono su una pagina del provider sotto un unico titolo. Quando un nodo pubblica sia un ascoltatore TCP sia uno UDP per OpenVPN, trattali come due endpoint: un profilo modificato da uno all’altro punta a un ascoltatore che nessuno ha attivato. L’etichetta di trasporto nel file fa parte dell’indirizzo, non è un’impostazione cosmetica.

Il fatto che il client accetti un file importato stabilisce che il file viene analizzato. Non dice nulla sulla presenza di un ascoltatore remoto dall’altra parte, ed è per questo che il primo tentativo di connessione è la prova reale. Confronta la riga remota del profilo con l’host e la porta annunciati del nodo prima di dare la colpa al protocollo.

Sonda la fase che fallisce

Un host che risponde al traffico web può comunque mancare del servizio VPN previsto, e un host che rifiuta un protocollo non è necessariamente inattivo per tutti. Questi due errori mandano le persone in direzioni opposte lo stesso pomeriggio. Uno insegue un firewall che va bene; l’altro reinstalla un client che non è mai stato il problema. Sonda ogni percorso separatamente, così la risposta descrive un ascoltatore e non l’intero host.

Questi cinque controlli coprono i metodi comuni dei nodi pubblici. Eseguili dalla stessa rete che usa il client, perché una porta filtrata sembra identica a un ascoltatore assente da lontano.

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

Abbina ogni errore osservato alla sua riga prima di cambiare qualcosa. Un errore di identità TLS prova che l’ascoltatore esiste, quindi riscrivere il profilo verso un altro protocollo butterebbe via una prova che funziona. Una connessione rifiutata prova solo che questa porta non ha risposto, che è un’affermazione molto più stretta di «il nodo non supporta OpenVPN».

Conserva l’errore prima di cambiare qualcosa

Annota il risultato esatto: un timeout, un errore di identità del certificato, un rifiuto dell’account e un diniego a livello applicativo sono quattro esiti diversi. Solo il primo riguarda un protocollo non disponibile, e solo l’ultimo riguarda un permesso dopo una connessione riuscita. Reimpostare il client o cambiare protocollo distrugge questa distinzione, perché il fallimento successivo arriva con una cronologia diversa e senza una linea di base con cui confrontarsi.

Non indebolire la verifica per far sembrare che un profilo incompatibile funzioni. Un controllo del certificato disattivato trasforma un chiaro errore di identità in una connessione a qualcosa che non intendevi raggiungere, e il successo che ne deriva è peggiore dell’errore originale perché nasconde quale fase era sbagliata.

Ricontrolla per ogni nodo, ogni volta

Le opzioni native SSL, OpenVPN, L2TP/IPsec e SSTP in un elenco di nodi pubblici descrivono la configurazione di quel nodo in quel momento. Lo stesso software altrove può presentare un insieme diverso, e un provider può ritirare un ascoltatore tra il tuo segnalibro e il tuo tentativo successivo. Le note vecchie descrivono deployment vecchi.

Annota il profilo verificato con il suo endpoint e il suo metodo, poi ripeti la sonda quando il nodo cambia o la connessione inizia a fallire. La specifica del protocollo SoftEther è il riferimento per ciò che il software può fare; l’elenco del nodo stesso è il riferimento per ciò che fa. Tieni separati i due documenti e la diagnosi diventa più breve.