Dvousekundové zamrznutí: VPN, nebo Wi-Fi?

Zamrznutí na dvě sekundy, které se samo spraví, vypadá stejně, ať už tunel znovu vyjednal, nebo radiové rozhraní zakoktalo. Je také možné, že vůbec nic nespadlo, a tuto možnost stojí za to vyzkoušet jako první. Krátký výpad v podobě ztrát, nové vyjednání a zaseknutí aplikace působí na člověka u klávesnice stejně. Jen jeden ze tří případů se řeší úpravou konfigurace tunelu.

Dva záznamy, ne jeden

Zapište, co se stalo se spojením pod tím, a zvlášť, co udělal samotný tunel. Pak postavte pauzu aplikace proti oběma záznamům. Jsou to nezávislé řady událostí, které se někdy překrývají, a nazvat všechny tři odpojením znamená předpokládat odpověď hned na začátku.

Monitor, který testuje jednou za minutu, nemůže dvousekundové přerušení vidět. Hlásit ten den jako zdravý je technicky přesné a prakticky k ničemu. Uvádějte interval vzorkování vedle každého výsledku, který citujete.

Co dělala přístupová linka, když aplikace zamrzla

Interval vzorkování a časový limit určují, co mohl monitor vůbec pozorovat, proto zaznamenejte obojí vedle výsledku. Zaznamenaná nepřítomnost výpadků málo znamená, když přístroj vzorkuje každých šedesát sekund. Potom otestujte tři místa s časovými značkami: místní router, schválený vnější host dosažený po prosté cestě a zdroj za tunelem.

Nejprve potvrďte trasy, protože veřejný cíl může sám být směrován tunelem a pak měří tunel, ne přístupovou cestu. Důkazy, které výpadek skutečně datují, leží o vrstvu níž: události linky na routeru, záznamy o resynchronizaci na modemu a změněná adresa WAN. Kumulativní čítač chyb vám řekne, že se něco pokazilo, nikdy kdy. Propojte tyto záznamy s oknem incidentu, místo abyste je četli izolovaně.

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

Čítač, který včera stoupl, nevysvětluje nic o dnešním ranním zamrznutí. Ohraničte korelaci oknem, které uživatel nahlásil.

Hledejte záznam o restartu

Ztracený datagram UDP sám o sobě nezpůsobí, že Community OpenVPN zahájí nové vyjednávání TLS. Chování restartu se řídí ping-restart a platná hodnota mohla být vnucena serverem; příručka pro 2.6 tyto časovače definuje. Doručování se na okamžik přeruší, prahu se nikdy nedosáhne a protokol zůstane prázdný. Proto hledejte v protokolu kolem pauzy řádek o restartu, nové připojení nebo změněný identifikátor relace. Pokud se neobjeví nic z toho, tunel pravděpodobně nic nedělal a časovač nikdy nebyl problém.

Zkrácení každého keepalive dělá detekci zdánlivě rychlejší a posouvá hranici, kde se krátký výpadek stává opětovným připojením. Každé opětovné připojení stojí jedno kolo autentizace a reinstalaci tras. Prodloužení časovače nekoupí nic než delší okno, ve kterém mrtvá cesta ještě vypadá živě. Obojí jsou rozhodnutí o ladění s cenou, ne bezplatná vylepšení.

Chybějící událost je také důkaz, a to právě ten druh, který lidé přeskakují, protože na něj v protokolu nic neupozorňuje. Zaznamenejte hledání, které jste provedli, ne jen jeho výsledek.

Nechte srovnání rozhodnout, co opravit

Když jsou oba záznamy vedle sebe, přiřazení se obvykle napíše samo. Událost linky routeru na obou cestách znamená, že tématem je přístupové spojení. Tichý tunel a použitelná prostá cesta znamenají, že tématem je vyjednávání.

Každý řádek je stopa, ne rozsudek: koncové body snižují prioritu ICMP a dvě destinace nutně nesdílejí jednu cestu. Udržujte hodiny klienta, brány a aplikace srovnané, aby srovnání vůbec bylo možné. Řádek, který sedí do dvou sloupců, potřebuje další pozorování, ne rozhodnutí.

Zpráva, která projde kontrolou, odpovídá na čtyři věci: jak dlouho zamrznutí trvalo, které cesty dál odpovídaly, co tunel v tu sekundu zalogoval a jak často monitor vzorkuje. Tyto čtyři údaje umožní dalšímu čtenáři pozorování zopakovat, místo aby věřil shrnutí. Procento dostupnosti skrývá právě ten interval, který vás zajímá, a stejně tak fráze "VPN spadla".