WireGuard svigter efter inaktivitet: test retningen først

Fire spørgsmål kommer før enhver ændring af indstillinger: virker den samme ressource, mens klienten er aktiv, hvor længe varede den inaktive periode, sov enheden eller skiftede den netværk, og viser fejlen sig kun for trafik, som den anden side starter. Svarene adskiller en udløbet NAT-mapping fra en sovende radio og fra en forældet applikation. De fortæller også, om en keepalive overhovedet er relevant. Begynd med retningen, fordi den koster én kommando og udelukker halvdelen af de mulige årsager.

Hvilken retning svigter?

En ny udgående anmodning fra klienten og trafik, der ankommer mod den efter en stille periode, belaster stateful udstyr forskelligt. Udgående pakker genopbygger en mapping, når de forlader, mens indgående pakker har brug for, at den gamle mapping har overlevet. Den asymmetri er hele testen. Hvis klienten kan nå ud, men intet når ind, er mappingen sandsynligvis udløbet, og hvis ingen af dem virker, er tunnelen eller klientens netværksadgang væk.

Bemærk, hvor længe den stille periode varede, og om enheden sov eller skiftede til et andet netværk i mellemtiden. De to fakta ændrer diagnosen, før nogen indstilling gør det.

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

Kør de tre før og efter den stille periode, fordi hver især besvarer en anden del af spørgsmålet. Et handshake-tidsstempel, der ikke har flyttet sig, siger, at parterne holdt op med at tale, mens et endepunkt, der har ændret sig siger, at mappingen flyttede sig i stedet for at dø. Overførselsstællerne viser, om der overhovedet ankom noget, og det er forskellen mellem en forældet mapping og en tavs applikation. Skriv tallene ned begge steder, fordi sammenligningen er beviset.

Søvn, radio og applikationstilstand

På en telefon eller bærbar computer kan en sovende enhed helt have mistet netværksadgang, og en keepalive kan ikke genskabe en radio, der er slukket, eller fuldføre en captive portal, der ikke er opfyldt. Mobile platforme suspenderer baggrundsarbejde som en politik, så om periodisk trafik fortsætter, afhænger af platformen og af, hvad appen har forhandlet med den. En cachet forbindelse er det tredje tilfælde og det mest vildledende, fordi tunnelens tilbagekomst ikke er det samme som applikationens genopkobling til den.

Genåbn applikationen efter den inaktive periode i stedet for at stole på fanen, der blev stående åben. Hvis en ny anmodning lykkes, hvor den gamle session fejlede, var tunnelen aldrig problemet.

Hvad en keepalive faktisk gør

PersistentKeepalive sender periodisk en autentificeret tom pakke til en peer, hvilket er nok til at holde en NAT-mapping i live mellem peers og til at holde den anden sides endepunkt aktuelt, som WireGuards hurtige start beskriver. Den reparerer ikke en sovende radio, en tabt rute eller en applikation, der aldrig prøver igen. Vælg intervallet via de understøttede klientindstillinger, og aktivér ikke en aggressiv værdi overalt, bare fordi en statusvisning bliver tavs.

De fleste inaktive perioder er ikke fejl. En tunnel, der genopkobler efter fem minutters stilhed, opfører sig korrekt, og problemet er kun det tilfælde, hvor noget skulle ankomme fra den anden side.

Vent på det interval, der plejede at svigte

Foretag én understøttet ændring, og lad derefter den samme inaktive periode gå, før du tester den ressource igen. At vente er en del af testen og ikke en formalitet. Øjeblikkelig succes efter en genopkobling siger intet om et langt inaktivitetssymptom, fordi genopkobling netop er den hændelse, der nulstiller tilstanden. Hvis problemet også viser sig under aktiv brug, gå tilbage til handshake- og datastikontroller i stedet for at tilføje mere periodisk trafik.

Hold én ændring per test, og skriv den brugte inaktive varighed ned. Uden det driver enhver senere sammenligning, og ingen kan se, hvilken ændring der betød noget. Notér de fire fakta sammen: retning, varighed, søvntilstand og applikationens opførsel.