At kjernens tilfeldigheit tek slutt er eit freistande forklaring på ein treg VPN, og nesten alltid den gale for symptomet folk rapporterer. Ein vert som ventar på tilfeldig utdata, stoppar på eit bestemt tidspunkt, vanlegvis tidleg i oppstarten eller under nøkkelhandtering. Ein tunnel som koplar seg raskt til og deretter overfører sakte skildrar i staden gjennomstrøyming. Skil dei to observasjonane før du installerer ein daemon for å rette eit tal du ikkje er ferdig med å lese.

Kvifor myten overlever

Begge problema er reelle, og dei ser like ut på avstand. Oppstartsstopp på ein nyoppstarta virtuell maskin skjer faktisk, og ein treg etablert tunnel er like reell. Feilen er å anta at det andre kjem av det første fordi kryptografi dukkar opp ein stad i begge historiene. Ingenting ved ordet kryptering tilseier at kvar overført byte brukar ein fersk byte med støy frå omgivnadene.

Slik verkar ikkje desse generatorane. Eit kryptografisk bibliotek held ein seeda generator og trekkjer utdata frå han, og re-seedar etter sin eigen policy, så det dyre augneblinken er seeding og ikkje jamn overføring.

Kva ein generator gjer per pakke

I OpenSSL 3 blir det standard generatorhierarkiet bygd av DRBG-førekomstar som seeder og re-seedar etter konfigurasjon og tilstand. I OpenVPN 2.6 leier AEAD-datastien nonce frå sekvensnummeret til pakken kombinert med ein implisitt verdi per sesjon, medan den eldre CBC-stien trekkjer ein pseudotilfeldig IV per pakke. Ingen av mønstra støttar ein regel om at flytting av ein gigabyte brukar ein gigabyte fersk kjernestøy. Begge støttar ideen om at nøkkelgenerering og handtrykk er der seeding betyr noko.

CBC-tilfellet fortener eit namn fordi det ser ut som myten og ikkje er det: IV-en per pakke kjem frå biblioteket sin generator etter biblioteket sin eigen re-seed-plan, aldri frå eit kjernekall per pakke. Når nokon viser til ein entropikostnad per byte, spør kva bibliotekversjon og kva kodeveg dei målte.

Kvar ventinga faktisk viser seg

Set tidsstempel rundt fasane i staden for rundt sesjonen: oppstart, autentisering, nøkkelbyte og overføring. Venta før tunnelen blir brukbar er ei anna klage enn ein låg jamn hastigheit, og berre éin av dei peiker på tilfeldet. På Linux kan ein normal getrandom() førespurnad blokkere til den tilfeldige kjelda til kjernen er initialisert, og difor er oppstartsvarianten av dette problemet reell på virtuelle maskinar og innebygde kort som tidleg har lite å fôre bassenget med.

FaseKva som skal køyrastAvlesing som tyder ventingAvlesing som tyder gjennomstrøyming
Oppstart, før nokon tunnelsystemd-analyze critical-chaineining som sit i sekund før tunnelen startarikkje aktuelt, ingenting blir overført enno
Handtrykkjournalctl -u openvpn-server@server -beit langt gap før initialiseringssekvensen er fullførtikkje aktuelt, tunnelen er ikkje oppe
Etablert overføringss -tin ved sida av sar -n DEV 1ein blokkert prosess med tomme socketkøarfulle køar, retransmisjonar og éin oppteken tråd

To billege kommandoar høyrer heime i starten av den innsamlinga, og dei avgjer dei enkle spørsmåla før tabellen i det heile er nødvendig. Teljaren dei les, er entropirekneskap og ikkje ein bandbreiddemålar, og eit enkelt augeblinksbilete kan ikkje vise at ein prosess er blokkert, kor lenge han venta eller kva grensesnitt bibliotekkalla brukar. Ein prøve teken etter gjenoppretting går som regel glipp av stoppen heilt, så hald kjerneversjonen ved sida av avlesinga.

cat /proc/sys/kernel/random/entropy_avail
uname -r

Tilpass rettinga til avlesinga

Viss kjernen verkeleg ventar på initialisering, sjå på den støtta seed-stien til plattforma i staden for tunnelen. Ei virtuell maskin kan få ei vertslevert tilfeldig eining, til dømes virtio-rng, og førebuing av biletet betyr noko fordi eit seed som blir kopiert uendra til mange gjester, ikkje er uavhengig initialisering. Viss eit bibliotek rapporterer seed-feil etter oppstart, undersøk den konfigurerte kjelda og åtferda til leverandøren i staden for å endre kjerneinnstillingar.

ss -tin dst 203.0.113.7
sar -n DEV 1 5

OpenSSL generatordokumentasjonen skildrar korleis dette hierarkiet får inndata og når re-seeding skjer, noko som er ein langt snevrare påstand enn myten og berre gjeld for den implementasjonen. Ein entropi-daemon er ikkje ei universell hastigheitsreparasjon, og å installere ein for å få ein teljar til å stige endrar ei tryggleiksantaking utan å vise ei forseinking. For gjennomstrøyming, følg datastien: éin metta tråd, retransmisjonar, ytre tap og køfall treng kvar si retting, og bufferstorleikar handterer socket-bufring med sitt eige købevis.

Relaterte artiklar