Je nízká propustnost VPN problém entropie? Obvykle ne

Pomalá propustnost tunelem a stroj zaseknutý při čekání na náhodná čísla vytvářejí velmi odlišné zážitky, přesto se evidují pod stejnou stížností. Jedno se projeví jako pauza, než cokoli funguje. Druhé se projeví jako spojení, které funguje a pomalu přenáší data, dokud se na něj díváte. Rozhodnout, které máte, trvá deset minut a ušetří týden hádání.

Dva příznaky, které vypadají stejně

Služba, která po čerstvém startu visí, než přijme jediné spojení, na něco čeká. Tunel, který se rychle naváže a poté přenáší zlomkem očekávané rychlosti, je omezen něčím jiným. Slovo šifrování se objevuje v obou příbězích, a proto se slučují. Oddělte je, než sáhnete na konfigurační soubor.

Umístěte časová razítka kolem startu, autentizace, opětovného vyjednávání klíčů a samotného přenosu. Dlouhé zpoždění, než je tunel použitelný, není nízká stálá rychlost, a zprůměrování obou do jednoho čísla ničí důkaz.

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

První dva příkazy staví práci při startu na časovou osu. Třetí vypisuje účetní hodnotu entropie jádra, která je užitečná jako jediný datový bod a nepoužitelná jako měřič šířky pásma.

Jak čekání na náhodná čísla skutečně vypadá

Požadavek na bezpečné náhodné bajty se může zablokovat, dokud jádro neinicializuje svůj náhodný zdroj. To je nejdůležitější na virtuálních strojích a malých vestavěných deskách na začátku startu, kdy je shromážděno málo okolního šumu. Z toho neplyne, že každý šifrovaný bajt spotřebovává čerstvou entropii.

Moderní generátory se nasadí jednou a poté produkují výstup z deterministické konstrukce a znovu se nasazují podle vlastního plánu. Hromadný přenos nevyprazdňuje fond bajt po bajtu, takže nízká hodnota fondu během pomalého přenosu nic nedokazuje o příčině.

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

První příkaz ukazuje, zda proces sedí ve volání náhodných čísel, zatímco se díváte. Druhý ukazuje vlastní inicializační zprávy jádra, a právě tam je zaseknutí při raném startu viditelné.

Zaznamenejte verzi jádra a knihovnu, proti níž služba skutečně linkuje, protože chování se liší mezi implementacemi a mezi verzemi. Trasování pořízené po obnovení obvykle pauzu úplně mine.

Jak trvalá pomalost skutečně vypadá

Tunel, který přenáší pomalu po celou dobu, je omezen datovou cestou. Jedno nasycené vlákno, ztráta vnějších paketů, opakované přenosy nebo plné fronty socketů každý vytvářejí tento vzorec a každý má svou opravu. Souhrnné procento CPU skrývá jediné zaneprázdněné vlákno, což je nejčastější chybné čtení. Podívejte se na čas na vlákno, než se podíváte na celkové zatížení.

Měřte v obou směrech s porovnatelnou základnou a sledujte čítače rozhraní, ne vlastní zprávu aplikace.

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

První příkaz ukazuje stav fronty a zahlcení pro jednoho protějšek. Druhý a třetí hlásí zahazování a opakované přenosy na zásobníku a na rozhraní, kde se příčina obvykle objeví první.

Zvolte opravu pro úzké místo, které jste změřili

Pokud důkazy ukazují na inicializaci při raném startu, podívejte se na podporovanou cestu seedování platformy, která na virtuálním stroji může zahrnovat náhodné zařízení poskytnuté hostitelem. Obraz seedu zkopírovaný beze změny do mnoha hostů není náhradou nezávislé inicializace.

Pokud důkazy ukazují na datovou cestu, vylaďte to, co čítače naznačují. Velikosti bufferů pomáhají, když fronty přetékají, a nedělají nic, když je jedno vlákno nasycené. Instalace daemona entropie, aby se zvedl čítač, není oprava propustnosti, a změna předpokladů seedování, aby graf vypadal lépe, vyměňuje bezpečnostní vlastnost za číslo.

Změnu přijměte jen tehdy, když se stejné měření zlepší za stejných podmínek. Větší čítač není výsledek; kratší změřené čekání nebo rychlejší přenos s určenou příčinou je.