VPN-tsjinnerbelesting ferklearre: brûkers, CPU of opkanaal?

In poarte op in belesting fan 0.4 kin noch foar elke brûker efter him krûpe. De gemiddelde belesting telt taken dy’t útfierber binne of fêst sitte yn ûnûnderbrutsen sliep, en op in host mei fjouwer kearnen is ien fersadige proses genôch om it nei 1.0 te triuwen wylst trije kearnen ferfeeld sitte. Dat getal as oerskot lêze is de meast foarkommende flater by it kiezen fan in einpunt. Wat in tunnel echt beheint is meastentiids ien fan fjouwer dingen: ien drok kearn, it opkanaal, de wachtrige derfoar of in belied per sesje dat nimmen dokumintearre hat.

Gemiddelde belesting telt taken, net trochstream

De kernel nimt monsters fan de útfierrige en it oantal taken dat op ynfier en útfier wachtet, en glêdet beide dêrnei oer ien, fiif en fyftjin minuten. Neat yn dy definysje neamt bytes, pakketten of tunnels. In host waans opslach fêst sitten is kin in hege belesting melde mei hast gjin ferkear, en in host dy’t in gigabit troch in kerneldatapaad triuwt kin in noflike melde.

Belesting korrelearje mei tunnelprestaasjes freget dus in each per kearn. As ien kearn folslein beset is, sil it totale persintaazje op in dashboard der noch goed útsjen:

cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20

It tredde kommando is itjinge dat it meast telt op VPN-hosts. Pakketferwurking yn brûkersromte yn OpenVPN 2.x is foar in grut part serialisearre per proses, sadat ien beset tried it plafond wurde kin wylst it dashboard oerfloedige frije kapasiteit meldt. As ien tried it grutste part fan in kearn hâldt yn jo stadige perioade, is de host net yn it gehiel ûnderbemjitte; hy is beheind yn de diminsje dy’t tafallich telt.

Let ek op de timing. Gemiddelden oer fyftjin minuten ferbergje de útbarsting dy’t in oprop ferpeste, dus in skermôfdruk nommen nei de klacht is swak bewiis. Nim monsters ûnder it probleem, en hâld de tiidstempel by de útfier.

It opkanaal en de wachtrige derfoar

Interface-tellers beantwurdzje de fraach oer bânbreedte dy’t CPU-sifers net kinne. Se skiede ek kapasiteit fan ferlies, en dat binne ferskillende fouten mei ferskillende oplossings:

ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit

In ferbining dy’t by jo test ticht by syn tawiisde faasje is, is de ferklearring, en gjin hoemannichte frije CPU feroaret dat. De qdisc-regel foeget it detail ta dat foar ynteraktyf ferkear telt: efterstân en ferliezen fertelle jo oft pakketten yn in rige wachtsje foardat se fuortgeane. In rige dy’t fol rekket ûnder in grutte oplaad produsearret krekt it symptoom dat minsken de fiere tsjinner ferwite, nammentlik trage oproppen op in ferbining dy’t yn benchmarks noch goed docht.

Weromstjoertellers fange it gefal wêryn pakketten fuortgeane mar nea skjin oankomme. As weromstjoeringen yn it stadige finster omheech geane en de interface fier fan kapasiteit is, wennet it probleem yn it paad en net op de host, en ferhúzje nei in oar einpunt yn deselde stêd sil net helpe.

Sesjetellingen beskriuwe fraach, net oerskot

Elk iepenbier register toant wat oantal ferbûne brûkers, en hast gjinien fan har fertelt jo wat dy brûkers dogge. Tweintich sesjes mei ynteraktyf wurk en fjouwer sesjes dy’t grutte bestannen lûke, meitsje hiel ferskillende belestings op deselde hardware. It twadde patroan is ûnsichtber yn in brûkerstelling, en dat is dejinge dy’t in jûn ferpestet. Sa wurdt in sesjegetal it bêste lêzen as in hint oer fraach, nea as in bewearing oer frije kapasiteit.

Op in host dy’t jo beheare, jout it statusbestân de ûntbrekkende diminsje. OpenVPN skriuwt in periodyk momintbyld dat tellers per klant befettet, en dat is genôch om te sjen oft ien sesje ferantwurdlik is foar it hiele opkanaal:

status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.status

Twa monsters tsien sekonden útinoar feroarje dy kumulatives yn in faasje per klant. Dat is de mjitting dy’t in brûkerstelling ferfangt, en sa ûntdekke jo ek dat ien ferkeard konfigurearre klant de keppeling elke nacht op itselde oere fersadiget.

Limiten per sesje ferskûlje har yn belied

In tsjinner kin idle wêze en jo dochs bânbreedte wegerje. Faasjelimiten, bânbreedteplafonds per klant en ferkearsfoarming wurde faak per mienskiplike namme of per pool tapast, sadat twa brûkers op deselde poarte hiel ferskillende resultaten krije kinne. It meganisme is net subtyl, mar it is fan bûten ôf ûnsichtber om’t de tunnel yn beide gefallen normaal omheech komt.

Sjoch foar foarming op de tunnelinterface ynstee fan op de fysike. Kontrolearje oft de limyt de brûker, it sertifikaat of de adrespool folget. As jo testaccount yn de pool sûnder plafond falt, sille jo konkludearje dat de tsjinner goed is en de klagende brûker mis is. Dy konklúzje is slimmer as gjin konklúzje, om’t er it ticket slút.

Fergelykje twa einpunten mei ien fêste taak

It eksperimint oan klantkant is noch altyd de muoite wurdich, mar allinnich as de fariabelen fêstset binne. Brûk itselde apparaat, itselde tagongsnetwurk, itselde protokol en itselde bestimmingsbestân, en werhelje it dan tsjin in twadde einpunt op in ferlykbere ôfstân. Alles dat tusken runs feroaret, ynklusyf it oere fan de dei, fersmoarget it resultaat.

Skriuw mislearrings like soarchfâldich op as súksessen. In searje wêryn trije einpunten wurkje en ien tiid útrint is ynformativer as fjouwer faasjesifers, om’t er op in paad- of beliedsprobleem wiist ynstee fan in kapasiteitsprobleem. Rin elke kwestje op syn minst twa kear; ien stadich monster bewiist neat op in dield netwurk.

Ta beslút, hâld de sifers dy’t jo sammele hawwe by de bewearing dy’t se stypje. "Dit einpunt die de oerdracht yn itselde finster wêryn it oare fêst rûn" is ferdigenber, wylst "dit einpunt is flugger" in diskusje útnoadiget dy’t jo net winne kinne mei in startside-skoare. It hânboek fan OpenVPN 2.6 dokumintearret it statusbestân en de foarmingsopsjes as jo de krekte rjochtlinen foar de hostkant nedich hawwe.