Bevriezing van twee seconden: was het de VPN of de wifi?
Een hapering van twee seconden en een nieuwe VPN-sessie zijn verschillende gebeurtenissen. Zet het toegangspad en de tunnel op aparte tijdlijnen voordat u een timer wijzigt.
Een bevriezing van twee seconden die vanzelf herstelt, ziet er hetzelfde uit of de tunnel opnieuw heeft onderhandeld of de radio heeft gestotterd. Het is ook mogelijk dat er helemaal niets is weggevallen, en die mogelijkheid is het eerst waard om te testen. Een korte verliespiek, een heronderhandeling en een hapering van een toepassing voelen voor de persoon achter het toetsenbord hetzelfde. Slechts één van de drie gevallen wordt verholpen door de tunnelconfiguratie te wijzigen.
Twee registraties, niet één
Noteer wat er met de verbinding eronder gebeurde, en apart wat de tunnel zelf deed. Leg daarna de pauze van de toepassing naast beide registraties. Dat zijn onafhankelijke reeksen gebeurtenissen die soms samenvallen, en alle drie een onderbreking noemen veronderstelt het antwoord al vanaf het begin.
Een monitor die één keer per minuut peilt, kan een onderbreking van twee seconden niet zien. Die dag als gezond rapporteren is technisch juist en praktisch nutteloos. Zet het meetinterval naast elk resultaat dat u citeert.
Wat de toegangslink deed terwijl de app bevroren was
Het meetinterval en de time-out bepalen wat de monitor überhaupt had kunnen waarnemen, dus noteer beide naast het resultaat. Een geregistreerde afwezigheid van storingen zegt weinig wanneer het instrument elke zestig seconden een meting doet. Peil daarna drie plaatsen met tijdstempels: de lokale router, een goedgekeurde externe host via het gewone pad, en een bron achter de tunnel.
Bevestig eerst de routes, want een openbaar doel kan zelf via de tunnel worden gerouteerd en meet dan de tunnel in plaats van het toegangspad. De bewijzen die de storing echt dateren, liggen een laag lager: linkgebeurtenissen op de router, resynchronisatieregels op het modem en een gewijzigd WAN-adres. Een cumulatieve foutenteller vertelt u dat er iets misging, nooit wanneer. Correleer die registraties met het incidentvenster in plaats van ze geïsoleerd te lezen.
ping -i 0.5 -c 40 192.168.60.1
mtr -rwc 40 203.0.113.25
ip -brief address showEen teller die gisteren steeg, verklaart niets over een bevriezing vanochtend. Beperk de correlatie tot het venster dat de gebruiker meldde.
Zoek de herstartregistratie
Een verloren UDP-datagram zorgt er op zichzelf niet voor dat Community OpenVPN een nieuwe TLS-onderhandeling begint. Herstartgedrag volgt ping-restart, en de geldende waarde kan door de server zijn opgelegd; de handleiding voor 2.6 definieert die timers. De aflevering breekt even, de drempel wordt nooit overschreden en het log blijft leeg. Zoek daarom in het log rond de pauze naar een herstartregel, een nieuwe verbinding of een gewijzigde sessie-identificatie. Als geen van de drie verschijnt, deed de tunnel waarschijnlijk niets en was de timer nooit het probleem.
Elke keepalive inkorten laat de detectie sneller lijken en verschuift de lijn waar een hikje een herverbinding wordt. Elke herverbinding kost een authenticatieronde en herinstallatie van routes. De timer oprekken levert niets op behalve een langer venster waarin een dood pad nog levend lijkt. Beide zijn afstemmingsbeslissingen met een prijs, geen gratis verbeteringen.
Een afwezige gebeurtenis is ook bewijs, en het is precies het soort dat mensen overslaan omdat niets in het log de aandacht erop vestigt. Noteer het onderzoek dat u deed, niet alleen het resultaat.
Laat de vergelijking beslissen wat er moet worden hersteld
Met beide registraties naast elkaar schrijft de toewijzing zich meestal zelf. Een linkgebeurtenis op de router op beide paden betekent dat de toegangsverbinding het onderwerp is. Een stille tunnel en een bruikbaar gewoon pad betekenen dat de onderhandeling het is.
| What you observed | Tunnel log at that second | Where to look next |
|---|---|---|
| two-second pause, plain path answers throughout | nothing | the monitor's resolution, then a loss burst |
| pause plus a router link event, plain path stops and returns | no restart line | the access link, not the tunnel timer |
| pause, then a new session identifier | restart line | the restart threshold and what triggered it |
| one application freezes while both paths answer | nothing | that application and its server-side work |
Elke rij is een aanwijzing, geen vonnis: eindpunten verlagen de prioriteit van ICMP, en twee bestemmingen delen niet noodzakelijk een pad. Houd de klokken van client, gateway en toepassing gelijk zodat de vergelijking überhaupt mogelijk is. Een rij die in twee kolommen past, vraagt om nog een waarneming, niet om een besluit.
Een rapport dat een beoordeling doorstaat, beantwoordt vier dingen: hoe lang de bevriezing duurde, welke paden bleven antwoorden, wat de tunnel in die seconde vastlegde en hoe vaak de monitor meet. Die vier feiten stellen de volgende lezer in staat de waarneming te reproduceren in plaats van een samenvatting te vertrouwen. Een uptimepercentage verbergt precies het interval dat u interesseert, en de zin "de VPN viel" ook.