P_CONTROL_HARD_RESET_CLIENT_V2 nel log: è un errore?

La riga si ripete ogni pochi secondi e sembra la causa di tutto: un pacchetto chiamato control hard reset, che arriva da un client che non approda da nessuna parte. Non è un errore. È il primo messaggio di una nuova sessione, e la ripetizione è il sintomo di qualcos'altro che fallisce più avanti. Separare ciò che dice l'etichetta da ciò che ha fatto la connessione dopo è tutta la diagnosi.

L'opcode indica una posizione nel protocollo

OpenVPN multiplessa diversi tipi di pacchetto su un solo socket, e l'opcode dice al ricevente quale tipo sta tenendo. I pacchetti hard-reset aprono una sessione, i pacchetti di controllo portano il materiale dell'handshake, gli acknowledgement confermano la ricezione e i pacchetti dati portano il carico del tunnel. Leggere il primo byte dice dove si colloca il pacchetto in quello scambio, e le definizioni dei pacchetti nel codice sorgente nominano ogni famiglia esplicitamente.

Questo è tutto ciò che dice. Un pacchetto etichettato come reset iniziale del client prova che il pacchetto ha raggiunto il tuo punto di osservazione e che il peer vuole aprire una sessione. Non prova che il client si sia fidato del tuo certificato, che le sue credenziali siano state accettate o che un canale dati sia mai diventato utilizzabile.

Il suffisso V2 è un marcatore di generazione del protocollo per quella famiglia di pacchetti, non una versione di prodotto e non un'impostazione che installi. Nulla nel nome rimanda al ripristino di un tunnel, al riavvio di un servizio o alla pulizia di una cache.

Che cosa fa davvero il client in quel momento

Il client apre un identificatore di sessione a cui entrambe le estremità collegheranno il traffico di controllo successivo. Con la protezione del canale di controllo configurata, quel primo pacchetto porta già l'HMAC che consente al ricevente di decidere se vale la pena dedicare sforzo al resto dello scambio. Un ricevente che non riesce a verificarlo scarta il pacchetto in silenzio, ed è per questo che una chiave condivisa sbagliata sembra un client che parla nel vuoto.

Non è ancora successo nulla di visibile all'utente. Nessun certificato è stato convalidato, nessun nome utente è stato offerto e nessun indirizzo del tunnel è stato assegnato. Il reset è il preambolo dell'handshake, quindi qualsiasi giudizio sulla connessione a questo punto è prematuro.

Per un ciclo di riconnessione inattivo, il dettaglio interessante è l'intervallo. Un client che riprova a ciclo fisso senza avanzare viene di solito rifiutato prima di poter progredire, e la ragione è nel log del peer, non nel nome del pacchetto.

Dove si nasconde il guasto reale dopo il reset

Leggi i due log fianco a fianco e trova il primo evento che non è un reset. Sul client, un errore di convalida del certificato viene segnalato con il motivo specifico: un certificato scaduto, una mancata corrispondenza del nome o un emittente sconosciuto. Sul server, un rifiuto delle credenziali viene segnalato come errore di autenticazione con il proprio motivo. Entrambi sono molto più specifici della visione ripetuta del server sui nuovi tentativi.

Abbina un tentativo per marca temporale invece di leggere ogni log isolatamente, perché lo stesso guasto appare in entrambi i posti con parole e gravità diverse. Il peer che si arrende di solito dice perché.

Se nessuno dei due lati segnala un rifiuto e lo scambio resta bloccato, il limite è la raggiungibilità e non la fiducia. Un firewall che scarta la direzione di ritorno, un dispositivo di traduzione degli indirizzi di rete che fa scadere la mappatura o un problema di MTU che uccide i pacchetti di handshake più grandi producono tutti uno scambio bloccato senza alcun errore di autenticazione.

grep -nE 'VERIFY|AUTH_FAILED|TLS Error|SIGUSR1' /var/log/openvpn*.log

Quella ricerca non è una diagnosi da sola, ma ti porta dal vocabolario del protocollo a una classe di guasto reale in un solo passo.

Perché disattivare la verifica è il riflesso sbagliato

Quando il reset continua a comparire, la correzione che sembra più rapida è disattivare la convalida dei certificati o rinunciare alla protezione del canale di controllo perché qualcosa si connetta. Questo scambia un guasto diagnosticabile con uno non diagnosticabile, e lascia la distribuzione ad accettare peer che era stata costruita per rifiutare.

Cambia invece il limite che ha davvero fallito. Un problema di fiducia appartiene all'autorità di certificazione e al profilo che la referenzia. Un problema di orario appartiene all'orologio. Un problema di credenziali appartiene al backend di autenticazione che le ha rifiutate, e un peer irraggiungibile appartiene al percorso tra i due host.

L'opcode è utile in una conversazione di supporto per una cosa: ti dice che il peer è arrivato abbastanza lontano da provarci. Quello che è successo dopo è ciò che devi sapere, ed è scritto nel log che registra il primo rifiuto concreto. Parti da lì, e la riga di reset smette di sembrare una causa e comincia a sembrare una marca temporale.