VPN pada tijekom velikih prijenosa: prvo pročitajte red čekanja

Tunel je stabilan cijeli dan, a onda padne kad god počne velik prijenos. Interaktivni zahtjevi prvi zastanu, klijent prijavi istek vremena, a veza se vrati kad prijenos završi. Taj obrazac upućuje na red čekanja i obradu, a ne na to da je udaljeni poslužitelj pao, jer poslužitelj nikada nije dobio priliku odgovoriti na vrijeme. Posao je reproducirati to pod kontroliranim opterećenjem i pročitati prave brojače.

Mijenjajte jednu varijablu po pokretanju i držite krajnju točku fiksnom.

Izgradite ponovljivu usporedbu opterećenja

Zabilježite osnovnu liniju dok veza miruje: vrijeme povratnog puta, nekoliko zahtjeva aplikacija i vlastiti dnevnik događaja tunela. Zatim pokrenite prijenos poznate veličine i ponovite točno ta mjerenja dok traje. Držite krajnju točku, klijenta i odredište testa nepromijenjenima, jer promjena dvaju odjednom ne govori ništa.

Zabilježite koji se događaj pojavljuje prvi. Rastuće vrijeme povratnog puta prije ikakve pogreške upućuje na red čekanja; tvrd istek vremena uz stabilnu latenciju upućuje na nešto drugo, poput obnove ključeva ili radnje na računu. Oba obrasca vode različitim sljedećim koracima. Zapišite zapažanje prije nego što bilo što promijenite.

Spremite izlaz s vremenskim oznakama kako bi se opterećeno i mirno pokretanje mogli usporediti red po red.

Čitajte red čekanja, ne brzinu

Potrošačke veze puferiraju pakete u opremi davatelja, a pun izlazni red čekanja odgađa sve, uključujući male kontrolne pakete koji drže tunel na životu. Test brzine koji pokazuje visoku brojku malo govori o tom kašnjenju, zato test u mirovanju prolazi dok zasićena veza pada.

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'

Usporedite brojke latencije pod opterećenjem s onima u mirovanju. Skok s desetaka milisekundi na stotine, bez gubitka paketa, red je čekanja; gubitak uz stabilnu latenciju upućuje na drugu grešku.

Provjerite uređaj i kontrolni put

Kriptiranje i prosljeđivanje troše procesorsko vrijeme, a mali usmjerivač ili prijenosnik ograničen toplinom može ispuštati pakete dok je zauzet. Gledajte ukupno opterećenje, a ne postotak jednog procesa, jer prosljeđivanje u kernelu i obrada prekida ne pojavljuju se tamo gdje ljudi obično gledaju.

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

Istek vremena na klijentu može se poklopiti i s planiranom obnovom ključeva ili s događajem politike sesije. Pročitajte vlastiti dnevnik klijenta za redoslijed događaja, a ne samo poruku o pogrešci aplikacije.

Promijenite jednu stvar i ponovite

Gdje platforma to podržava, ograničite brzinu prijenosa ili razvrstajte masovni promet ispod interaktivnog kako se red čekanja nikad ne bi napunio. Zatim ponovite isti posao i usporedite iste tri brojke kao prije. Promjena koja poboljša test brzine, ali ostavi istek vremena, nije ništa popravila.

Podizanje vremenskih ograničenja u cijelosti i slabljenje kriptiranja dvije su promjene koje uklone simptom bez utvrđivanja koja je granica zakazala. Nijedna nije popravak. Obje pomiču kvar kasnije, gdje ga je teže pripisati.

Završite testom novog zahtjeva i ponašanja ponovnog spajanja na koje se korisnik doista oslanja. Stabilnost pod opterećenjem koje je izazvalo pritužbu jedini je rezultat koji vrijedi zabilježiti.