Pomalá priepustnosť tunelom a stroj zaseknutý pri čakaní na náhodné čísla vytvárajú veľmi odlišné zážitky, no napriek tomu sa evidujú pod tou istou sťažnosťou. Jedno sa prejaví ako pauza, kým čokoľvek funguje. Druhé sa prejaví ako spojenie, ktoré funguje a pomaly presúva dáta, kým sa naň pozeráte. Rozhodnúť, ktoré máte, trvá desať minút a ušetrí týždeň hádania.

Dva príznaky, ktoré vyzerajú rovnako

Služba, ktorá po čerstvom štarte visí, kým prijme jediné spojenie, na niečo čaká. Tunel, ktorý sa rýchlo nadviaže a potom prenáša zlomkom očakávanej rýchlosti, je obmedzený niečím iným. Slovo šifrovanie sa objavuje v oboch príbehoch, a preto sa zlučujú. Oddeľte ich, kým sa dotknete konfiguračného súboru.

Umiestnite časové pečiatky okolo štartu, autentifikácie, opätovného vyjednávania kľúčov a samotného prenosu. Dlhé oneskorenie, kým je tunel použiteľný, nie je nízka stabilná rýchlosť, a spriemerovanie oboch do jedného čí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

Prvé dva príkazy stavajú prácu pri štarte na časovú os. Tretí vypisuje účtovnú hodnotu entropie jadra, ktorá je užitočná ako jediný dátový bod a nepoužiteľná ako merač šírky pásma.

Ako čakanie na náhodné čísla skutočne vyzerá

Žiadosť o bezpečné náhodné bajty sa môže zablokovať, kým jadro neinicializuje svoj náhodný zdroj. To je najdôležitejšie na virtuálnych strojoch a malých vstavaných doskách na začiatku štartu, keď sa zhromaždilo málo okolitého šumu. Z toho nevyplýva, že každý šifrovaný bajt spotrebúva čerstvú entropiu.

Moderné generátory sa nasadia raz a potom produkujú výstup z deterministickej konštrukcie, pričom sa znova nasadzujú podľa vlastného plánu. Hromadný prenos nevyprazdňuje fond bajt po bajte, takže nízka hodnota fondu počas pomalého prenosu nič nedokazuje o príčine.

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

Prvý príkaz ukazuje, či proces sedí vo volaní náhodných čísel, kým sa pozeráte. Druhý ukazuje vlastné inicializačné správy jadra, a práve tam je zaseknutie pri skorom štarte viditeľné.

Zaznamenajte verziu jadra a knižnicu, proti ktorej služba skutočne linkuje, pretože správanie sa líši medzi implementáciami a medzi vydaniami. Trasovanie zhotovené po obnovení zvyčajne pauzu úplne minie.

Ako trvalá pomalosť skutočne vyzerá

Tunel, ktorý prenáša pomaly celý čas, je obmedzený dátovou cestou. Jedno nasýtené vlákno, strata vonkajších paketov, opakované prenosy alebo plné fronty socketov každé vytvárajú ten vzor a každé má svoju vlastnú opravu. Súhrnné percento CPU skrýva jediné zaneprázdnené vlákno, a to je najčastejšie chybné čítanie. Pozrite sa na čas na vlákno, skôr než sa pozriete na celkové zaťaženie.

Merajte v oboch smeroch s porovnateľnou základňou a sledujte čítače rozhrania, nie správu samotnej aplikácie.

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

Prvý príkaz ukazuje stav frontu a preťaženia pre jedného partnera. Druhý a tretí hlásia zahadzovania a opakované prenosy v zásobníku a na rozhraní, kde sa príčina zvyčajne objaví prvá.

Vyberte opravu pre úzke miesto, ktoré ste zmerali

Ak dôkazy ukazujú na inicializáciu pri skorom štarte, pozrite sa na podporovanú cestu seedovania platformy, ktorá na virtuálnom stroji môže zahŕňať náhodné zariadenie poskytnuté hostiteľom. Obraz semena skopírovaný bez zmien do mnohých hostí nenahrádza nezávislú inicializáciu.

Ak dôkazy ukazujú na dátovú cestu, vyladte to, na čo čítače poukazujú. Veľkosti bufferov pomáhajú, keď fronty pretekajú, a nerobia nič, keď je jedno vlákno nasýtené. Inštalácia daemona entropie na zdvihnutie čítača nie je oprava priepustnosti a zmena predpokladov seedovania, aby graf vyzeral lepšie, vymieňa bezpečnostnú vlastnosť za číslo.

Zmenu prijmite len vtedy, keď sa to isté meranie zlepší za rovnakých podmienok. Väčší čítač nie je výsledok; kratšie namerané čakanie alebo rýchlejší prenos s určenou príčinou je výsledok.

Súvisiace články