WireGuard misslyckas efter inaktivitet: testa riktningen först

Fyra frågor kommer före varje inställningsändring: fungerar samma resurs medan klienten är aktiv, hur länge varade inaktivitetsperioden, sov enheten eller bytte den nätverk, och visas felet bara i trafik som den andra sidan startar. Svaren skiljer en utgången NAT-mappning från en sovande radio och från en inaktuell applikation. De säger också om en keepalive ens är relevant. Börja med riktningen, eftersom den kostar ett kommando och utesluter hälften av de möjliga orsakerna.

Vilken riktning misslyckas?

En ny utgående begäran från klienten och trafik som anländer mot den efter en tyst period belastar tillståndsbaserad utrustning olika. Utgående paket bygger upp en mappning när de lämnar, medan inkommande paket behöver att den gamla mappningen har överlevt. Den asymmetrin är hela testet. Om klienten kan nå ut men ingenting kommer in är mappningen förmodligen utgången, och om ingen av dem fungerar är tunneln eller klientens nätverksåtkomst borta.

Notera hur länge den tysta perioden varade och om enheten sov eller bytte till ett annat nätverk under tiden. Dessa två fakta ändrar diagnosen innan någon inställning gör det.

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

Kör de tre före och efter den tysta perioden, eftersom var och en svarar på en annan del av frågan. En handshake-tidsstämpel som inte har flyttat sig säger att parterna slutade prata, medan en slutpunkt som har ändrats säger att mappningen flyttade sig i stället för att dö. Överföringsräknarna visar om något alls kom fram, och det är skillnaden mellan en inaktuell mappning och en tyst applikation. Skriv ned talen på båda ställena, eftersom jämförelsen är beviset.

Sömn, radio och applikationstillstånd

På en telefon eller bärbar dator kan en sovande enhet helt ha tappat nätverksåtkomsten, och en keepalive kan inte återställa en radio som är avstängd eller slutföra en captive portal som inte är uppfylld. Mobila plattformar pausar bakgrundsarbete enligt policy, så om periodisk trafik fortsätter beror på plattformen och på vad appen har förhandlat med den. En cachad anslutning är det tredje fallet och det mest vilseledande, eftersom tunnelns återkomst inte är detsamma som applikationens återanslutning till den.

Öppna applikationen igen efter inaktivitetsperioden i stället för att lita på fliken som blev kvar öppen. Om en ny begäran lyckas där den gamla sessionen misslyckades var tunneln aldrig problemet.

Vad en keepalive faktiskt gör

PersistentKeepalive skickar med jämna mellanrum ett autentiserat tomt paket till en peer, vilket räcker för att hålla en NAT-mappning vid liv mellan peers och för att hålla den andra sidans slutpunkt uppdaterad, som WireGuards snabbstart beskriver. Det reparerar inte en sovande radio, en förlorad rutt eller en applikation som aldrig försöker igen. Välj intervallet via de stödda klientinställningarna och aktivera inte ett aggressivt värde överallt bara för att en statusvisning blir tyst.

De flesta inaktivitetsperioder är inte fel. En tunnel som återansluter efter fem minuters tystnad beter sig korrekt, och problemet är bara fallet där något skulle ha anlänt från den andra sidan.

Vänta ut intervallet som brukade misslyckas

Gör en stödd ändring och låt sedan samma inaktivitetsperiod gå innan du testar resursen igen. Att vänta är en del av testet och inte en formalitet. Omedelbar framgång efter en återanslutning säger ingenting om ett långt inaktivitetsproblem, eftersom återanslutningen är just den händelse som nollställer tillståndet. Om problemet också visas under aktiv användning, gå tillbaka till handshake- och datavägskontroller i stället för att lägga till mer periodisk trafik.

Håll en ändring per test och skriv ned den använda inaktivitetsvaraktigheten. Utan det driver varje senare jämförelse iväg och ingen kan säga vilken ändring som spelade roll. Notera de fyra fakta tillsammans: riktning, varaktighet, sömntillstånd och applikationens beteende.