Problema ba sa entropy ang mababang throughput ng VPN? Karaniwang hindi

Ang mabagal na throughput sa isang tunnel at isang makina na natigil sa paghihintay ng mga random na numero ay nagbibigay ng magkaibang karanasan, ngunit naitala pa rin sila sa ilalim ng parehong reklamo. Ang isa ay lumilitaw bilang paghinto bago gumana ang anuman. Ang isa ay lumilitaw bilang koneksyon na gumagana at mabagal na naglilipat ng data hangga't pinapanood mo ito. Ang pagtukoy kung alin ang mayroon ka ay tumatagal ng sampung minuto at nakakatipid ng isang linggong hula.

Dalawang sintomas na magkamukha

Ang serbisyong bumabitin pagkatapos ng bagong boot, bago tumanggap ng kahit isang koneksyon, ay naghihintay ng isang bagay. Ang tunnel na mabilis na naitatag at pagkatapos ay naglilipat sa maliit na bahagi ng inaasahang bilis ay nililimitahan ng ibang bagay. Ang salitang encryption ay lumilitaw sa parehong kuwento, kaya pinagsasama sila. Paghiwalayin sila bago mo hawakan ang file ng configuration.

Maglagay ng mga timestamp sa paligid ng pagsisimula, pagpapatotoo, muling negosasyon ng mga key at ang paglilipat mismo. Ang mahabang pagkaantala bago magamit ang tunnel ay hindi mababang matatag na bilis, at ang pag-average ng dalawa sa isang numero ay sumisira sa ebidensya.

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

Ang unang dalawang utos ay naglalagay ng gawain sa pagsisimula sa isang timeline. Ang pangatlo ay nagpi-print ng halaga ng accounting ng entropy ng kernel, na kapaki-pakinabang bilang isang data point at walang gamit bilang metro ng bandwidth.

Paano talaga nagmumukha ang paghihintay ng mga random na numero

Ang kahilingan para sa mga secure na random na byte ay maaaring harangan hanggang ma-initialize ng kernel ang random na pinagmulan nito. Pinakamahalaga ito sa mga virtual machine at maliliit na embedded board sa unang bahagi ng boot, kapag kakaunti pa lang ang naipon na ingay ng kapaligiran. Hindi ibig sabihin nito na ang bawat encrypted na byte ay gumagamit ng sariwang entropy.

Ang mga modernong generator ay nai-seed nang isang beses at pagkatapos ay gumagawa ng output mula sa isang deterministikong konstruksyon, at nagre-reseed ayon sa sarili nilang iskedyul. Ang bulk transfer ay hindi nag-uubos ng pool byte bawat byte, kaya ang mababang halaga ng pool habang mabagal na paglilipat ay walang pinatutunayan tungkol sa sanhi.

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

Ipinapakita ng unang utos kung ang proseso ay nakaupo sa isang tawag sa random na numero habang nagmamasid ka. Ipinapakita ng pangalawa ang sariling mga mensahe ng initialization ng kernel, at doon nagiging nakikita ang pagkaantala sa maagang boot.

Itala ang bersyon ng kernel at ang aklatan na aktwal na naka-link ng serbisyo, dahil nag-iiba ang pag-uugali sa pagitan ng mga implementasyon at ng mga release. Ang trace na kinuha pagkatapos ng pagbawi ay karaniwang hindi nakikita ang paghinto.

Paano talaga nagmumukha ang tuloy-tuloy na kabagalan

Ang tunnel na mabagal na naglilipat sa buong oras ay nililimitahan ng landas ng data. Isang saturated na thread, pagkawala ng panlabas na packet, mga retransmission o punong pila ng socket ang bawat isa ay gumagawa ng ganoong pattern, at bawat isa ay may sariling pagwawasto. Ang pinagsama-samang porsyento ng CPU ay nagtatago ng isang abalang thread, at ito ang pinakakaraniwang maling pagbasa. Tingnan ang oras bawat thread bago tingnan ang kabuuang load.

Sukatin sa parehong direksyon gamit ang maihahambing na baseline, at panoorin ang mga counter ng interface sa halip na ang ulat ng aplikasyon mismo.

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

Ipinapakita ng unang utos ang estado ng pila at siksikan para sa isang peer. Ang pangalawa at pangatlo ay nag-uulat ng mga drop at retransmission sa stack at sa interface, kung saan karaniwang unang lumilitaw ang sanhi.

Piliin ang pagwawasto para sa bottleneck na sinukat mo

Kung ang ebidensya ay tumuturo sa maagang initialization ng boot, tingnan ang sinusuportahang landas ng seeding ng platform, na sa isang virtual machine ay maaaring may kasamang random na device na ibinigay ng host. Ang seed image na kinopya nang walang pagbabago sa maraming guest ay hindi kapalit ng malayang initialization.

Kung ang ebidensya ay tumuturo sa landas ng data, i-tune ang itinuturo ng mga counter. Nakakatulong ang mga sukat ng buffer kapag umaapaw ang mga pila at wala silang ginagawa kapag saturado ang isang thread. Ang pag-install ng entropy daemon para itaas ang isang counter ay hindi pagkukumpuni ng throughput, at ang pagbabago ng mga palagay sa seeding para magmukhang mas maganda ang isang graph ay ipinagpapalit ang isang katangian ng seguridad sa isang numero.

Tanggapin ang pagbabago lamang kapag ang parehong pagsukat ay bumuti sa parehong mga kondisyon. Ang mas malaking counter ay hindi resulta; ang mas maikling sinukat na paghihintay o mas mabilis na paglilipat na may natukoy na sanhi ang resulta.