Je li nizak VPN protok problem entropije? Obično nije

Spor protok kroz tunel i mašina zaglavljena u čekanju slučajnih brojeva daju vrlo različita iskustva, ali se ipak evidentiraju pod istom pritužbom. Jedno se pojavljuje kao pauza pre nego što išta radi. Drugo se pojavljuje kao veza koja radi i polako prenosi podatke dok god je gledate. Utvrditi koje imate traje deset minuta i štedi nedelju nagađanja.

Dva simptoma koja izgledaju isto

Usluga koja se zaglavi nakon svežeg podizanja, pre nego što prihvati ijednu vezu, čeka nešto. Tunel koji se brzo uspostavi i zatim prenosi delićem očekivane brzine ograničen je nečim drugim. Reč enkripcija pojavljuje se u obe priče, zbog čega se spajaju. Razdvojite ih pre nego što dotaknete konfiguracionu datoteku.

Postavite vremenske oznake oko pokretanja, autentifikacije, ponovnog pregovaranja ključeva i samog prenosa. Duga odgoda pre nego što tunel postane upotrebljiv nije niska stalna brzina, a usrednjavanje njih dvoje u jedan broj uništava dokaz.

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

Prve dve naredbe stavljaju rad pri pokretanju na vremensku liniju. Treća ispisuje vrednost knjigovodstva entropije u kernelu, koja je korisna kao jedna podatkovna točka i beskorisna kao merač propusnosti.

Kako čekanje na slučajne brojeve zapravo izgleda

Zahtev za sigurne slučajne bajtove može blokirati dok kernel ne inicijalizuje svoj slučajni izvor. To je najvažnije na virtuelnim mašinama i malim ugrađenim pločama na početku podizanja, kada je prikupljeno malo šuma iz okoline. Iz toga ne sledi da svaki enkriptirani bajt troši svežu entropiju.

Moderni generatori se zasijavaju jednom i zatim proizvode izlaz iz determinističke konstrukcije, ponovo se zasijavajući po sopstvenom rasporedu. Skupni prenos ne iscrpljuje pul bajt po bajt, pa niska vrednost pula tokom sporog prenosa ne dokazuje ništa o uzroku.

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

Prva naredba pokazuje sedi li proces u pozivu slučajnih brojeva dok gledate. Druga pokazuje kernelove sopstvene poruke inicijalizacije, i tu zastoj pri ranom podizanju postaje vidljiv.

Zabeležite verziju kernela i biblioteku sa kojom se usluga zapravo povezuje, jer ponašanje se razlikuje između implementacija i između izdanja. Trag snimljen nakon oporavka obično u potpunosti promaši pauzu.

Kako trajna sporost zapravo izgleda

Tunel koji sve vreme polako prenosi ograničen je podatkovnim putem. Jedna zasićena nit, gubitak spoljnih paketa, ponovni prenosi ili puni redovi utičnica svaki proizvode taj uzorak, i svaki ima svoje rešenje. Zbirni procenat CPU-a skriva jednu zauzetu nit, što je najčešće pogrešno čitanje. Pogledajte vreme po niti pre nego što pogledate ukupno opterećenje.

Merite u oba smera sa uporedivom osnovom i gledajte brojače interfejsa, a ne sopstveni izveštaj aplikacije.

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

Prva naredba pokazuje stanje reda i zagušenja za jednog partnera. Druga i treća prijavljuju odbacivanja i ponovne prenose na steku i na interfejsu, gde se uzrok obično pojavljuje prvi.

Odaberite ispravku za usko grlo koje ste izmerili

Ako dokazi upućuju na inicijalizaciju pri ranom podizanju, pogledajte podržani put zasijavanja platforme, koji na virtuelnoj mašini može uključivati slučajni uređaj koji pruža host. Slika semena kopirana nepromenjena u mnoge goste nije zamena za nezavisnu inicijalizaciju.

Ako dokazi upućuju na podatkovni put, podesite ono na šta brojači upućuju. Veličine bafera pomažu kada redovi preliju i ne čine ništa kada je jedna nit zasićena. Instaliranje demona entropije da podigne brojač nije popravka protoka, a promena pretpostavki zasijavanja da graf izgleda bolje menja sigurnosno svojstvo za broj.

Prihvatite promenu samo kada se isto merenje poboljša pod istim uslovima. Veći brojač nije rezultat; kraće izmereno čekanje ili brži prenos sa utvrđenim uzrokom jeste.