Är låg VPN-genomströmning ett entropiproblem? Vanligtvis inte

Låg genomströmning genom en tunnel och en maskin som hänger sig i väntan på slumptal ger mycket olika upplevelser, men de registreras ändå under samma klagomål. Den ena visar sig som en paus innan något fungerar. Den andra visar sig som en anslutning som fungerar och flyttar data långsamt så länge du tittar på. Att avgöra vilken du har tar tio minuter och sparar en vecka av gissningar.

Två symtom som ser likadana ut

En tjänst som hänger sig efter en färsk start, innan den accepterar en enda anslutning, väntar på något. En tunnel som etableras snabbt och sedan överför med en bråkdel av den förväntade hastigheten begränsas av något annat. Ordet kryptering dyker upp i båda historierna, och därför slås de ihop. Separera dem innan du rör en konfigurationsfil.

Sätt tidsstämplar runt start, autentisering, omförhandling av nycklar och själva överföringen. En lång fördröjning innan tunneln är användbar är inte en låg jämn hastighet, och att medelvärdesbilda de två till ett tal förstör beviset.

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

De två första kommandona sätter startarbetet på en tidslinje. Det tredje skriver ut kärnans entropiredovisningsvärde, som är användbart som en enda datapunkt och oanvändbart som bandbreddsmätare.

Hur en väntan på slumptal faktiskt ser ut

En begäran om säkra slumpmässiga byte kan blockera tills kärnan har initierat sin slumptalskälla. Det spelar störst roll på virtuella maskiner och små inbyggda kort tidigt i starten, när lite miljöbrus har samlats in. Det följer inte att varje krypterad byte förbrukar färsk entropi.

Moderna generatorer seedas en gång och producerar sedan utdata från en deterministisk konstruktion, och reseedar enligt sitt eget schema. Bulköverföring tömmer inte en pool byte för byte, så ett lågt poolvärde under en långsam överföring bevisar ingenting om orsaken.

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

Det första kommandot visar om processen sitter i ett slumptalsanrop medan du tittar. Det andra visar kärnans egna initieringsmeddelanden, och det är där en tidig startfördröjning blir synlig.

Notera kärnversionen och biblioteket som tjänsten faktiskt länkar mot, eftersom beteendet skiljer sig mellan implementationer och mellan utgåvor. Ett trace som tas efter återställning missar vanligtvis pausen helt.

Hur ihållande långsamhet faktiskt ser ut

En tunnel som överför långsamt hela tiden begränsas av datavägen. En mättad tråd, förlust av yttre paket, omsändningar eller fulla socketköer producerar var och en det mönstret, och var och en har sin egen åtgärd. Aggregerad CPU-procent döljer en enda upptagen tråd, och det är den vanligaste felläsningen. Titta på tid per tråd innan du tittar på den totala belastningen.

Mät i båda riktningarna med en jämförbar baslinje, och följ gränssnittets räknare i stället för programmets egen rapport.

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

Det första kommandot visar kö- och överbelastningstillstånd för en peer. Det andra och tredje rapporterar droppar och omsändningar i stacken och på gränssnittet, där orsaken vanligtvis dyker upp först.

Välj åtgärden för den flaskhals du mätte

Om bevisen pekar på tidig startinitiering, titta på plattformens stödda seedningsväg, som på en virtuell maskin kan omfatta en värdslevererad slumptalsenhet. En seed-bild som kopieras oförändrad till många gäster ersätter inte en oberoende initiering.

Om bevisen pekar på datavägen, justera det som räknarna pekar på. Buffertstorlekar hjälper när köer svämmar över och gör ingenting när en tråd är mättad. Att installera en entropidaemon för att höja en räknare är ingen genomströmningsreparation, och att ändra seedningsantaganden för att få en graf att se bättre ut byter en säkerhetsegenskap mot ett tal.

Acceptera ändringen bara när samma mätning förbättras under samma förhållanden. En större räknare är inte ett resultat; en kortare uppmätt väntan eller en snabbare överföring med identifierad orsak är det.