Is lege VPN-trochset in entropieprobleem? Meastentiids net

Lege trochset troch in tunnel en in masine dy't fêstsit yn it wachtsjen op tafallige getallen jouwe hiel ferskillende ûnderfiningen, mar se wurde dochs ûnder deselde klacht registrearre. It iene docht bliken as in skoft foardat wat dan ek wurket. It oare docht bliken as in ferbining dy't wurket en gegevens stadich ferpleatst salang't jo dernei sjogge. Beslute hokker oft jo hawwe duorret tsien minuten en sparret in wike rieden.

Twa symptomen dy't opinoar lykje

In tsjinst dy't hinget nei in farske opstart, foardat er ien inkele ferbining akseptearret, wachtet op eat. In tunnel dy't fluch fêststeld wurdt en dan mei in fraksje fan 'e ferwachte faasje oerdraacht, wurdt beheind troch eat oars. It wurd fersifering komt yn beide ferhalen foar, dêrom wurde se gearfoege. Skied se foardat jo in konfiguraasjebestân oanreitsje.

Set tiidstimpels om opstart, ferifikaasje, kaaiwerûnderhanneling en de oerdracht sels. In lange fertraging foardat de tunnel brûkber is, is gjin lege stive faasje, en it gemiddelde fan 'e beide yn ien getal ferneatiget it bewiis.

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

De earste twa opdrachten sette opstartwurk op in tiidline. De tredde printet de kernel syn entropie-administraasjewearde, dy't brûkber is as ien datapunt en nutteloas as bânbreedtemeter.

Hoe't in wachtsjen op tafallige getallen der echt útsjocht

In fersyk om feilige tafallige bytes kin blokkearje oant de kernel syn tafallige boarne initialisearre hat. Dat makket it measte út op firtuele masines en lytse ynboude buordsjes ier yn 'e opstart, as der mar in bytsje omjouwingslûd sammele is. Dêrfandinne folget net dat elke fersifere byte farske entropie ferbrûkt.

Moderne generators wurde ien kear seed en produsearje dêrnei útfier út in deterministyske konstruksje, wêrby't se harsels op har eigen skema opnij seed. Bulk-oerdracht drainet gjin poel byte foar byte, dus in lege poelwearde by in stadige oerdracht bewiist neat oer de oarsaak.

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

De earste opdracht lit sjen oft it proses yn in oprop foar tafallige getallen sit wylst jo sjogge. De twadde lit de kernel syn eigen initialisaasjebesjochten sjen, en dêr wurdt in iere opstartstilstân sichtber.

Notearje de kernelferzje en de bibleteek dêr't de tsjinst echt oan keppele is, want it gedrach ferskilt tusken ymplemintaasjes en tusken útjeften. In trace dy't nei it herstel nommen wurdt, mist it skoft meastentiids hielendal.

Hoe't oanhâldende stadigens der echt útsjocht

In tunnel dy't de hiele tiid stadich oerdraacht, wurdt beheind troch it gegevenspaad. Ien fersêde tried, ferlies fan bûtenste pakketten, weromstjoeringen of folle socket-rijen produsearje elk dat patroan, en elk hat syn eigen oplossing. Gearfoege CPU-persintaazje ferberget ien drokke tried, dat is de meast foarkommende ferkearde lêzing. Sjoch nei tiid per tried foardat jo nei de totale lading sjogge.

Mjit yn beide rjochtingen mei in ferlykbere basisline, en hâld de ynterface-tellers yn 'e gaten ynstee fan it rapport fan 'e applikaasje sels.

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

De earste opdracht lit de rige- en oerladingstastân foar ien peer sjen. De twadde en tredde rapportearje drops en weromstjoeringen by de stapel en by de ynterface, dêr't de oarsaak meastentiids it earst ferskynt.

Kies de korreksje foar de knelpunt dy't jo metten hawwe

As it bewiis nei iere opstartinitialisaasje wiist, sjoch dan nei it stipe seedingpaad fan it platfoarm, dat op in firtuele masine in troch de host levere tafallich apparaat omfetsje kin. In seedbyld dat ûnferoare yn in protte gasten kopyearre wurdt, is gjin ferfanging foar ûnôfhinklike initialisaasje.

As it bewiis nei it gegevenspaad wiist, stel dan ôf wat de tellers oanjaan. Buffergrutten helpe as rijen oerstreame en dogge neat as ien tried fersêde is. It ynstallearjen fan in entropie-demon om in teller te ferheegjen is gjin trochsetreparaasje, en it feroarjen fan seeding-oannames om in grafyk better lykje te litten ruilet in feiligensskea foar in getal.

Akseptearje de feroaring allinnich as deselde mjitting ûnder deselde omstannichheden better wurdt. In grutter teller is gjin resultaat; in koarter metten wachtsjen of in fluggere oerdracht mei in identifisearre oarsaak is dat wol.