VPN valt steeds weg: test eerst de radio, dan de server

Een VPN-verbreking kan lang beginnen voordat er ook maar enig verkeer de server bereikt. Wi-Fi-verlies, een overgang van Wi-Fi naar mobiel, drukte op het lokale toegangspunt en een telefoon die in slaap valt kunnen allemaal het buitenste pad onderbreken terwijl de tunnelssoftware een schone fout meldt. Ga van het apparaat naar buiten: eerst de link, dan de gebeurtenissen van de client zelf, dan een gecontroleerde vergelijking en pas daarna de server. Die volgorde houdt je ervan af uitgangsknooppunten te wisselen voor een probleem dat in de kamer woont.

Let op de link, niet op het signaalpictogram

Let op linkovergangen in plaats van balkjes. Een apparaat kan een sterk signaal tonen terwijl het toegangspunt verzadigd is, terwijl een roaming-overgang bezig is of terwijl een energiebesparingsbeleid de radio parkeert bij een uitgeschakeld scherm.

Noteer de toestand van de interface, de huidige gateway en het tijdstip van elke wijziging. Controleer daarna of de verbreking samenvalt met de overgang. Een uitval die elke keer gebeurt wanneer de telefoon tussen kamers beweegt, is een linkprobleem tot het tegendeel bewezen is, ongeacht welke server de app toont.

Lees de herverbindingsgebeurtenissen van de client

De meeste clients loggen een reden voor de verbreking en een tijdstempel voor de volgende poging. Een tunnel die binnen seconden opnieuw onderhandelt en daarna werkt, is een andere gebeurtenis dan een die omlaag blijft tot je hem handmatig aanzet.

Herhaalde korte herverbindingen wijzen op het buitenste pad, omdat de client de server blijft bereiken en de sessie verliest. Een tunnel die omlaag blijft, wijst op authenticatie, een wijziging van eindpunt of een beleid, omdat de client niet ver genoeg komt om iets te verliezen. Lees de twee patronen apart voordat je de configuratie aanraakt.

Vergelijk een tweede eindpunt zorgvuldig

Een tweede eindpunt is een nuttige vergelijking en is op zichzelf geen gecontroleerd experiment. Het verandert de route, de infrastructuur en vaak het land, dus een verschil tussen twee eindpunten bewijst niet dat de eerste server defect is.

Houd het apparaat, het toegangsnetwerk en de werklast vast en noteer wat er nog meer veranderde toen je wisselde. Als beide eindpunten op hetzelfde moment op dezelfde plek falen, is het lokale pad de gemeenschappelijke factor. Als er maar één faalt, wordt de server of de route ernaartoe het spoor. Schrijf de verstorende factoren op zodat de conclusie de bewijzen niet vooruitloopt.

Correleer met de server die je beheert

Als je het eindpunt beheert, vergelijk dan het pogingstijdstip met listener- en associatieregistraties. Meerdere onafhankelijke clients die op dezelfde gateway falen, zijn ander bewijs dan één telefoon die uitvalt telkens wanneer hij beweegt.

Eén peer-antwoord stelt geen aanhoudende gezondheid van de applicatie vast. Test na herstel de bron die je echt nodig hebt, want een geslaagde handshake en een bereikbare server kunnen samengaan met een kapot applicatiepad.

Schrijf het rapport dat het vernauwt

Scheid vier uitspraken: lokaal linkverlies, externe bereikbaarheid, tunnelonderhandeling en de eigen toestand van de applicatie. Elk heeft zijn eigen bewijs, en een rapport dat ze gescheiden houdt, vertelt de volgende persoon waar die moet kijken.

Noteer ook de beperkingen van de vergelijking. Als beleid een test van het directe pad verhinderde, zeg dat dan in plaats van de eindpuntvergelijking als bewijs te presenteren. Het landlabel in de app identificeert niet de volledige route, en een geografisch nabije server kan nog steeds via een overbelast pad worden bereikt.

De pagina met bekende beperkingen van het WireGuard-project is een nuttige herinnering dat een protocol correct kan zijn en toch linkgedrag aan het besturingssysteem overlaat. Sluit af met dezelfde test te herhalen na de volgende verbreking, want één gebeurtenis is een datapunt en een patroon is een diagnose.