Er låg VPN-gjennomstrøyming eit entropiproblem? Vanlegvis ikkje

Låg gjennomstrøyming gjennom ein tunnel og ein maskin som heng og ventar på tilfeldige tal gjev svært ulike opplevingar, men dei vert likevel registrerte under same klage. Det eine viser seg som ein pause før noko verkar. Det andre viser seg som eit samband som verkar og flyttar data sakte så lenge du ser på. Å avgjere kva du har tek ti minutt og sparer ei veke med gjetting.

To symptom som ser like ut

Ein teneste som heng etter ein fersk oppstart, før ho godtek eit einaste samband, ventar på noko. Ein tunnel som vert etablert raskt og deretter overfører med ein brøkdel av forventa hastigheit, vert avgrensa av noko anna. Ordet kryptering dukkar opp i begge historiene, og difor vert dei slått saman. Skil dei før du rører ei konfigurasjonsfil.

Set tidsstempel rundt oppstart, autentisering, ny forhandling av nøklar og sjølve overføringa. Ei lang forseinking før tunnelen er brukbar er ikkje ein låg jamn hastigheit, og å ta gjennomsnittet av dei to til eitt tal øydelegg beviset.

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

Dei to første kommandoane set oppstartsarbeidet på ei tidslinje. Den tredje skriv ut entropirekneskapsverdien til kjernen, som er nyttig som eitt datapunkt og ubrukeleg som bandbreiddemålar.

Korleis ein venting på tilfeldige tal faktisk ser ut

Ei førespurnad om trygge tilfeldige byte kan blokkere til kjernen har initialisert den tilfeldige kjelda si. Det betyr mest på virtuelle maskinar og små innebygde kort tidleg i oppstarten, når lite miljøstøy er samla. Det følgjer ikkje at kvar kryptert byte brukar fersk entropi.

Moderne generatorar vert seeda éin gong og produserer deretter utdata frå ein deterministisk konstruksjon, og reseedar etter sin eigen plan. Bulkoverføring tømmer ikkje ein pool byte for byte, så ein låg poolverdi under ei treg overføring beviser ingenting om årsaka.

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

Den første kommandoen viser om prosessen sit i eit tilfeldigtal-kall medan du ser på. Den andre viser dei eigne initialiseringsmeldingane til kjernen, og det er der ein tidleg oppstartsstopp vert synleg.

Noter kjerneversjonen og biblioteket tenesta faktisk lenkjer mot, fordi åtferda varierer mellom implementasjonar og mellom utgivingar. Eit trace teke etter gjenoppretting misser vanlegvis pausen heilt.

Korleis vedvarande treigheit faktisk ser ut

Ein tunnel som overfører sakte heile tida, vert avgrensa av datastien. Éin metta tråd, tap av ytre pakkar, retransmisjonar eller fulle socketkøar produserer kvar det mønsteret, og kvar har si eiga retting. Samla CPU-prosent skjuler éin oppteken tråd, og det er den vanlegaste feillesinga. Sjå på tid per tråd før du ser på total belastning.

Mål i begge retningar med ei samanliknbar grunnlinje, og følg med på teljarane til grensesnittet i staden for rapporten til applikasjonen sjølv.

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

Den første kommandoen viser kø- og overbelastningstilstand for éin peer. Den andre og tredje rapporterer dropp og retransmisjonar i stakken og på grensesnittet, der årsaka vanlegvis dukkar opp først.

Vel rettinga for flaskehalsen du målte

Viss bevisa peikar på tidleg oppstartsinitialisering, sjå på den støtta seeding-stien til plattformen, som på ein virtuell maskin kan omfatte ein vertslevert tilfeldig eining. Eit seed-bilete kopiert uendra til mange gjester er ikkje ei erstatning for uavhengig initialisering.

Viss bevisa peikar på datastien, juster det teljarane peikar på. Bufferstorleikar hjelper når køar flyt over, og gjer ingenting når éin tråd er metta. Å installere ein entropi-demon for å heve ein teljar er ingen gjennomstrøymingsreparasjon, og å endre seeding-føresetnader for å få ein graf til å sjå betre ut byter ein tryggleikseigenskap mot eit tal.

Godta endringa berre når same måling vert betre under same tilhøve. Ein større teljar er ikkje eit resultat; ei kortare målt ventetid eller ei raskare overføring med identifisert årsak er det.