Errore di RAND_bytes su OpenVPN: errore della libreria o nodo mancante

RAND_bytes() failed è un’affermazione su una primitiva locale, non sull’account, sulla chiave precondivisa o sulla porta remota. Due guasti molto diversi producono quella stessa riga e lasciano prove diverse. Uno è un backend crittografico che rifiuta di emettere byte; l’altro è un processo che non raggiunge la sorgente di entropia per cui il suo codice è stato compilato. Distinguerli richiede una lettura della coda degli errori e uno sguardo alla vista del file system del processo in jail, e quel controllo va fatto prima di creare qualsiasi cosa sotto /dev.

Che cosa distingue il valore di ritorno

Il contratto documentato separa tre esiti, non due: 1 per il successo, -1 quando il metodo RAND caricato non supporta la richiesta e 0 per gli altri guasti, con la spiegazione lasciata alla coda degli errori. Il riferimento di RAND_bytes aggiunge un punto facile da trascurare: il generatore predefinito si inizializza dal sistema operativo sulle piattaforme supportate e, quando quell’inizializzazione fallisce, resta in uno stato di errore invece di restituire byte prevedibili.

Solo uno di quei numeri descrive l’ambiente. Un -1 è una questione di build, di provider o di funzionalità, perché il codice ha chiesto qualcosa che l’implementazione attiva non offre. Uno 0 con una lamentela sull’inizializzazione è una questione di ambiente, perché il generatore non è riuscito a ottenere entropia in alcun modo. Il numero da solo non dice mai quale dei due, e nemmeno il nome della funzione.

Quando un nodo di dispositivo nascosto è la vera causa

Un servizio confinato vede un albero diverso da quello della shell in cui stai digitando. Le jail chroot, le immagini dei container e le unit file indurite presentano di norma un /dev che contiene meno nodi di quello dell’host. Se l’implementazione che fallisce apre /dev/urandom tramite il percorso, quella differenza basta a rompere l’avvio mentre l’host sembra perfettamente sano. Un dispositivo che esiste fuori dalla jail non dimostra nulla su ciò che il processo in jail può aprire.

Non ogni interfaccia casuale ha bisogno di un percorso, però. La chiamata di sistema getrandom di Linux non accetta alcun nome di file né descrittore di file, e la sua pagina di manuale osserva che questa proprietà è utile proprio dove un chroot nasconde i percorsi dei dispositivi.

Quindi la spiegazione del nodo mancante è un’ipotesi su un ramo del codice, non una regola sui numeri casuali in generale. Vale quando le prove nominano un percorso, ed è congettura quando le prove nominano qualcos’altro.

Leggi la coda degli errori, poi la vista del processo

Il modo più rapido per risolvere la questione è leggere ciò che la libreria ha già registrato, poi guardare direttamente la vista in jail. Inizia da la build di OpenSSL che il servizio ha effettivamente caricato, perché gli stack dei provider differiscono tra versioni maggiori e tra distribuzioni. Chiedi poi a systemd quale processo è in esecuzione e quali restrizioni gli si applicano. Solo dopo che entrambi i fatti sono sul tavolo vale la pena elencare i nodi che quel processo può vedere.

openssl version -a
systemctl show openvpn-server@lab -p MainPID -p PrivateDevices -p DevicePolicy
pid=$(systemctl show -p MainPID --value openvpn-server@lab)
sudo ls -l /proc/"$pid"/root/dev/urandom /proc/"$pid"/root/dev/random

Esegui quelle letture sullo stesso processo, non sulla shell che capita di avere aperta. Confrontare il /dev dell’host con la vista di un processo estraneo è il modo in cui la dipendenza sbagliata viene riparata due volte.

Aggiungi la dipendenza solo dopo averla saputa nominare

Quando le prove nominano davvero un percorso, la riparazione è piccola: rendi disponibile quel solo percorso dentro la jail e lascia stare tutto il resto. Un bind mount del singolo nodo di solito basta, e mknod con i numeri major e minor standard del nodo produce lo stesso risultato nelle installazioni in cui il montaggio non è un’opzione. Allargare la sandbox, concedere l’accesso a ogni dispositivo a caratteri o disattivare PrivateDevices scambia una correzione mirata con una regressione di sicurezza permanente.

Un demone dell’entropia non sostituisce quella riparazione. Pacchetti come haveged cambiano il modo in cui viene alimentato il pool del kernel; non possono creare un percorso che un processo in jail sia autorizzato ad aprire. Installarne uno può far sembrare migliore un grafico di salute mentre la chiamata open continua a fallire. Tieni separati i due problemi, altrimenti il prossimo guasto verrà di nuovo attribuito allo strato sbagliato.

Verifica separatamente il generatore e il tunnel

Un riavvio è l’unico test che riutilizza la stessa configurazione, la stessa unit file e lo stesso confinamento che hanno prodotto il guasto. Eseguilo, poi leggi le voci più recenti del journal invece di un campione di un avvio precedente.

sudo systemctl restart openvpn-server@lab
sudo journalctl -u openvpn-server@lab --since -5min --no-pager | grep -iE 'rand|entropy|Initialization Sequence'

Cerca due cose distinte in quell’output: il messaggio sulla sorgente casuale che scompare e il tunnel che raggiunge la sua solita tappa di avvio. Un generatore che torna a funzionare elimina un guasto locale e non dice nulla sull’identità del server, sulle credenziali o sul routing. Prova questo con la stessa configurazione client che falliva prima, così il risultato è confrontabile e non solo migliore.