Går en VPN tom for entropi? Hva entropy_avail egentlig viser
En oppstartsforsinkelse og en treg etablert tunnel er to forskjellige feil. Les fasen, tellerens reelle betydning og køen før du gir tilfeldigheten skylden.
At kjernens tilfeldighet tar slutt er en fristende forklaring på en treg VPN, og nesten alltid den gale for symptomet folk rapporterer. En vert som venter på tilfeldig utdata, stopper på et bestemt tidspunkt, vanligvis tidlig i oppstarten eller under nøkkelhåndtering. En tunnel som kobler seg raskt til og deretter overfører sakte beskriver i stedet gjennomstrømning. Skill de to observasjonene før du installerer en daemon for å rette et tall du ikke er ferdig med å lese.
Hvorfor myten overlever
Begge problemene er reelle, og de ser like ut på avstand. Oppstartsstopp på en nyoppstartet virtuell maskin skjer faktisk, og en treg etablert tunnel er like reell. Feilen er å anta at det andre skyldes det første fordi kryptografi dukker opp et sted i begge historiene. Ingenting ved ordet kryptering tilsier at hver overført byte bruker en fersk byte med støy fra omgivelsene.
Slik virker ikke disse generatorene. Et kryptografisk bibliotek holder en seedet generator og trekker utdata fra den, og re-seeder etter sin egen policy, så det dyre øyeblikket er seeding og ikke jevn overføring.
Hva en generator gjør per pakke
I OpenSSL 3 bygges den standard generatorhierarkiet av DRBG-forekomster som seeder og re-seeder etter konfigurasjon og tilstand. I OpenVPN 2.6 utleder AEAD-datastien nonce fra pakkens sekvensnummer kombinert med en implisitt verdi per sesjon, mens den eldre CBC-stien trekker en pseudotilfeldig IV per pakke. Ingen av mønstrene støtter en regel om at flytting av en gigabyte bruker en gigabyte fersk kjernestøy. Begge støtter ideen om at nøkkelgenerering og håndtrykk er der seeding betyr noe.
CBC-tilfellet fortjener et navn fordi det ser ut som myten og ikke er det: IV-en per pakke kommer fra bibliotekets generator etter bibliotekets egen re-seed-plan, aldri fra et kjernekall per pakke. Når noen viser til en entropikostnad per byte, spør hvilken bibliotekversjon og hvilken kodevei de målte.
Hvor ventingen faktisk vises
Sett tidsstempler rundt fasene i stedet for rundt sesjonen: oppstart, autentisering, nøkkelbytte og overføring. Venting før tunnelen blir brukbar er en annen klage enn en lav jevn hastighet, og bare én av dem peker på tilfeldighet. På Linux kan en normal getrandom() forespørsel blokkere til kjernens tilfeldige kilde er initialisert, og derfor er oppstartsvarianten av dette problemet reell på virtuelle maskiner og innebygde kort som tidlig har lite å fôre bassenget med.
| Fase | Hva som skal kjøres | Avlesning som betyr venting | Avlesning som betyr gjennomstrømning |
|---|---|---|---|
| Oppstart, før noen tunnel | systemd-analyze critical-chain | en enhet som sitter i sekunder før tunnelen starter | ikke aktuelt, ingenting overføres ennå |
| Håndtrykk | journalctl -u openvpn-server@server -b | et langt gap før initialiseringssekvensen er fullført | ikke aktuelt, tunnelen er ikke oppe |
| Etablert overføring | ss -tin ved siden av sar -n DEV 1 | en blokkert prosess med tomme socketkøer | fulle køer, retransmisjoner og én opptatt tråd |
To billige kommandoer hører hjemme i starten av den innsamlingen, og de avgjør de enkle spørsmålene før tabellen i det hele tatt er nødvendig. Telleren de leser, er entropiregnskap og ikke en båndbreddemåler, og et enkelt øyeblikksbilde kan ikke vise at en prosess er blokkert, hvor lenge den ventet eller hvilket grensesnitt bibliotekkallene bruker. En prøve tatt etter gjenoppretting går som regel glipp av stoppen helt, så hold kjerneversjonen ved siden av avlesningen.
cat /proc/sys/kernel/random/entropy_avail
uname -rTilpass rettelsen til avlesningen
Hvis kjernen virkelig venter på initialisering, se på plattformens støttede seed-sti i stedet for tunnelen. En virtuell maskin kan få en vertslevert tilfeldig enhet, for eksempel virtio-rng, og forberedelse av avbildet betyr noe fordi et seed som kopieres uendret til mange gjester, ikke er uavhengig initialisering. Hvis et bibliotek rapporterer seed-feil etter oppstart, undersøk den konfigurerte kilden og leverandøratferden i stedet for å endre kjerneinnstillinger.
ss -tin dst 203.0.113.7
sar -n DEV 1 5OpenSSL generatordokumentasjonen beskriver hvordan dette hierarkiet får inndata og når re-seeding skjer, noe som er en langt snevrere påstand enn myten og bare gjelder for den implementasjonen. En entropi-daemon er ikke en universell hastighetsreparasjon, og å installere en for å få en teller til å stige endrer en sikkerhetsantakelse uten å påvise en forsinkelse. For gjennomstrømning, følg datastien: én mettet tråd, retransmisjoner, ytre tap og køfall trenger hver sin rettelse, og bufferstørrelser håndterer socket-bufring med sitt eget købevis.