WireGuard svikt etter inaktivitet: test retninga først

Fire spørsmål kjem før kvar innstillingsendring: verkar den same ressursen medan klienten er aktiv, kor lenge varte inaktivitetsperioden, sov eininga eller bytte ho nettverk, og viser feilen seg berre i trafikk som den andre sida startar. Svara skil ei utgått NAT-mapping frå ein sovande radio og frå ein utdatert applikasjon. Dei fortel òg om ein keepalive i det heile er relevant. Byrja med retninga, fordi ho kostar éin kommando og utelukkar halvparten av dei moglege årsakene.

Kva retning sviktar?

Ein ny utgåande førespurnad frå klienten og trafikk som kjem mot han etter ein stille periode belastar tilstandsbasert utstyr ulikt. Utgåande pakkar byggjer opp ei mapping på nytt når dei forlèt, medan inngåande pakkar treng at den gamle mappinga har overlevd. Den asymmetrien er heile testen. Viss klienten kan nå ut, men ingenting kjem inn, er mappinga truleg utgått, og viss ingen av dei verkar, er tunnelen eller nettverkstilgangen til klienten borte.

Legg merke til kor lenge den stille perioden varte, og om eininga sov eller bytte til eit anna nettverk i mellomtida. Dei to fakta endrar diagnosen før noka innstilling gjer det.

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

Køyr dei tre før og etter den stille perioden, fordi kvar av dei svarar på ein annan del av spørsmålet. Eit handshake-tidsstempel som ikkje har flytta seg, seier at partane slutta å snakke, medan eit endepunkt som har endra seg seier at mappinga flytta seg i staden for å døy. Overføringsteljarane viser om noko i det heile kom fram, og det er skilnaden mellom ei utdatert mapping og ein stille applikasjon. Skriv ned tala begge stader, fordi samanlikninga er beviset.

Søvn, radio og applikasjonstilstand

På ein telefon eller berbar datamaskin kan ei sovande eining ha mista nettverkstilgangen heilt, og ein keepalive kan ikkje gjenopprette ein radio som er av eller fullføre ein captive portal som ikkje er oppfylt. Mobile plattformer suspenderer bakgrunnsarbeid som ein policy, så om periodisk trafikk held fram, avheng av plattforma og av kva appen har forhandla med henne. Ei bufra tilkopling er det tredje tilfellet og det mest misvisande, fordi tilbakekomsten av tunnelen ikkje er det same som at applikasjonen koplar seg til han på nytt.

Opne applikasjonen på nytt etter inaktivitetsperioden i staden for å stole på fana som vart ståande open. Viss ein ny førespurnad lukkast der den gamle økta feila, var tunnelen aldri problemet.

Kva ein keepalive faktisk gjer

PersistentKeepalive sender med jamne mellomrom ein autentisert tom pakke til ein peer, noko som er nok til å halde ei NAT-mapping levande mellom peers og til å halde endepunktet til den andre sida oppdatert, slik WireGuards hurtigstart skildrar. Det reparerer ikkje ein sovande radio, ei tapt rute eller ein applikasjon som aldri prøver igjen. Vel intervallet gjennom dei støtta klientinnstillingane, og ikkje slå på ein aggressiv verdi overalt berre fordi ei statusvising blir stille.

Dei fleste inaktivitetsperiodar er ikkje feil. Ein tunnel som koplar til på nytt etter fem minutt stillheit, oppfører seg rett, og problemet er berre tilfellet der noko skulle kome frå den andre sida.

Vent ut intervallet som brukte å svikte

Gjer éi støtta endring, og la deretter den same inaktivitetsperioden gå før du testar ressursen på nytt. Å vente er ein del av testen og ikkje ein formalitet. Umiddelbar suksess etter ei gjenoppkopling seier ingenting om eit langt inaktivitetsproblem, fordi gjenoppkoplinga er nettopp hendinga som nullstiller tilstanden. Viss problemet òg viser seg under aktiv bruk, gå tilbake til handshake- og datastikontrollar i staden for å leggje til meir periodisk trafikk.

Hald éi endring per test og skriv ned den brukte inaktivitetsvarigheita. Utan det driv kvar seinare samanlikning, og ingen kan seie kva endring som betydde noko. Noter dei fire fakta saman: retning, varigheit, søvntilstand og oppførselen til applikasjonen.