Nauubusan ba ng entropy ang isang VPN? Ano ang tunay na ipinapakita ng entropy_avail
Ang pagkahinto sa boot at ang mabagal na naitatag na tunnel ay dalawang magkaibang sira. Basahin ang yugto, ang tunay na kahulugan ng counter at ang pila bago sisihin ang randomness.
Ang pagkaubos ng randomness ng kernel ay kaakit-akit na paliwanag para sa mabagal na VPN, at halos palaging mali para sa sintomas na iniuulat ng mga tao. Ang host na naghihintay ng random na output ay humihinto sa isang partikular na sandali, kadalasan sa umpisa ng boot o habang hinahawakan ang mga key. Isang tunnel na mabilis kumonekta at pagkatapos ay mabagal maglipat ang inilalarawan sa halip ay ang throughput. Paghiwalayin ang dalawang obserbasyon bago mag-install ng daemon para ayusin ang isang numero na hindi mo pa tapos basahin.
Bakit nagtatagal ang alamat
Totoo ang dalawang problema at magkamukha sila mula sa malayo. Ang pagkahinto sa pagsisimula sa bagong boot na virtual machine ay talagang nangyayari, at ang mabagal na naitatag na tunnel ay kasing totoo. Ang mali ay ipagpalagay na ang pangalawa ay dulot ng una dahil may kriptograpiya sa isang lugar sa dalawang kuwento. Wala sa salitang encryption ang nagsasabing ang bawat byte na inilipat ay gumagamit ng bagong byte ng ingay ng kapaligiran.
Hindi ganoon gumagana ang mga generator na ito. Ang isang cryptographic library ay may generator na may binhi at kumukuha ng output mula rito, muling nagtatanim ng binhi ayon sa sarili nitong patakaran, kaya ang mamahaling sandali ay ang pagtatanim ng binhi, hindi ang tuluy-tuloy na paglilipat.
Ano ang ginagawa ng generator sa bawat packet
Sa OpenSSL 3 ang default na hierarchy ng generator ay binubuo ng mga DRBG instance na nagtatanim at muling nagtatanim ng binhi ayon sa configuration at estado. Sa OpenVPN 2.6 ang AEAD data path ay kumukuha ng nonce mula sa sequence number ng packet kasama ng implicit na halaga bawat session, habang ang mas lumang CBC path ay kumukuha ng pseudo-random na IV bawat packet. Wala sa dalawang pattern ang sumusuporta sa tuntuning ang paglipat ng isang gigabyte ay gumagamit ng isang gigabyte ng bagong ingay ng kernel. Pareho nilang sinusuportahan ang ideyang ang paggawa ng key at handshake ang lugar kung saan mahalaga ang pagtatanim ng binhi.
Ang kaso ng CBC ay dapat pangalanan dahil mukhang alamat ito at hindi: ang IV nito bawat packet ay nagmumula sa generator ng library ayon sa sariling iskedyul ng library sa muling pagtatanim ng binhi, kailanman hindi mula sa tawag sa kernel bawat packet. Kapag may sumipi ng halaga ng entropy bawat byte, itanong kung aling bersyon ng library at aling code path ang sinukat nila.
Saan talaga nakikita ang paghihintay
Maglagay ng timestamp sa paligid ng mga yugto, hindi ng session: pagsisimula, authentication, pagpapalit ng key at paglilipat. Ang paghihintay bago maging magagamit ang tunnel ay ibang reklamo kaysa sa mababang tuluy-tuloy na bilis, at isa lang sa dalawa ang tumuturo sa randomness. Sa Linux ang normal na getrandom() kahilingan ay maaaring ma-block hanggang sa ma-initialize ang random na pinagmulan ng kernel, kaya ang bersyon sa boot ng problemang ito ay totoo sa mga virtual machine at embedded board na kakaunti ang maipapakain sa pool sa simula.
| Yugto | Ano ang patatakbuhin | Pagbasa na nangangahulugang paghihintay | Pagbasa na nangangahulugang throughput |
|---|---|---|---|
| Boot, bago ang anumang tunnel | systemd-analyze critical-chain | isang unit na nakaupo nang ilang segundo bago magsimula ang tunnel | hindi naaangkop, wala pang inililipat |
| Handshake | journalctl -u openvpn-server@server -b | mahabang agwat bago matapos ang initialization sequence | hindi naaangkop, wala pang taas ang tunnel |
| Naitatag na paglilipat | ss -tin sa tabi ng sar -n DEV 1 | isang naka-block na proseso na may walang laman na socket queue | puno ang pila, retransmission at isang abalang thread |
Dalawang murang command ang nabibilang sa simula ng koleksyong iyon, at nilulutas nila ang madaling tanong bago pa kailanganin ang talahanayan. Ang counter na binabasa nila ay accounting ng entropy, hindi metro ng bandwidth, at ang isang snapshot ay hindi maipapakita na naka-block ang isang proseso, gaano katagal itong naghintay o aling interface ang tinatawag ng library nito. Ang sample na kinuha pagkatapos ng paggaling ay kadalasang tuluyang nakakaligtaan ang pagkahinto, kaya itago ang bersyon ng kernel sa tabi ng pagbasa.
cat /proc/sys/kernel/random/entropy_avail
uname -rItugma ang pagwawasto sa pagbasa
Kung talagang naghihintay ang kernel sa initialization, tingnan ang sinusuportahang seed path ng platform, hindi ang tunnel. Ang isang virtual machine ay maaaring bigyan ng random na device na ibinibigay ng host, tulad ng virtio-rng, at mahalaga ang paghahanda ng image dahil ang binhing kinopya nang walang pagbabago sa maraming guest ay hindi malayang initialization. Kung ang isang library ay nag-uulat ng mga kabiguan sa pagtatanim ng binhi pagkatapos ng boot, suriin ang naka-configure na pinagmulan at pag-uugali ng provider sa halip na baguhin ang mga setting ng kernel.
ss -tin dst 203.0.113.7
sar -n DEV 1 5Ang dokumentasyon ng generator ng OpenSSL ay naglalarawan kung paano nakakakuha ng input ang hierarchy na iyon at kailan nangyayari ang muling pagtatanim ng binhi, na isang mas makitid na pahayag kaysa sa alamat at totoo lamang para sa implementasyong iyon. Ang entropy daemon ay hindi pangkalahatang pag-aayos ng bilis, at ang pag-install nito para tumaas ang counter ay nagbabago ng palagay sa seguridad nang hindi nagpapakita ng pagkaantala. Para sa throughput, sundan ang data path: isang saturated na thread, retransmission, panlabas na pagkawala at pagbagsak ng queue ay nangangailangan ng kanya-kanyang pagwawasto, at ang laki ng buffer ay humahawak sa socket buffering kasama ang sarili nitong ebidensya sa queue.