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

Tunel je stabilan cijeli dan, a onda padne kad god počne veliki prijenos. Interaktivni zahtjevi prvi zastanu, klijent prijavi istek vremena, a veza se vrati kad se prijenos završi. Taj obrazac upućuje na red čekanja i obradu, a ne na to da je udaljeni server pao, jer server nikada nije dobio priliku da na vrijeme odgovori. 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 ponovljivo poređenje 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, klijent 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 greš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 uporediti 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'

Uporedite 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 greš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 uporedite 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. Ni jedna 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.