Dvosekundni zastoj: VPN ali Wi-Fi?

Zastoj za dve sekundi, ki se sam popravi, izgleda enako, ne glede na to, ali je tunel znova izpogajal ali se je radio spotaknil. Možno je tudi, da ni padlo nič, in to možnost je vredno preizkusiti najprej. Kratek izbruh izgub, ponovno pogajanje in zastoj aplikacije se osebi za tipkovnico občutijo enako. Samo eden od treh primerov se odpravi s spremembo konfiguracije tunela.

Dva zapisa, ne eden

Zapišite, kaj se je zgodilo s povezavo spodaj, in ločeno, kaj je naredil sam tunel. Nato postavite premor aplikacije oba zapisa. To so neodvisne vrste dogodkov, ki se včasih prekrivajo, in če vse tri imenujete prekinitev, odgovor domnevate že na začetku.

Monitor, ki preverja enkrat na minuto, ne more videti prekinitve za dve sekundi. Poročati, da je bil tisti dan zdrav, je tehnično pravilno in praktično neuporabno. Ob vsak citiran rezultat postavite interval vzorčenja.

Kaj je počela dostopna povezava, medtem ko je aplikacija obstala

Interval vzorčenja in časovna omejitev določata, kaj bi monitor sploh lahko opazil, zato oba zapišite ob rezultat. Zabeležena odsotnost prekinitev malo pomeni, ko instrument vzorči vsakih šestdeset sekund. Nato preverite tri mesta s časovnimi žigi: lokalni usmerjevalnik, odobren zunanji gostitelj, dosegljiv po preprosti poti, in vir za tunelom.

Najprej potrdite poti, ker je javni cilj lahko sam usmerjen skozi tunel in potem meri tunel namesto dostopne poti. Dokazi, ki res datirajo prekinitev, ležijo plast nižje: dogodki povezave na usmerjevalniku, zapisi o ponovni sinhronizaciji na modemu in spremenjen naslov WAN. Kumulativni števec napak pove, da je šlo nekaj narobe, nikoli kdaj. Te zapise povežite z oknom dogodka, namesto da jih berete izolirano.

ping -i 0.5 -c 40 192.168.60.1
mtr -rwc 40 203.0.113.25
ip -brief address show

Števec, ki je včeraj narasel, ne pojasni ničesar o današnjem jutranjem zastoju. Korelacijo omejite na okno, ki ga je uporabnik prijavil.

Poiščite zapis o ponovnem zagonu

Izgubljeni datagram UDP sam po sebi ne povzroči, da bi Community OpenVPN začel novo pogajanje TLS. Vedenje ob ponovnem zagonu sledi ping-restart, veljavna vrednost pa je lahko bila vsiljena s strežnika; priročnik za 2.6 določa te časovnike. Dostava se za trenutek prekine, prag ni nikoli presežen in dnevnik ostane prazen. Zato v dnevniku okoli premora poiščite vrstico o ponovnem zagonu, novo povezavo ali spremenjeni identifikator seje. Če se ne pojavi nobena od treh, tunel verjetno ni storil ničesar in časovnik nikoli ni bil težava.

Krajšanje vsakega keepalive naredi zaznavanje videti hitrejše in premakne mejo, kjer majhen zatikanec postane ponovna povezava. Vsaka ponovna povezava stane en krog overjanja in ponovno namestitev poti. Raztegovanje časovnika ne kupi ničesar razen daljšega okna, v katerem je mrtva pot še videti živa. Oboje so odločitve o nastavitvi s ceno, ne brezplačne izboljšave.

Tudi odsoten dogodek je dokaz, in to prav tiste vrste, ki jo ljudje izpustijo, ker v dnevniku nič ne opozori nanj. Zapišite iskanje, ki ste ga izvedli, ne le njegovega rezultata.

Naj primerjava odloči, kaj popraviti

Ko sta oba zapisa drug ob drugem, se dodelitev običajno napiše sama. Dogodek povezave na usmerjevalniku na obeh poteh pomeni, da je tema dostopna povezava. Tih tunel in uporabna preprosta pot pomenita, da je tema pogajanje.

Vsaka vrstica je sled, ne razsodba: končne točke znižajo prednost ICMP, in dva cilja si ne delita nujno iste poti. Ure odjemalca, prehoda in aplikacije naj bodo usklajene, da bo primerjava sploh mogoča. Vrstica, ki se prilega dvema stolpcema, potrebuje še eno opazovanje, ne odločitve.

Poročilo, ki prestane pregled, odgovori na štiri stvari: kako dolgo je zastoj trajal, katere poti so še naprej odgovarjale, kaj je tunel zabeležil v tisti sekundi in kako pogosto monitor vzorči. Ta štiri dejstva omogočijo naslednjemu bralcu, da opazovanje ponovi, namesto da bi zaupal povzetku. Odstotek delovanja skrije točno tisti interval, ki vas zanima, in tudi besedna zveza "VPN je padel".