Connessione rifiutata non è un problema di certificato: guida VPN

Il client dice connessione rifiutata subito dopo aver rigenerato la CRL, quindi la CRL sembra colpevole. Non lo è. Il rifiuto è una risposta del livello trasporto, e la validazione del certificato avviene più tardi, dentro l’handshake del tunnel. Il tempismo è contesto, non prova.

Due controlli separano i casi in meno di un minuto, e nessuno dei due tocca le impostazioni di fiducia.

Leggi l’errore al livello che lo ha prodotto

Un ECONNREFUSED da connect significa che il tentativo di trasporto è stato rifiutato: qualcosa ha risposto con un reset, oppure lo stack ha segnalato una porta irraggiungibile. Un problema di certificato non può produrre quell’errore, perché l’handshake TLS non inizia mai senza una connessione di trasporto. Se vedi un rifiuto, il client non è mai arrivato abbastanza avanti da presentare un certificato. Questo singolo fatto esclude la revoca come causa.

Vale anche il contrario. Un certificato revocato produce una connessione TCP completata e un handshake fallito, registrato sul server come errore di verifica.

Rifiuto TCP: nessuno è in ascolto

Per TCP, controlla se l’istanza prevista è in esecuzione e associata all’indirizzo e alla porta del profilo. ss -lntp mostra gli ascoltatori, e la loro assenza è la spiegazione abituale. Un firewall che rifiuta invece di scartare produce lo stesso messaggio sul lato client, per questo controlli entrambi.

Controlla anche la famiglia di indirizzi. Un servizio associato a 127.0.0.1 o solo a IPv6 rifiuterà un client che risolve verso l’altra.

Poi leggi il log del servizio invece di indovinare. Un riavvio dopo la manutenzione della CA può fallire su un file illeggibile o mancante e non raggiungere mai lo stato di ascolto, e il log nomina il file. È un errore di avvio, un bug diverso da un certificato rifiutato.

UDP non ha un handshake da rifiutare

OpenVPN su UDP non stabilisce una connessione nel senso di TCP, quindi non c’è nulla da rifiutare al momento del connect. Su Linux, un errore mostrato da un socket UDP può provenire da un ICMP port-unreachable generato da un datagramma precedente. La pagina di manuale udp(7) descrive questo comportamento asincrono.

Per questo un client UDP può stampare un rifiuto mentre il processo server è in esecuzione ma non è associato all’indirizzo atteso.

Dove viene realmente controllata una CRL

La CRL viene consultata durante l’handshake TLS, dopo che la controparte ha presentato il proprio certificato, e solo se la configurazione del server lo consente. L’opzione crl-verify di OpenVPN punta al file, e un errore appare nel log del server come errore di verifica che nomina il certificato.

Un client revocato quindi si connette a livello trasporto e poi fallisce l’autenticazione. Stesso server, stessa porta, messaggio completamente diverso.

Controlla l’emittente e le date di validità della CRL quando arrivi a quella fase. Una CRL firmata dalla CA sbagliata, o una scaduta prima che il client si connettesse, produce errori di verifica che non hanno nulla a che vedere con il certificato del client stesso.

Una guida breve per la prossima volta

Conferma prima il trasporto: ascoltatore presente, famiglia di indirizzi corretta, firewall che non rifiuta. Poi conferma che il servizio ha raggiunto lo stato di ascolto leggendo il log di avvio. E solo allora guarda gli errori di handshake in cerca di messaggi di verifica. Mantieni fisso quest’ordine, perché ogni passo elimina un’intera classe di cause.

Annota il trasporto, la destinazione risolta, la porta e il testo esatto dell’errore. Reinstallare il client distrugge quella prova e di solito non cambia nulla.