Debitul VPN scăzut este o problemă de entropie? De obicei nu

Un debit redus printr-un tunel și o mașină blocată așteptând numere aleatoare produc experiențe foarte diferite, dar sunt înregistrate sub aceeași reclamație. Unul apare ca o pauză înainte ca ceva să funcționeze. Celălalt apare ca o conexiune care funcționează și mută datele încet atât timp cât o urmăriți. A stabili pe care îl aveți durează zece minute și economisește o săptămână de presupuneri.

Două simptome care arată la fel

Un serviciu care se blochează după o pornire nouă, înainte de a accepta o singură conexiune, așteaptă ceva. Un tunel care se stabilește repede și apoi transferă la o fracțiune din rata așteptată este limitat de altceva. Cuvântul criptare apare în ambele povestiri, de aceea sunt fuzionate. Separați-le înainte de a atinge un fișier de configurare.

Puneți marcaje de timp în jurul pornirii, autentificării, renegocierii cheilor și transferului în sine. O întârziere lungă înainte ca tunelul să fie utilizabil nu este o rată mică și constantă, iar media celor două într-un singur număr distruge dovada.

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

Primele două comenzi așază munca de pornire pe o linie de timp. A treia afișează valoarea contabilă a entropiei nucleului, utilă ca un singur punct de date și inutilă ca instrument de măsurare a lățimii de bandă.

Cum arată de fapt o așteptare pentru numere aleatoare

O cerere de octeți aleatori siguri se poate bloca până când nucleul își inițializează sursa aleatoare. Acest lucru contează cel mai mult pe mașinile virtuale și pe plăcile încorporate mici la începutul pornirii, când s-a adunat puțin zgomot ambiental. De aici nu rezultă că fiecare octet criptat consumă entropie proaspătă.

Generatoarele moderne se inițializează o dată și apoi produc ieșire dintr-o construcție deterministă, reinițializându-se după propriul program. Transferul în bloc nu golește un bazin octet cu octet, așa că o valoare scăzută a bazinului în timpul unui transfer lent nu dovedește nimic despre cauză.

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

Prima comandă arată dacă procesul stă într-un apel de numere aleatoare în timp ce urmăriți. A doua arată mesajele de inițializare ale nucleului însuși, și acolo devine vizibilă o blocare la pornirea timpurie.

Notați versiunea nucleului și biblioteca de care serviciul se leagă efectiv, deoarece comportamentul diferă între implementări și între versiuni. O urmă luată după recuperare ratează de obicei pauza complet.

Cum arată de fapt o încetineală susținută

Un tunel care transferă încet tot timpul este limitat de calea datelor. Un singur fir saturat, pierderea pachetelor externe, retransmisiile sau cozile de socket pline produc fiecare acel model, și fiecare are propria corecție. Procentul agregat de CPU ascunde un singur fir ocupat, iar aceasta este cea mai frecventă citire greșită. Uitați-vă la timpul pe fir înainte de a vă uita la încărcarea totală.

Măsurați în ambele direcții cu o bază comparabilă și urmăriți contoarele interfeței în locul raportului aplicației în sine.

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

Prima comandă arată starea cozii și a congestiei pentru un peer. A doua și a treia raportează pierderi și retransmisii la nivel de stivă și de interfață, unde cauza apare de obicei prima.

Alegeți corecția pentru blocajul pe care l-ați măsurat

Dacă dovezile indică inițializarea la pornirea timpurie, uitați-vă la calea de inițializare acceptată de platformă, care pe o mașină virtuală poate include un dispozitiv aleator furnizat de gazdă. O imagine de sămânță copiată neschimbat în mulți oaspeți nu înlocuiește o inițializare independentă.

Dacă dovezile indică calea datelor, reglați ceea ce indică contoarele. Dimensiunile bufferelor ajută când cozile se revarsă și nu fac nimic când un fir este saturat. Instalarea unui demon de entropie pentru a ridica un contor nu este o reparație a debitului, iar schimbarea presupunerilor de inițializare pentru ca un grafic să arate mai bine schimbă o proprietate de securitate pe un număr.

Acceptați schimbarea doar când aceeași măsurătoare se îmbunătățește în aceleași condiții. Un contor mai mare nu este un rezultat; o așteptare măsurată mai scurtă sau un transfer mai rapid cu o cauză identificată este.