VPN falas dum grandaj alŝutoj: unue legu la atendovicon

La tunelo estas stabila la tutan tagon kaj poste falas ĉiam, kiam komenciĝas granda alŝuto. Interagaj petoj unue haltas, la kliento raportas tempolimon, kaj la konekto revenas kiam la transigo finiĝas. Tiu ŝablono montras atendovicon kaj prilaboradon, ne falintan foran servilon, ĉar la servilo neniam ricevis la ŝancon respondi ĝustatempe. La tasko estas reprodukti tion sub regata ŝarĝo kaj legi la ĝustajn nombrilojn.

Ŝanĝu unu variablon por ĉiu rultempo kaj tenu la finpunkton senŝanĝa.

Konstruu ripeteblan komparon de ŝarĝo

Registru bazlinion dum la ligilo estas senokupa: rondiran tempon, kelkajn aplikaĵajn petojn kaj la propran eventoprotokolon de la tunelo. Poste komencu alŝuton de konata grandeco kaj ripetu ĝuste tiujn mezurojn dum ĝi funkcias. Tenu la finpunkton, la klienton kaj la testan celon senŝanĝaj, ĉar ŝanĝi du el ili samtempe diras al vi nenion.

Rimarku, kiu evento aperas unue. Kreskanta rondira tempo antaŭ iu ajn eraro sugestas atendovicon; firma tempolimo kun stabila latenteco sugestas ion alian, ekzemple ŝlosilŝanĝon aŭ agon pri la konto. La du ŝablonoj kondukas al malsamaj sekvaj paŝoj. Skribu la observon antaŭ ol ŝanĝi ion ajn.

Konservu la eligon kun tempomarkoj, por ke la ŝarĝita kaj la senokupa rultempoj povu esti komparitaj linio post linio.

Legu la atendovicon, ne la rapidon

Konsumantaj ligiloj bufras pakojn en la ekipaĵo de la provizanto, kaj plena suprena atendovico malfruigas ĉion, inkluzive la malgrandajn regajn pakojn, kiuj tenas tunelon viva. Rapidtesto, kiu montras altan nombron, diras malmulte pri tiu malfruo, kaj tial senokupa rapidtesto sukcesas dum satigita ligilo malsukcesas.

ping -c 20 -i 0.2 203.0.113.10
mtr -rwc 20 203.0.113.10
tc -s qdisc show dev eth0
ss -ti dst 203.0.113.10
nstat -az | grep -E 'Retrans|Timeout'

Komparu la latentecajn nombrojn sub ŝarĝo kun tiuj de senokupo. Salto de dekoj da milisekundoj al centoj, sen pakoperdo, estas atendovico; perdo kun stabila latenteco montras alian difekton.

Kontrolu la aparaton kaj la regan vojon

Ĉifrado kaj plusendado kostas procesoran tempon, kaj malgranda enkursigilo aŭ varme limigita tekkomputilo povas perdi pakojn dum ĝi estas okupata. Rigardu la totalan ŝarĝon anstataŭ la procenton de unu procezo, ĉar plusendado en la kerno kaj traktado de interrompoj ne aperas tie, kie homoj kutime rigardas.

uptime
mpstat -P ALL 1 3
dmesg | grep -i -E 'thermal|throttl'
journalctl -u openvpn-server@server --since '10 min ago' | tail -20

Klienta tempolimo ankaŭ povas koincidi kun planita ŝlosilŝanĝo aŭ kun evento de sesia politiko. Legu la propran protokolon de la kliento por la ordo de eventoj, ne nur la erarmesaĝon de la aplikaĵo.

Ŝanĝu unu aferon kaj ripetu

Kie la platformo subtenas tion, limigu la alŝutan rapidon aŭ klasifiku amasan trafikon sub la interaga trafiko, por ke la atendovico neniam pleniĝu. Poste ripetu la saman laborŝarĝon kaj komparu la samajn tri nombrojn kiel antaŭe. Ŝanĝo, kiu plibonigas rapidteston sed lasas la tempolimon, riparis nenion.

Levi tempolimojn ĉie kaj malfortigi ĉifradon estas la du ŝanĝoj, kiuj igas la simpton malaperi sen identigi la limon, kiu malsukcesis. Neniu el ili estas riparo. Ambaŭ movas la malsukceson pli posten, kie estas pli malfacile atribui ĝin.

Finu per testo de nova peto kaj de la rekonekta konduto, sur kiu la uzanto vere dependas. Stabileco sub la ŝarĝo, kiu kaŭzis la plendon, estas la sola rezulto inda je registro.