WireGuard svikter etter inaktivitet: test retningen først

Fire spørsmål kommer før enhver innstillingsendring: virker den samme ressursen mens klienten er aktiv, hvor lenge varte inaktivitetsperioden, sov enheten eller byttet den nettverk, og vises feilen bare i trafikk som den andre siden starter. Svarene skiller en utløpt NAT-mapping fra en sovende radio og fra en utdatert applikasjon. De forteller også om en keepalive i det hele tatt er relevant. Begynn med retningen, fordi den koster én kommando og utelukker halvparten av de mulige årsakene.

Hvilken retning svikter?

En ny utgående forespørsel fra klienten og trafikk som ankommer mot den etter en stille periode belaster tilstandsbasert utstyr ulikt. Utgående pakker bygger opp en mapping på nytt når de forlater, mens innkommende pakker trenger at den gamle mappingen har overlevd. Den asymmetrien er hele testen. Hvis klienten kan nå ut, men ingenting kommer inn, er mappingen sannsynligvis utløpt, og hvis ingen av dem virker, er tunnelen eller klientens nettverkstilgang borte.

Legg merke til hvor lenge den stille perioden varte, og om enheten sov eller byttet til et annet nettverk i mellomtiden. De to fakta endrer diagnosen før noen innstilling gjør det.

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

Kjør de tre før og etter den stille perioden, fordi hver av dem svarer på en annen del av spørsmålet. Et handshake-tidsstempel som ikke har flyttet seg, sier at partene sluttet å snakke, mens et endepunkt som har endret seg sier at mappingen flyttet seg i stedet for å dø. Overføringstellerne viser om noe i det hele tatt kom fram, og det er forskjellen mellom en utdatert mapping og en stille applikasjon. Skriv ned tallene begge steder, fordi sammenligningen er beviset.

Søvn, radio og applikasjonstilstand

På en telefon eller bærbar datamaskin kan en sovende enhet ha mistet nettverkstilgangen helt, og en keepalive kan ikke gjenopprette en radio som er av eller fullføre en captive portal som ikke er oppfylt. Mobile plattformer suspenderer bakgrunnsarbeid som en policy, så om periodisk trafikk fortsetter avhenger av plattformen og av hva appen har forhandlet med den. En bufret tilkobling er det tredje tilfellet og det mest misvisende, fordi tunnelens tilbakekomst ikke er det samme som applikasjonens gjenoppkobling til den.

Åpne applikasjonen på nytt etter inaktivitetsperioden i stedet for å stole på fanen som ble stående åpen. Hvis en ny forespørsel lykkes der den gamle økten feilet, var tunnelen aldri problemet.

Hva en keepalive faktisk gjør

PersistentKeepalive sender med jevne mellomrom en autentisert tom pakke til en peer, noe som er nok til å holde en NAT-mapping levende mellom peers og til å holde den andre sidens endepunkt oppdatert, slik WireGuards hurtigstart beskriver. Det reparerer ikke en sovende radio, en tapt rute eller en applikasjon som aldri prøver igjen. Velg intervallet gjennom de støttede klientinnstillingene, og ikke aktiver en aggressiv verdi overalt bare fordi en statusvisning blir stille.

De fleste inaktivitetsperioder er ikke feil. En tunnel som kobler til på nytt etter fem minutters stillhet, oppfører seg riktig, og problemet er bare tilfellet der noe skulle ankomme fra den andre siden.

Vent ut intervallet som pleide å svikte

Gjør én støttet endring, og la deretter den samme inaktivitetsperioden gå før du tester ressursen på nytt. Å vente er en del av testen og ikke en formalitet. Umiddelbar suksess etter en gjenoppkobling sier ingenting om et langt inaktivitetsproblem, fordi gjenoppkoblingen er nettopp hendelsen som nullstiller tilstanden. Hvis problemet også vises under aktiv bruk, gå tilbake til handshake- og datastikontroller i stedet for å legge til mer periodisk trafikk.

Hold én endring per test og skriv ned den brukte inaktivitetsvarigheten. Uten det driver enhver senere sammenligning, og ingen kan si hvilken endring som betydde noe. Noter de fire fakta sammen: retning, varighet, søvntilstand og applikasjonens oppførsel.