Is lage VPN-doorvoer een entropieprobleem? Meestal niet

Lage doorvoer door een tunnel en een machine die vastloopt bij het wachten op willekeurige getallen geven heel verschillende ervaringen, maar ze worden onder dezelfde klacht geregistreerd. Het ene uit zich als een pauze voordat er iets werkt. Het andere uit zich als een verbinding die werkt en gegevens langzaam verplaatst zolang u kijkt. Bepalen welke u hebt kost tien minuten en bespaart een week gissen.

Twee symptomen die op elkaar lijken

Een dienst die na een verse opstart blijft hangen, voordat hij één verbinding accepteert, wacht op iets. Een tunnel die snel tot stand komt en daarna overdraagt met een fractie van de verwachte snelheid, wordt door iets anders beperkt. Het woord versleuteling komt in beide verhalen voor, daarom worden ze samengevoegd. Scheid ze voordat u een configuratiebestand aanraakt.

Plaats tijdstempels rond opstart, authenticatie, sleutelheronderhandeling en de overdracht zelf. Een lange vertraging voordat de tunnel bruikbaar is, is geen lage stabiele snelheid, en het gemiddelde van beide in één getal vernietigt het bewijs.

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

De eerste twee opdrachten zetten opstartwerk op een tijdlijn. De derde drukt de entropieboekhoudwaarde van de kernel af, die nuttig is als één datapunt en nutteloos als bandbreedtemeter.

Hoe een wachttijd op willekeurige getallen er werkelijk uitziet

Een verzoek om veilige willekeurige bytes kan blokkeren tot de kernel zijn willekeurige bron heeft geïnitialiseerd. Dat telt het zwaarst op virtuele machines en kleine embedded boards vroeg in de opstart, wanneer er weinig omgevingsruis is verzameld. Daaruit volgt niet dat elke versleutelde byte verse entropie verbruikt.

Moderne generatoren worden één keer geseed en produceren daarna uitvoer uit een deterministische constructie, en reseeden volgens hun eigen schema. Bulkoverdracht put een pool niet byte voor byte uit, dus een lage poolwaarde tijdens een langzame overdracht bewijst niets over de oorzaak.

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

De eerste opdracht laat zien of het proces in een willekeuriggetal-aanroep zit terwijl u kijkt. De tweede toont de initialisatiemeldingen van de kernel zelf, en daar wordt een vroege opstartstilstand zichtbaar.

Noteer de kernelversie en de bibliotheek waartegen de dienst werkelijk linkt, want het gedrag verschilt tussen implementaties en tussen releases. Een trace die na herstel wordt genomen, mist de pauze meestal volledig.

Hoe aanhoudende traagheid er werkelijk uitziet

Een tunnel die de hele tijd langzaam overdraagt, wordt door het datapad beperkt. Eén verzadigde thread, verlies van buitenste pakketten, hertransmissies of volle socketwachtrijen veroorzaken elk dat patroon, en elk heeft zijn eigen oplossing. Geaggregeerd CPU-percentage verbergt één drukke thread, en dat is de meest voorkomende verkeerde lezing. Kijk naar tijd per thread voordat u naar de totale belasting kijkt.

Meet in beide richtingen met een vergelijkbare basislijn, en let op de interfacetellers in plaats van het rapport van de toepassing zelf.

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

De eerste opdracht toont de wachtrij- en congestiestatus voor één peer. De tweede en derde melden drops en hertransmissies in de stack en op de interface, waar de oorzaak meestal het eerst verschijnt.

Kies de correctie voor de bottleneck die u hebt gemeten

Als het bewijs wijst op vroege opstartinitialisatie, kijk dan naar het door het platform ondersteunde seedingpad, dat op een virtuele machine een door de host geleverd willekeurig apparaat kan omvatten. Een seed-image dat ongewijzigd naar veel gasten wordt gekopieerd, vervangt geen onafhankelijke initialisatie.

Als het bewijs wijst op het datapad, stel dan af wat de tellers aanwijzen. Buffergroottes helpen wanneer wachtrijen overlopen en doen niets wanneer één thread verzadigd is. Een entropie-daemon installeren om een teller te verhogen is geen doorvoerreparatie, en seedingaannames wijzigen om een grafiek er beter uit te laten zien ruilt een beveiligingseigenschap voor een getal.

Accepteer de wijziging alleen wanneer dezelfde meting onder dezelfde omstandigheden verbetert. Een grotere teller is geen resultaat; een kortere gemeten wachttijd of een snellere overdracht met een geïdentificeerde oorzaak is dat wel.