És un problema d'entropia el baix rendiment de la VPN? Normalment no

Un rendiment lent a través d'un túnel i una màquina encallada esperant números aleatoris produeixen experiències molt diferents, però s'arxiven sota la mateixa queixa. Un es manifesta com una pausa abans que res funcioni. L'altre es manifesta com una connexió que funciona i mou dades lentament mentre la mireu. Decidir quin teniu costa deu minuts i estalvia una setmana d'especulacions.

Dos símptomes que semblen iguals

Un servei que es penja després d'una arrencada nova, abans d'acceptar una sola connexió, espera alguna cosa. Un túnel que s'estableix ràpidament i després transfereix a una fracció del ritme esperat està limitat per una altra cosa. La paraula xifratge apareix en les dues històries, i per això es fusionen. Separeu-los abans de tocar un fitxer de configuració.

Poseu marques de temps al voltant de l'inici, l'autenticació, la renegociació de claus i la transferència mateixa. Un retard llarg abans que el túnel sigui utilitzable no és un ritme baix constant, i fer la mitjana dels dos en un sol número destrueix l'evidència.

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

Les dues primeres ordres posen la feina d'inici en una línia temporal. La tercera imprimeix el valor comptable d'entropia del nucli, que és útil com a punt de dades únic i inútil com a mesurador d'amplada de banda.

Com es veu realment una espera de números aleatoris

Una petició de bytes aleatoris segurs pot bloquejar-se fins que el nucli hagi inicialitzat la seva font aleatòria. Això importa sobretot en màquines virtuals i plaques incrustades petites al principi de l'arrencada, quan s'ha recollit poc soroll ambiental. No se segueix que cada byte xifrat consumeixi entropia nova.

Els generadors moderns se sembren una vegada i després produeixen sortida d'una construcció determinista, tornant-se a sembrar al seu propi ritme. La transferència massiva no buida un dipòsit byte a byte, així que un valor baix del dipòsit durant una transferència lenta no demostra res sobre la causa.

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

La primera ordre mostra si el procés està assegut en una crida de números aleatoris mentre mireu. La segona mostra els missatges d'inicialització del propi nucli, i és allà on una aturada d'inici primerenc es fa visible.

Anoteu la versió del nucli i la biblioteca a què el servei enllaça realment, perquè el comportament difereix entre implementacions i entre versions. Un rastre pres després de la recuperació normalment omet la pausa del tot.

Com es veu realment una lentitud sostinguda

Un túnel que transfereix lentament durant tota l'estona està limitat pel camí de dades. Un fil saturat, pèrdua de paquets exteriors, retransmissions o cues de sòcol plenes produeixen cadascun aquest patró, i cadascun té la seva solució. El percentatge agregat de CPU amaga un sol fil ocupat, que és la mala lectura més habitual. Mireu el temps per fil abans de mirar la càrrega total.

Mesureu en les dues direccions amb una base comparable, i vigileu els comptadors de la interfície en lloc de l'informe de la pròpia aplicació.

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

La primera ordre mostra l'estat de cua i congestió per a un parell. La segona i la tercera informen de descarts i retransmissions a la pila i a la interfície, que és on la causa sol aparèixer primer.

Trieu la correcció per al coll d'ampolla que heu mesurat

Si l'evidència apunta a la inicialització d'inici primerenc, mireu el camí de sembra admès per la plataforma, que en una màquina virtual pot incloure un dispositiu aleatori proporcionat per l'amfitrió. Una imatge de llavor copiada sense canvis a molts convidats no substitueix una inicialització independent.

Si l'evidència apunta al camí de dades, ajusteu el que assenyalen els comptadors. Les mides de búfer ajuden quan les cues desborden i no fan res quan un fil està saturat. Instal·lar un dimoni d'entropia per pujar un comptador no és una reparació de rendiment, i canviar les suposicions de sembra per fer que un gràfic sembli millor intercanvia una propietat de seguretat per un número.

Accepteu el canvi només quan la mateixa mesura millora en les mateixes condicions. Un comptador més gran no és un resultat; una espera mesurada més curta o una transferència més ràpida amb una causa identificada sí que ho és.