Un throughput VPN basso è un problema di entropia? Di solito no

Un throughput lento attraverso un tunnel e una macchina bloccata in attesa di numeri casuali producono esperienze molto diverse, ma vengono archiviati sotto lo stesso reclamo. Uno si manifesta come una pausa prima che qualsiasi cosa funzioni. L'altro si manifesta come una connessione che funziona e sposta i dati lentamente finché la osservate. Stabilire quale avete richiede dieci minuti e fa risparmiare una settimana di congetture.

Due sintomi che sembrano uguali

Un servizio che si blocca dopo un avvio fresco, prima di accettare una sola connessione, sta aspettando qualcosa. Un tunnel che si stabilisce rapidamente e poi trasferisce a una frazione della velocità attesa è limitato da qualcos'altro. La parola cifratura compare in entrambe le storie, ed è per questo che vengono unite. Separateli prima di toccare un file di configurazione.

Mettete timestamp intorno all'avvio, all'autenticazione, alla rinegoziazione delle chiavi e al trasferimento stesso. Un lungo ritardo prima che il tunnel sia utilizzabile non è una velocità bassa e costante, e fare la media dei due in un solo numero distrugge la prova.

systemd-analyze blame | head -10
journalctl -u [email protected] -o short-precise | head -40
cat /proc/sys/kernel/random/entropy_avail

I primi due comandi collocano il lavoro di avvio su una linea temporale. Il terzo stampa il valore contabile dell'entropia del kernel, utile come singolo punto dati e inutile come misuratore di larghezza di banda.

Che aspetto ha davvero un'attesa di numeri casuali

Una richiesta di byte casuali sicuri può bloccarsi finché il kernel non ha inizializzato la sua sorgente casuale. Questo conta soprattutto sulle macchine virtuali e sulle piccole schede embedded all'inizio dell'avvio, quando è stato raccolto poco rumore ambientale. Non ne segue che ogni byte cifrato consumi entropia fresca.

I generatori moderni vengono seminati una volta e poi producono output da una costruzione deterministica, riseminandosi secondo il proprio calendario. Il trasferimento in blocco non svuota un pool byte per byte, quindi un valore basso del pool durante un trasferimento lento non dimostra nulla sulla causa.

strace -f -e trace=getrandom -p $(pidof openvpn) 2>&1 | head -20
dmesg | grep -i 'random\|crng'

Il primo comando mostra se il processo è fermo in una chiamata di numeri casuali mentre osservate. Il secondo mostra i messaggi di inizializzazione del kernel stesso, ed è lì che un blocco all'avvio precoce diventa visibile.

Annotate la versione del kernel e la libreria a cui il servizio è realmente collegato, perché il comportamento varia tra implementazioni e tra release. Una traccia presa dopo il ripristino di solito manca del tutto la pausa.

Che aspetto ha davvero una lentezza persistente

Un tunnel che trasferisce lentamente per tutto il tempo è limitato dal percorso dei dati. Un singolo thread saturo, la perdita di pacchetti esterni, le ritrasmissioni o le code di socket piene producono ciascuno quel modello, e ciascuno ha la sua correzione. La percentuale CPU aggregata nasconde un singolo thread occupato, ed è la lettura errata più comune. Guardate il tempo per thread prima di guardare il carico totale.

Misurate in entrambe le direzioni con una base comparabile, e osservate i contatori dell'interfaccia invece del rapporto dell'applicazione stessa.

ss -tin dst 203.0.113.10
nstat -az | grep -i 'drop\|retrans'
ethtool -S eth0 | grep -i 'drop\|error'

Il primo comando mostra lo stato di coda e congestione per un peer. Il secondo e il terzo riportano scarti e ritrasmissioni nello stack e nell'interfaccia, dove la causa di solito appare per prima.

Scegliete la correzione per il collo di bottiglia che avete misurato

Se le prove indicano l'inizializzazione all'avvio precoce, guardate il percorso di seeding supportato dalla piattaforma, che su una macchina virtuale può includere un dispositivo casuale fornito dall'host. Un'immagine di seed copiata invariata in molti ospiti non sostituisce un'inizializzazione indipendente.

Se le prove indicano il percorso dei dati, regolate ciò che i contatori indicano. Le dimensioni dei buffer aiutano quando le code traboccano e non fanno nulla quando un thread è saturo. Installare un demone dell'entropia per alzare un contatore non è una riparazione del throughput, e cambiare le assunzioni di seeding per far apparire migliore un grafico scambia una proprietà di sicurezza con un numero.

Accettate il cambiamento solo quando la stessa misura migliora nelle stesse condizioni. Un contatore più grande non è un risultato; un'attesa misurata più breve o un trasferimento più veloce con una causa identificata lo è.