Je nizka prepustnost VPN problem entropije? Običajno ne

Počasna prepustnost skozi tunel in stroj, ki obtiči med čakanjem na naključna števila, dajeta zelo različne izkušnje, a se vseeno evidentirata pod isto pritožbo. Eno se pokaže kot premor, preden karkoli deluje. Drugo se pokaže kot povezava, ki deluje in počasi premika podatke, dokler jo opazujete. Ugotoviti, katero imate, traja deset minut in prihrani teden ugibanja.

Dva znaka, ki se zdita enaka

Storitev, ki se po svežem zagonu obesi, preden sprejme eno samo povezavo, na nekaj čaka. Tunel, ki se hitro vzpostavi in nato prenaša z delčkom pričakovane hitrosti, omejuje nekaj drugega. Beseda šifriranje se pojavi v obeh zgodbah, zato ju združujejo. Ločite ju, preden se dotaknete konfiguracijske datoteke.

Okoli zagona, overjanja, ponovnega pogajanja o ključih in samega prenosa postavite časovne žige. Dolga zamuda, preden je tunel uporaben, ni nizka stalna hitrost, povprečenje obeh v eno število pa uniči dokaz.

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

Prva dva ukaza postavita delo ob zagonu na časovnico. Tretji izpiše računovodsko vrednost entropije jedra, ki je koristna kot ena podatkovna točka in neuporabna kot merilnik pasovne širine.

Kako čakanje na naključna števila v resnici izgleda

Zahteva za varne naključne bajte se lahko blokira, dokler jedro ne inicializira svojega naključnega vira. To je najpomembnejše na virtualnih strojih in majhnih vgrajenih ploščah na začetku zagona, ko je zbranega malo okoljskega šuma. Iz tega ne sledi, da vsak šifriran bajt porabi svežo entropijo.

Sodobni generatorji se enkrat nasadijo in nato proizvajajo izhod iz deterministične konstrukcije, znova se nasadijo po svojem urniku. Množični prenos ne izprazni bazena bajt za bajtom, zato nizka vrednost bazena med počasnim prenosom ničesar ne dokaže o vzroku.

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

Prvi ukaz pokaže, ali proces sedi v klicu naključnih števil, medtem ko opazujete. Drugi pokaže lastna inicializacijska sporočila jedra, in prav tam postane zastoj ob zgodnjem zagonu viden.

Zapišite različico jedra in knjižnico, s katero je storitev dejansko povezana, ker se vedenje razlikuje med izvedbami in med izdajami. Sled, posneta po obnovitvi, običajno popolnoma zgreši premor.

Kako trajna počasnost v resnici izgleda

Tunel, ki ves čas prenaša počasi, omejuje podatkovna pot. Ena nasičena nit, izguba zunanjih paketov, ponovni prenosi ali polne čakalne vrste vtičnic vsak ustvari ta vzorec in vsak ima svoj popravek. Skupni odstotek CPU skrije eno zasedeno nit, in to je najpogostejše napačno branje. Poglejte čas na nit, preden pogledate skupno obremenitev.

Merite v obe smeri s primerljivo osnovno linijo in spremljajte števce vmesnika, ne poročila same aplikacije.

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

Prvi ukaz pokaže stanje čakalne vrste in zastoja za enega partnerja. Drugi in tretji poročata o zavrnitvah in ponovnih prenosih v skladu in na vmesniku, kjer se vzrok običajno pojavi prvi.

Izberite popravek za ozko grlo, ki ste ga izmerili

Če dokazi kažejo na inicializacijo ob zgodnjem zagonu, poglejte podprto pot sejanja platforme, ki na virtualnem stroju lahko vključuje naključno napravo, ki jo zagotovi gostitelj. Slika semena, kopirana nespremenjena v številne goste, ne nadomesti neodvisne inicializacije.

Če dokazi kažejo na podatkovno pot, prilagodite tisto, na kar kažejo števci. Velikosti medpomnilnikov pomagajo, ko se čakalne vrste prelijejo, in ne naredijo ničesar, ko je ena nit nasičena. Namestitev demona entropije za dvig števca ni popravilo prepustnosti, spreminjanje predpostavk sejanja, da bi graf izgledal bolje, pa zamenja varnostno lastnost za število.

Spremembo sprejmite le, ko se enaka meritev izboljša pod enakimi pogoji. Večji števec ni rezultat; krajše izmerjeno čakanje ali hitrejši prenos z ugotovljenim vzrokom je rezultat.