OpenVPN: stretta di mano TLS non riuscita, su quale ramo sei?
Un timeout, un certificato rifiutato e un canale di controllo non corrispondente richiedono correzioni diverse. Leggi gli eventi prima della disconnessione per scegliere il ramo giusto.
La riga che dice che la stretta di mano TLS non è riuscita è la fine di una storia, non l'inizio. Conta l'evento immediatamente precedente, perché quell'evento nomina quale dei quattro guasti molto diversi hai. Un timeout, una discrepanza del canale di controllo, un certificato rifiutato e un guasto dopo la negoziazione producono tutti lo stesso titolo. Scegli il ramo in base alle prove e la correzione smette di essere un'ipotesi.
Leggi l'ultimo evento prima del guasto
Scorri verso l'alto invece di leggere l'ultima riga. L'evento prima della disconnessione di solito nomina la fase: nessuna risposta, un errore durante lo scambio dei pacchetti di controllo, un esito di verifica o una negoziazione riuscita seguita da un esito di autenticazione. Ognuno di essi appartiene a un responsabile diverso. Quella singola riga decide quale sezione qui sotto si applica.
Salva il testo dell'errore con la versione del client, l'endpoint e il trasporto. Tieni chiavi, password e profili non oscurati fuori da tutto ciò che pubblichi.
Un primo errore preciso vale più di un lungo estratto di log. Nomina la fase, e la fase nomina il responsabile.
Ramo uno: non è tornato nulla
Se il client ha inviato il suo primo pacchetto e non ha ricevuto nulla di utilizzabile, il problema è sul percorso o presso l'ascoltatore. Verifica che il profilo corrisponda a un'opzione che l'operatore offre davvero: indirizzo, porta e UDP o TCP. Poi controlla se l'endpoint è raggiungibile da questa rete. Annota quale dei due controlli ha fallito prima di andare avanti.
Un browser che carica una pagina sullo stesso nome host dimostra solo che un servizio web ha risposto. Nemmeno una connessione TCP accettata dice qualcosa sul fatto che OpenVPN abbia completato la negoziazione.
Se il profilo funziona su un'altra rete affidabile, conserva questo confronto. Localizza la restrizione su un percorso o su un intermediario.
Ramo due: il canale di controllo non corrisponde
Quando lo scambio inizia e poi si blocca, le impostazioni del canale di controllo sono il primo sospetto. tls-auth e tls-crypt devono corrispondere alla distribuzione, e il materiale di un altro server non produrrà uno scambio utile. Questo guasto avviene prima di qualsiasi accesso all'account. Un profilo copiato da un server più vecchio è la fonte abituale.
Reimpostare la password non sostituisce queste impostazioni, e prendere in prestito una chiave da un altro servizio non è una correzione di compatibilità. Ottieni il profilo tramite il canale verificato dell'operatore e annota la versione del client che si aspetta.
Registra l'errore di negoziazione specifico invece di attivare una pila di algoritmi più vecchi per vedere cosa regge. È un testo di errore catturato che permette all'operatore di controllare il suo lato.
Ramo tre: un certificato è stato rifiutato
Un guasto esplicito di verifica nomina il certificato che non gradisce. Controlla prima l'orologio del dispositivo, poi leggi quale oggetto ha fallito: il certificato del server, quello del client o un emittente della catena. Scadenza, un emittente non affidabile e un'identità inattesa sono tre messaggi diversi.
Mantieni attiva la verifica mentre ottieni il materiale corretto. Accettare un certificato non correlato elimina l'errore senza dimostrare di aver raggiunto il server previsto.
Annota se il guasto segue la rete o il profilo. Un errore di certificato che compare ovunque non è un problema di percorso.
Ramo quattro: la negoziazione è finita e qualcos'altro è fallito
Una volta riuscito lo scambio di identità, il guasto rimanente appartiene all'autenticazione o all'instradamento. Un rifiuto esplicito dell'account è una questione di autenticazione, e un tunnel connesso con siti irraggiungibili è una questione di instradamento o DNS. Continuare a sostituire opzioni TLS a quel punto danneggia una fase che già funzionava.
Quando segnali il problema, dì se falliscono tutte le reti, se un altro profilo funziona e se il server ha registrato il tentativo. Il silenzio lato server e un rifiuto da parte sua stanno su confini diversi.