WireGuard PersistentKeepalive: hold NAT-mappingen i live
Hvis den omvendte forbindelsen bare virker rett etter at partneren sender trafikk, utløper mappingen. Sett keepalive bak ruteren, og les deretter den reelle tidsavbruddet.
Hjemmeboksen åpner tunnelen og når skyserveren uten problemer. Skyserveren kan nå hjemmeapplikasjonen i ett eller to minutter etter at hjemmeboksen sist sendte noe, og slutter deretter. Ingenting vises i WireGuard-loggen, ingen handshake-feil rapporteres, og en omstart av tunnelen fikser det kortvarig. Det mønsteret er en mapping som utløper, ikke en ødelagt tunnel, og runbooken nedenfor bekrefter det før noe endres.
Bekreft at mønsteret er utløp ved inaktivitet
Den avgjørende detaljen er timingen. Hvis den omvendte forbindelsen virker rett etter at hjemmepartneren har sendt trafikk, og feiler etter et rolig intervall, er veien i orden og tilstanden i midten ikke. Hvis den aldri har virket, selv rett etter trafikk, er dette feil diagnose.
sudo wg show wg0 latest-handshakes
sudo wg show wg0 endpoints
sudo wg show wg0 transferKjør de to første rett etter at hjemmepartneren har sendt noe, vent fem minutter og kjør dem igjen. Et handshake-tidsstempel som fornyes etter planen uten et nytt endepunkt forteller deg at tunnelen lever. Det som endret seg, er evnen uoppfordrede pakker har til å komme utenfra, noe som er en egenskap ved veien og ikke ved tunnelen.
Gjør deretter et omvendt forsøk og se på overføringstellerne. Hvis skysiden sender byte og hjemsiden ikke mottar noen, forlot pakken skyen og døde i en tilstandsful enhet underveis. Det er signaturen du leter etter. Hvis begge tellerne beveger seg, leverte tunnelen pakken, og applikasjonen er den mistenkte.
Sett keepalive på partneren bak ruteren
Vedvarende keepalives holder en NAT-mapping og enhver brannmurtilstand i live ved å sende en liten autentisert pakke etter en plan. Innstillingen hører hjemme på maskinen bak ruteren, i oppføringen for den eksterne partneren, fordi det er siden hvis utgående pakke skaper tilstanden.
[Peer]
PublicKey = <cloud peer public key>
AllowedIPs = 10.71.0.1/32
PersistentKeepalive = 25Flett den inn i den eksisterende partnerdelen. Å legge til en andre blokk med samme offentlige nøkkel er ikke en gyldig måte å legge til alternativer på, og wg-quick vil ikke flette dem for deg. De dokumenterte 25 sekundene er et eksempel valgt for å ligge under vanlige UDP-tidsavbrudd, ikke en verdi med spesiell betydning.
Å sette den samme direktiven på skysiden hjelper ikke på dette problemet. Pakker fra den partneren kommer allerede fra en offentlig adresse, så det er ingen mapping å bevare i retningen som betyr noe. Det legger til trafikk og endrer ingenting.
Les timerne i stedet for å gjette et intervall
Keepalives virker fordi de ankommer oftere enn tilstanden utløper. Det gjør tidsavbruddet til tallet du faktisk trenger, og på Linux kan det leses på enheten som gjør oversettelsen:
sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream
sudo conntrack -L -p udp --dport 51820Den første verdien er tidsavbruddet for en UDP-strøm som bare er sett i én retning, og den andre gjelder når svar er observert. Begge er vanligvis korte, og en mapping som blir stille vil følge det som gjelder for strømmen din.
Sammenlign det tallet med intervallet ditt. En keepalive på 25 sekunder under et tidsavbrudd på 30 sekunder virker; den samme keepaliven under et tidsavbrudd på 15 sekunder virker ikke. Ingen mengde nye forsøk endrer den aritmetikken. Noen forbrukerrutere og mobiloperatører bruker mye kortere verdier enn Linux-standardverdien, og derfor feiler en konfigurasjon som virker på ett nettverk, på et annet.
| 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 brannmuren hver for seg
En levende mapping er nødvendig og ikke tilstrekkelig. Applikasjonen på hjemmeboksen må lytte på riktig adresse, og vertsbrannmuren må tillate pakken etter at den er dekryptert.
sudo ss -lntup | grep 8080
sudo wg show wg0 allowed-ips
curl -sS -m 5 http://10.71.0.2:8080/healthHvis socketen bare er bundet til den fysiske grensesnittadressen og ikke til tunneladressen, blir pakker som ankommer på tunnelen droppet før brannmuren i det hele tatt blir spurt. Den feilen ser fra skysiden identisk ut med et mapping-problem, og den overlever enhver keepalive-justering.
Sjekken av den tillatte listen er like viktig i den andre retningen. Sky-partneren må tillate hjemmetunnelens adresse som kilde hvis den skal svare, og hjemmepartneren må tillate skyadressen som mål. Keepalive-pakker er autentisert trafikk og bruker de samme reglene, og derfor kan en keepalive som ser ut til å virke, sameksistere med en applikasjon som ikke gjør det.
Rull ut endringen og kjenn grensene
Bruk innstillingen, start grensesnittet på nytt hvis det er oppdateringsmetoden din, og gjenta deretter inaktivitetstesten i stedet for den umiddelbare testen. Vent lenger enn tidsavbruddet du leste tidligere, gjør en omvendt forespørsel og bekreft at tellerne beveget seg i begge ender.
Noter intervallet og det målte tidsavbruddet ved siden av. En fremtidig endring av ruterens fastvare, eller en overgang til en mobilforbindelse, kan endre tidsavbruddet. Notatet er det som lar noen utlede verdien på nytt i stedet for å kopiere den. To tall på én linje sparer en hel undersøkelse senere.
Vedvarende keepalives beskytter tilstand. De åpner ikke en port, de legger ikke til en oppføring i den tillatte listen, og de får ikke en lytter til å dukke opp. Når den omvendte forbindelsen ikke virker i det hele tatt, ligger feilen i en av de tre, og WireGuard-hurtigstarten beskriver keepalive-innstillingen i de samme snevre begrepene.