VPN kobler stadig fra: test radioen før serveren

En VPN-frakobling kan begynne lenge før noen trafikk når serveren. Tap av Wi-Fi, en overgang fra Wi-Fi til mobilnett, trengsel på det lokale aksesspunktet og en telefon som sovner kan alle avbryte den ytre veien mens tunnelprogramvaren rapporterer en ren feil. Gå utover fra enheten: først lenken, deretter klientens egne hendelser, deretter en kontrollert sammenligning og først til slutt serveren. Den rekkefølgen holder deg fra å bytte utgangsnoder for et problem som bor i rommet.

Følg med på lenken, ikke signalikonet

Se etter lenkeoverganger i stedet for søyler. En enhet kan vise et sterkt signal mens aksesspunktet er mettet, mens en roaming-overgang pågår eller mens en strømsparepolicy parkerer radioen når skjermen er av.

Noter grensesnittets tilstand, gjeldende gateway og tidspunktet for hver endring. Sjekk deretter om frakoblingen sammenfaller med overgangen. Et utfall som skjer hver gang telefonen flyttes mellom rom, er et lenkeproblem til det motsatte er bevist, uansett hvilken server appen viser.

Les klientens egne gjenoppkoblingshendelser

De fleste klienter logger en årsak til frakoblingen og et tidsstempel for neste forsøk. En tunnel som forhandler på nytt i løpet av sekunder og deretter virker, er en annen hendelse enn en som blir liggende nede til du slår den på manuelt.

Gjentatte korte gjenoppkoblinger peker på den ytre veien, fordi klienten fortsetter å nå serveren og miste økten. En tunnel som blir liggende nede, peker på autentisering, en endring av endepunkt eller en policy, fordi klienten ikke kommer langt nok til å miste noe. Les de to mønstrene hver for seg før du rører konfigurasjonen.

Sammenlign et annet endepunkt med omhu

Et annet endepunkt er en nyttig sammenligning og er ikke i seg selv et kontrollert eksperiment. Det endrer ruten, infrastrukturen og ofte landet, så en forskjell mellom to endepunkter beviser ikke at den første serveren er defekt.

Hold enheten, aksessnettet og arbeidsbelastningen fast og noter hva annet som endret seg da du byttet. Hvis begge endepunktene feiler samtidig på samme sted, er den lokale veien den felles faktoren. Hvis bare ett feiler, blir serveren eller ruten dit sporet. Skriv ned forstyrrelsesfaktorene så konklusjonen ikke løper fra bevisene.

Korrelér med serveren du driver

Hvis du administrerer endepunktet, samsvar forsøkstidspunktet med lytter- og assosiasjonslogger. Flere uavhengige klienter som feiler på samme gateway, er et annet bevis enn én telefon som faller ut hver gang den flyttes.

Ett peer-svar fastslår ikke vedvarende applikasjonshelse. Test etter gjenoppretting ressursen du faktisk trenger, fordi et vellykket håndtrykk og en tilgjengelig server kan eksistere sammen med en ødelagt applikasjonsvei.

Skriv rapporten som snevrer det inn

Skill fire utsagn: lokalt lenketap, ytre tilgjengelighet, tunneleforhandling og applikasjonens egen tilstand. Hver har sine egne bevis, og en rapport som holder dem atskilt, forteller neste person hvor de skal se.

Noter også begrensningene ved sammenligningen. Hvis en policy hindret en test av den direkte veien, si det i stedet for å presentere endepunktsammenligningen som bevis. Landetiketten i appen identifiserer ikke hele ruten, og en server som er geografisk nær, kan fortsatt nås gjennom en overbelastet vei.

WireGuard-prosjektets side om kjente begrensninger er en nyttig påminnelse om at en protokoll kan være korrekt og likevel overlate lenkeatferd til operativsystemet. Avslutt med å gjenta den samme testen etter neste frakobling, fordi en enkelt hendelse er et datapunkt og et mønster er en diagnose.