WireGuard PersistentKeepalive: håll NAT-mappningen vid liv

Hemmalådan öppnar tunneln och når molnservern utan problem. Molnservern kan nå hemmaprogrammet i en eller två minuter efter att hemmalådan senast skickade något, och slutar sedan. Ingenting visas i WireGuard-loggen, inget handskakningsfel rapporteras, och en omstart av tunneln löser det tillfälligt. Det mönstret är en mappning som löper ut, inte en trasig tunnel, och stegen nedan bekräftar det innan något ändras.

Bekräfta att mönstret är ett utlöpande vid inaktivitet

Den avgörande detaljen är timingen. Om den omvända anslutningen fungerar direkt efter att hempeer’en skickat trafik och misslyckas efter ett lugnt intervall, är vägen i ordning och tillståndet i mitten inte. Om den aldrig har fungerat, även direkt efter trafik, är detta fel diagnos.

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

Kör de två första direkt efter att hempeer’en har skickat något, vänta fem minuter och kör dem igen. En handskakningstidsstämpel som förnyas enligt schemat utan en ny slutpunkt säger att tunneln lever. Det som ändrades är förmågan för oombedda paket att komma utifrån, vilket är en egenskap hos vägen och inte hos tunneln.

Gör sedan ett omvänt försök och titta på överföringsräknarna. Om molnsidan skickar byte och hemsidan inte tar emot någon, lämnade paketet molnet och dog i en tillståndsfull enhet på vägen. Det är signaturen du letar efter. Om båda räknarna rör sig levererade tunneln paketet och programmet är den misstänkta.

Sätt keepalive på peern bakom routern

Beständiga keepalive håller en NAT-mappning och varje brandväggstillstånd vid liv genom att enligt schema skicka ett litet autentiserat paket. Inställningen hör hemma på maskinen bakom routern, i dess post för fjärrpeern, eftersom det är den sidan vars utgående paket skapar tillståndet.

[Peer]
PublicKey = <cloud peer public key>
AllowedIPs = 10.71.0.1/32
PersistentKeepalive = 25

Slå ihop den med det befintliga peer-avsnittet. Att lägga till ett andra block med samma publika nyckel är inte ett giltigt sätt att lägga till alternativ, och wg-quick slår inte ihop dem åt dig. De dokumenterade 25 sekunderna är ett exempel valt för att ligga under vanliga UDP-tidsgränser, inte ett värde med särskild betydelse.

Att sätta samma direktiv på molnsidan hjälper inte mot det här problemet. Den peerns paket kommer redan från en publik adress, så det finns ingen mappning att bevara i den riktning som spelar roll. Det lägger till trafik och ändrar ingenting.

Läs timrarna i stället för att gissa ett intervall

Keepalive fungerar eftersom de kommer oftare än tillståndet löper ut. Det gör tidsgränsen till talet du faktiskt behöver, och på Linux kan den läsas på enheten som gör översättningen:

sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream
sudo conntrack -L -p udp --dport 51820

Det första värdet är tidsgränsen för ett UDP-flöde som bara setts i en riktning, och det andra gäller när svar har observerats. Båda är vanligtvis korta, och en mappning som tystnar följer det som gäller för ditt flöde.

Jämför det talet med ditt intervall. En keepalive på 25 sekunder under en tidsgräns på 30 sekunder fungerar; samma keepalive under en tidsgräns på 15 sekunder fungerar inte. Ingen mängd nya försök ändrar den aritmetiken. Vissa konsumentroutrar och mobiloperatörer använder mycket kortare värden än Linux-standardvärdet, och därför misslyckas en konfiguration som fungerar i ett nätverk i ett annat.

Kontrollera lyssnaren och brandväggen var för sig

En levande mappning är nödvändig och inte tillräcklig. Programmet på hemmalådan måste lyssna på rätt adress, och värdens brandvägg måste tillåta paketet efter dekryptering.

sudo ss -lntup | grep 8080
sudo wg show wg0 allowed-ips
curl -sS -m 5 http://10.71.0.2:8080/health

Om socketen bara är bunden till den fysiska gränssnittsadressen och inte till tunneladressen, släpps paket som kommer in på tunneln innan brandväggen ens tillfrågas. Det felet ser från molnsidan identiskt ut med ett mappningsproblem, och det överlever varje keepalive-justering.

Kontrollen av den tillåtna listan är lika viktig i den andra riktningen. Molnpeern måste tillåta hemmatunnelns adress som källa om den ska svara, och hempeern måste tillåta molnadressen som mål. Keepalive-paket är autentiserad trafik och tillämpar samma regler, därför kan en keepalive som verkar fungera samexistera med ett program som inte gör det.

Rulla ut ändringen och känn dess gränser

Tillämpa inställningen, starta om gränssnittet om det är din uppdateringsmetod, och upprepa sedan inaktivitetstestet i stället för det omedelbara testet. Vänta längre än tidsgränsen du läste tidigare, gör en omvänd begäran och bekräfta att räknarna rörde sig i båda ändar.

Anteckna intervallet och den uppmätta tidsgränsen bredvid. En framtida ändring av routerns firmware, eller en övergång till en mobilanslutning, kan ändra tidsgränsen. Anteckningen är det som låter någon härleda värdet igen i stället för att kopiera det. Två tal på en rad sparar en hel utredning senare.

Beständiga keepalive skyddar tillstånd. De öppnar ingen port, de lägger inte till en post i den tillåtna listan och de får ingen lyssnare att dyka upp. När den omvända anslutningen inte fungerar alls ligger felet i en av de tre, och WireGuard-snabbstarten beskriver keepalive-inställningen i samma snäva termer.