tls-auth key-direction: 0 e 1 devono differire, non coincidere
Con tls-auth le due estremità hanno bisogno di direzioni opposte, 0 e 1, oppure entrambe devono omettere l'impostazione. Lo stesso numero fallisce, e tls-crypt non lo usa mai.
Un lato del tunnel firma il canale di controllo con uno slot di chiave che l'altro lato non controlla mai, e la connessione muore con un errore di autenticazione prima che venga scambiato un solo certificato. Ecco com'è un disallineamento di direzione con tls-auth, ed è deterministico: gli stessi due file falliscono a ogni tentativo, da qualsiasi rete. Nulla nel registro nomina l'opzione che stai cercando, per questo le persone ricostruiscono chiavi e reimmettano certificati che non erano mai stati rotti. La soluzione è rendere le due estremità complementari, o lasciarle entrambe bidirezionali, invece di indebolire la verifica.
Il guasto arriva prima dei certificati
Con tls-auth, entrambi i peer detengono la stessa chiave condivisa e ciascuno usa uno dei due slot che ne derivano: uno slot firma i pacchetti di controllo in uscita, l'altro verifica quelli in entrata. La direzione 0 e la direzione 1 assegnano questi ruoli in ordine opposto, quindi la coppia deve essere complementare perché i controlli HMAC coincidano. Quando l'assegnazione viene invertita su un lato, il ricevitore cerca una firma nello slot sbagliato e rifiuta il pacchetto. La sessione finisce lì, per questo l'errore riguarda l'autenticazione dei pacchetti e non qualcosa che produrrebbe l'archivio dei certificati.
Il determinismo conta per la diagnosi, perché un problema di tempo o di percorso lascia un'impronta diversa: interruzioni intermittenti, una direzione che fallisce o una sessione che muore solo su una rete particolare. Un disallineamento di direzione fallisce alla prima stretta di mano ogni volta, e fallisce allo stesso modo su un'altra macchina con gli stessi due file. Leggi il registro con --verb 4 e trova il primo pacchetto rifiutato invece dell'ultima riga. Se quel rifiuto avviene prima di qualsiasi scambio di certificati, la chiave condivisa e la sua direzione sono le due cose che vale la pena controllare.
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
Dove vive il numero
Il manuale di OpenVPN 2.6 documenta due punti per la direzione: il secondo argomento di tls-auth quando la chiave è in un file separato, e una riga key-direction autonoma quando la chiave è incorporata nel profilo. Entrambi impostano lo stesso valore, quindi un profilo deve usare una forma o l'altra, mai entrambe. Anche l'omissione è una scelta, e mette entrambi i peer in una disposizione bidirezionale che funziona quando nessun lato nomina una direzione. Due peer con lo stesso numero non sono in quella disposizione: ciascuno si aspetta di firmare in uno slot e verificare nell'altro, ed entrambi lo fanno allo stesso modo.
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
La forma incorporata è una direttiva su una riga propria, non un attributo sul tag di apertura del blocco della chiave, e aggiungere un argomento a quel tag è un errore, non un cambio di direzione. Anche la posizione conta: la direttiva sta fuori dal blocco a cui appartiene, quindi un valore scritto dentro il blocco viene letto come materiale della chiave. Copia la disposizione prevista dal distributore del profilo invece di inventare una coppia, perché un profilo che funziona contro un server è forse già specchiato dall'altro lato.
Cosa lascia intatto l'opzione
Non cifra il traffico delle applicazioni. tls-auth mette un HMAC attorno ai pacchetti del canale di controllo, mentre il canale dati è protetto da chiavi di sessione negoziate durante la stretta di mano, quindi una domanda su prestazioni o cifratura non ha nulla a che vedere con il numero di direzione. L'impostazione non aggiunge nemmeno un secondo strato di cifratura, ed è questa supposizione che manda la gente a cercare una chiave più lunga.
Non si applica a tls-crypt, un altro meccanismo di canale di controllo con opzioni e gestione delle chiavi proprie, e non dice nulla sull'identità del certificato di nessun peer. Quindi una corrispondenza di direzione funzionante dimostra solo che le due estremità concordano su come autenticare il canale di controllo, non che la catena di fiducia sia stata validata.
Allinea la coppia, poi riconnetti
Confronta le due configurazioni prima di cambiarne una, perché modificare il lato già corretto raddoppia il lavoro. Il grep qui sotto mostra quale meccanismo sceglie ogni file; l'esecuzione dettagliata mostra se il canale di controllo si è autenticato. Conserva entrambi gli output, così il prossimo cambiamento potrà essere confrontato con uno stato noto.
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
Riavvia entrambi i peer dopo ogni modifica, perché queste opzioni vengono lette una volta all'avvio e ricaricare un lato lascia la coppia incoerente per tutta la vita della vecchia sessione. Se il deployment funziona ora senza direzione configurata, aggiungere l'impostazione su un peer riproduce il guasto con cui hai iniziato; o lascia stare entrambi o configurali entrambi. Cambia un'estremità alla volta e conserva il file precedente, così una regressione è un ripristino di due minuti e non una ricostruzione.
Annota il meccanismo, il file della chiave e la direzione di ogni estremità nelle note di deployment, perché altrimenti la persona successiva leggerà due file simili e presumerà che i numeri debbano concordare tra loro. La direzione è un dettaglio di coordinamento, non un potenziamento di sicurezza: separa le due direzioni del canale di controllo e non fa altro.