VPN kopplar från hela tiden: testa radion före servern

En VPN-frånkoppling kan börja långt innan någon trafik når servern. Förlust av Wi-Fi, en övergång från Wi-Fi till mobilnät, trängsel vid den lokala åtkomstpunkten och en telefon som somnar kan alla avbryta den yttre vägen medan tunnelprogramvaran rapporterar ett rent fel. Gå utåt från enheten: först länken, sedan klientens egna händelser, sedan en kontrollerad jämförelse och först därefter servern. Den ordningen hindrar dig från att byta utgångsnoder för ett problem som bor i rummet.

Titta på länken, inte signalikonen

Leta efter länkövergångar i stället för staplar. En enhet kan visa stark signal medan åtkomstpunkten är mättad, medan en roamingövergång pågår eller medan en energisparpolicy parkerar radion när skärmen är av.

Anteckna gränssnittets tillstånd, aktuell gateway och tidpunkten för varje ändring. Kontrollera sedan om frånkopplingen sammanfaller med övergången. Ett avbrott som sker varje gång telefonen flyttas mellan rum är ett länkproblem tills motsatsen bevisats, oavsett vilken server appen visar.

Läs klientens egna återanslutningshändelser

De flesta klienter loggar en orsak till frånkopplingen och en tidsstämpel för nästa försök. En tunnel som förhandlar om inom sekunder och sedan fungerar är en annan händelse än en som ligger nere tills du slår på den manuellt.

Upprepade korta återanslutningar pekar på den yttre vägen, eftersom klienten fortsätter att nå servern och tappa sessionen. En tunnel som ligger nere pekar på autentisering, en ändring av ändpunkt eller en policy, eftersom klienten inte kommer tillräckligt långt för att tappa något. Läs de två mönstren separat innan du rör konfigurationen.

Jämför en andra ändpunkt med omsorg

En andra ändpunkt är en användbar jämförelse och är inte i sig ett kontrollerat experiment. Den ändrar rutten, infrastrukturen och ofta landet, så en skillnad mellan två ändpunkter bevisar inte att den första servern är defekt.

Håll enheten, åtkomstnätet och arbetsbelastningen oförändrade och anteckna vad annat som ändrades när du bytte. Om båda ändpunkterna misslyckas samtidigt på samma plats är den lokala vägen den gemensamma faktorn. Om bara en misslyckas blir servern eller rutten dit spåret. Skriv ner störningsfaktorerna så att slutsatsen inte springer före bevisen.

Korrelatera med servern du driver

Om du administrerar ändpunkten, matcha försökstiden mot lyssnar- och associationsloggar. Flera oberoende klienter som misslyckas på samma gateway är ett annat bevis än en telefon som faller ur varje gång den flyttas.

Ett enda peer-svar fastställer inte bestående applikationshälsa. Testa efter återställning den resurs du faktiskt behöver, eftersom ett lyckat handskakning och en nåbar server kan samexistera med en trasig applikationsväg.

Skriv rapporten som snävar in det

Separera fyra påståenden: lokalt länktapp, yttre nåbarhet, tunneleförhandling och applikationens eget tillstånd. Var och en har sina egna bevis, och en rapport som håller dem åtskilda talar om för nästa person var den ska titta.

Anteckna också jämförelsens begränsningar. Om en policy hindrade ett test av den direkta vägen, säg det i stället för att presentera ändpunktsjämförelsen som bevis. Landsetiketten i appen identifierar inte hela rutten, och en server som ligger geografiskt nära kan fortfarande nås via en överbelastad väg.

WireGuard-projektets sida om kända begränsningar är en nyttig påminnelse om att ett protokoll kan vara korrekt och ändå lämna länkbeteendet till operativsystemet. Avsluta med att upprepa samma test efter nästa frånkoppling, eftersom en enskild händelse är en datapunkt och ett mönster är en diagnos.