WireGuard PersistentKeepalive: hold NAT-mappingen i live
Hvis den omvendte forbindelse kun virker lige efter, at peer’en sender trafik, udløber mappingen. Sæt keepalive bag routeren, og læs derefter den reelle timeout.
Hjemmeboksen åbner tunnelen og når cloudserveren uden problemer. Cloudserveren kan nå hjemmeapplikationen i et minut eller to, efter at hjemmeboksen sidst sendte noget, og holder så op. Der står intet i WireGuard-loggen, der rapporteres ingen handshake-fejl, og en genstart af tunnelen retter det kortvarigt. Det mønster er en mapping, der udløber, ikke en ødelagt tunnel, og runbooken nedenfor bekræfter det, før noget ændres.
Bekræft, at mønsteret er udløb ved inaktivitet
Den afgørende detalje er timingen. Hvis den omvendte forbindelse virker lige efter, at hjemmepeer’en har sendt trafik, og fejler efter et stille interval, er vejen i orden, og tilstanden i midten er ikke. Hvis den aldrig har virket, selv lige efter trafik, er det den forkerte diagnose.
sudo wg show wg0 latest-handshakes
sudo wg show wg0 endpoints
sudo wg show wg0 transferKør de to første lige efter, at hjemmepeer’en har sendt noget, vent fem minutter, og kør dem igen. Et handshake-tidsstempel, der fornyes efter planen uden et nyt endpoint, fortæller dig, at tunnelen lever. Det, der ændrede sig, er evnen for uopfordrede pakker til at ankomme udefra, hvilket er en egenskab ved vejen og ikke ved tunnelen.
Lav derefter et omvendt forsøg, og hold øje med overførsestællerne. Hvis cloud-siden sender bytes, og hjemmesiden ikke modtager nogen, har pakken forladt skyen og er død i en tilstandsfuld enhed undervejs. Det er den signatur, du leder efter. Hvis begge tællere bevæger sig, leverede tunnelen pakken, og applikationen er den mistænkte.
Sæt keepalive på peer’en bag routeren
Vedvarende keepalives holder en NAT-mapping og enhver firewall-tilstand i live ved at sende en lille autentificeret pakke efter en plan. Indstillingen hører på maskinen bag routeren, i dens post for den fjernede peer, fordi det er den side, hvis udgående pakke skaber tilstanden.
[Peer]
PublicKey = <cloud peer public key>
AllowedIPs = 10.71.0.1/32
PersistentKeepalive = 25Flet den ind i den eksisterende peer-sektion. At tilføje en anden blok med samme offentlige nøgle er ikke en gyldig måde at tilføje indstillinger på, og wg-quick fletter dem ikke for dig. De dokumenterede 25 sekunder er et eksempel valgt for at ligge under almindelige UDP-timeouts, ikke en værdi med nogen særlig betydning.
At sætte den samme direktiv på cloud-siden hjælper ikke dette problem. Den peers pakker ankommer allerede fra en offentlig adresse, så der er ingen mapping at bevare i den retning, der betyder noget. Det tilføjer trafik og ændrer intet.
Læs timere i stedet for at gætte et interval
Keepalives virker, fordi de ankommer oftere, end tilstanden udløber. Det gør timeouten til det tal, du faktisk har brug for, og på Linux kan den læses på den enhed, der laver oversættelsen:
sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream
sudo conntrack -L -p udp --dport 51820Den første værdi er timeouten for en UDP-strøm, der kun er set i én retning, og den anden gælder, når svar er observeret. Begge er normalt korte, og en mapping, der bliver stille, følger det, der gælder for din strøm.
Sammenlign det tal med dit interval. En keepalive på 25 sekunder under en timeout på 30 sekunder virker; den samme keepalive under en timeout på 15 sekunder virker ikke. Ingen mængde af gentagelser ændrer den aritmetik. Nogle forbrugerroutere og mobiloperatører bruger meget kortere værdier end Linux-standardværdien, og derfor fejler en konfiguration, der virker på ét netværk, på et andet.
| Observation | What it means | Reasonable response |
|---|---|---|
| Works after traffic, dies when idle | Mapping or firewall state expiring | Lower the keepalive interval |
| Never works, even immediately | No return route, listener or firewall | Stop tuning keepalive |
| Works for hours, then dies once | Carrier-side translation or address change | Check the endpoint and logs together |
Kontroller lytteren og firewallen hver for sig
En levende mapping er nødvendig og ikke tilstrækkelig. Applikationen på hjemmeboksen skal lytte på den rigtige adresse, og værtsfirewallen skal tillade pakken, efter at den er dekrypteret.
sudo ss -lntup | grep 8080
sudo wg show wg0 allowed-ips
curl -sS -m 5 http://10.71.0.2:8080/healthHvis socket’en kun er bundet til den fysiske interface-adresse og ikke til tunneladressen, bliver pakker, der ankommer på tunnelen, droppet, før firewallen overhovedet konsulteres. Den fejl ser fra cloud-siden identisk ud med et mapping-problem, og den overlever enhver keepalive-justering.
Tjekket af den tilladte liste er lige så vigtigt i den anden retning. Cloud-peer’en skal tillade hjemmetunneladressen som kilde, hvis den skal svare, og hjemmepeer’en skal tillade cloudadressen som destination. Keepalive-pakker er autentificeret trafik og bruger de samme regler, og derfor kan en keepalive, der ser ud til at virke, sameksistere med en applikation, der ikke gør.
Rul ændringen ud, og kend dens grænser
Anvend indstillingen, genstart interfacet, hvis det er din opdateringsmetode, og gentag derefter inaktivitetstesten i stedet for den øjeblikkelige test. Vent længere end den timeout, du læste tidligere, lav en omvendt anmodning, og bekræft, at tællerne flyttede sig i begge ender.
Notér intervallet og den målte timeout ved siden af. En fremtidig ændring af routerens firmware eller et skift til en mobilforbindelse kan ændre timeouten. Noten er det, der lader nogen udlede værdien igen i stedet for at kopiere den. To tal på en linje sparer en hel undersøgelse senere.
Vedvarende keepalives beskytter tilstand. De åbner ikke en port, de tilføjer ikke en post på den tilladte liste, og de får ikke en lytter til at dukke op. Når den omvendte forbindelse slet ikke virker, ligger fejlen i en af de tre, og WireGuard-hurtigstarten beskriver keepalive-indstillingen i de samme snævre vendinger.