Rămâne un VPN fără entropie? Ce arată de fapt entropy_avail
O blocare la pornire și un tunel stabilit lent sunt două defecte diferite. Citiți etapa, sensul real al contorului și coada înainte de a da vina pe aleatorism.
Epuizarea aleatorismului nucleului este o explicație atractivă pentru un VPN lent și aproape întotdeauna cea greșită pentru simptomul pe care îl raportează oamenii. Un host care așteaptă ieșire aleatorie se blochează la un anumit moment, de obicei devreme în pornire sau în timpul manipulării cheilor. Un tunel care se conectează repede și apoi transferă lent descrie de fapt debitul. Separați aceste două observații înainte de a instala un demon pentru a repara un număr pe care nu ați terminat de citit.
De ce mitul supraviețuiește
Ambele probleme sunt reale și de departe arată la fel. Blocările de pornire pe o mașină virtuală proaspăt pornită chiar se întâmplă, iar un tunel stabilit lent este la fel de real. Greșeala este să presupui că al doilea este cauzat de primul pentru că criptografia apare undeva în ambele povești. Nimic din cuvântul criptare nu implică faptul că fiecare byte transferat consumă un byte proaspăt de zgomot ambiental.
Generatoarele nu funcționează așa. O bibliotecă criptografică păstrează un generator cu sămânță și extrage ieșire din el, reînsămânțând după propria politică, așa că momentul scump este însămânțarea, nu transferul constant.
Ce face un generator pentru fiecare pachet
În OpenSSL 3 ierarhia implicită de generatoare este construită din instanțe DRBG care însămânțează și reînsămânțează în funcție de configurație și stare. În OpenVPN 2.6 calea de date AEAD își derivă nonce-ul din numărul de secvență al pachetului combinat cu o valoare implicită pe sesiune, în timp ce calea CBC mai veche extrage un IV pseudoaleator pentru fiecare pachet. Niciunul dintre modele nu susține regula că mutarea unui gigabyte consumă un gigabyte de zgomot proaspăt al nucleului. Ambele susțin ideea că generarea cheilor și strângerile de mână sunt locul unde însămânțarea contează.
Cazul CBC merită numit pentru că pare mitul și nu este: IV-ul său pe pachet vine de la generatorul bibliotecii conform programului propriu de reînsămânțare al bibliotecii, niciodată dintr-un apel la nucleu pentru fiecare pachet. Când cineva citează un cost de entropie pe byte, întrebați ce versiune de bibliotecă și ce cale de cod au măsurat.
Unde se vede de fapt așteptarea
Puneți ștampile de timp în jurul etapelor, nu al sesiunii: pornire, autentificare, schimbarea cheii și transfer. O așteptare înainte ca tunelul să devină utilizabil este o altă plângere decât un debit constant mic, și doar una dintre ele indică aleatorismul. În Linux o cerere getrandom() normală se poate bloca până când sursa aleatorie a nucleului este inițializată, motiv pentru care versiunea de la pornire a acestei probleme este reală pe mașini virtuale și plăci încorporate care au puțin cu ce hrăni bazinul la început.
| Etapă | Ce trebuie executat | Citire care înseamnă așteptare | Citire care înseamnă debit |
|---|---|---|---|
| Pornire, înainte de orice tunel | systemd-analyze critical-chain | o unitate care stă secunde înainte ca tunelul să pornească | nu se aplică, încă nu se transferă nimic |
| Strângere de mână | journalctl -u openvpn-server@server -b | un interval lung înainte ca secvența de inițializare să se termine | nu se aplică, tunelul nu este ridicat |
| Transfer stabilit | ss -tin lângă sar -n DEV 1 | un proces blocat cu cozi de socket goale | cozi pline, retransmisii și un singur fir ocupat |
Două comenzi ieftine aparțin începutului acelei colecții și rezolvă întrebările ușoare înainte ca tabelul să fie măcar necesar. Contorul pe care îl citesc este contabilitate de entropie, nu un aparat de măsurat lățimea de bandă, iar o singură instantanee nu poate arăta că un proces este blocat, cât a așteptat sau ce interfață apelează funcțiile bibliotecii sale. O probă luată după recuperare ratează de obicei blocarea în întregime, așa că păstrați versiunea nucleului lângă citire.
cat /proc/sys/kernel/random/entropy_avail
uname -rPotriviți corecția cu citirea
Dacă nucleul așteaptă într-adevăr inițializarea, uitați-vă la calea de însămânțare suportată de platformă, nu la tunel. Unei mașini virtuale i se poate da un dispozitiv aleator furnizat de gazdă, cum ar fi virtio-rng, iar pregătirea imaginii contează pentru că o sămânță copiată neschimbat în mulți oaspeți nu este o inițializare independentă. Dacă o bibliotecă raportează eșecuri de însămânțare după pornire, inspectați sursa configurată și comportamentul furnizorului în loc să modificați setările nucleului.
ss -tin dst 203.0.113.7
sar -n DEV 1 5Documentația generatorului OpenSSL descrie cum această ierarhie obține intrare și când are loc reînsămânțarea, ceea ce este o afirmație mult mai îngustă decât mitul și valabilă doar pentru acea implementare. Un demon de entropie nu este o reparație universală de viteză, iar instalarea lui pentru a ridica un contor modifică o presupunere de securitate fără a demonstra o întârziere. Pentru debit, urmați calea datelor: un fir saturat, retransmisiile, pierderea externă și căderile de coadă au nevoie fiecare de altă corecție, iar dimensiunile bufferelor abordează bufferizarea socketurilor cu propriile dovezi de coadă.