WireGuard PersistentKeepalive: hald NAT-mappinga i live

Heimeboksen opnar tunnelen og når skyserveren utan problem. Skyserveren kan nå heimeapplikasjonen i eitt eller to minutt etter at heimeboksen sist sende noko, og sluttar deretter. Ingenting viser seg i WireGuard-loggen, ingen handshake-feil vert rapportert, og ein omstart av tunnelen fiksar det kortvarig. Det mønsteret er ei mapping som går ut, ikkje ein øydelagd tunnel, og runbooken nedanfor stadfestar det før noko vert endra.

Stadfest at mønsteret er utgang ved inaktivitet

Den avgjerande detaljen er timinga. Viss den omvende sambindinga virkar rett etter at heimepartnaren har sendt trafikk, og feilar etter eit roleg intervall, er vegen i orden og tilstanden i midten ikkje. Viss ho aldri har virka, sjølv rett etter trafikk, er dette feil diagnose.

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

Køyr dei to første rett etter at heimepartnaren har sendt noko, vent fem minutt og køyr dei igjen. Eit handshake-tidsstempel som vert fornya etter planen utan eit nytt endepunkt fortel deg at tunnelen lever. Det som endra seg, er evna uoppfordra pakkar har til å kome utanfrå, noko som er ein eigenskap ved vegen og ikkje ved tunnelen.

Gjer deretter eit omvendt forsøk og sjå på overføringsteljarane. Viss skysida sender byte og heimesida ikkje mottek nokon, forlét pakken skyen og døydde i ein tilstandsful eining undervegs. Det er signaturen du leitar etter. Viss begge teljarane flyttar seg, leverte tunnelen pakken, og applikasjonen er den mistenkte.

Set keepalive på partnaren bak rutaren

Vedvarande keepalives held ei NAT-mapping og kvar brannmur-tilstand i live ved å sende ein liten autentisert pakke etter ein plan. Innstillinga høyrer heime på maskina bak rutaren, i oppføringa for den eksterne partnaren, fordi det er den sida der den utgåande pakken skaper tilstanden.

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

Flett ho inn i den eksisterande partnaren. Å leggje til ein andre blokk med same offentlege nøkkel er ikkje ein gyldig måte å leggje til val på, og wg-quick vil ikkje flette dei for deg. Dei dokumenterte 25 sekunda er eit døme valt for å liggje under vanlege UDP-tidsavbrot, ikkje ein verdi med særleg tyding.

Å setje den same direktivet på skysida hjelper ikkje på dette problemet. Pakkar frå den partnaren kjem allereie frå ei offentleg adresse, så det er inga mapping å ta vare på i retninga som betyr noko. Det legg til trafikk og endrar ingenting.

Les timarane i staden for å gjette eit intervall

Keepalives verkar fordi dei kjem oftare enn tilstanden går ut. Det gjer tidsavbrotet til talet du faktisk treng, og på Linux kan det lesast på eininga som gjer omsetjinga:

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

Den første verdien er tidsavbrotet for ein UDP-straum som berre er sett i éi retning, og den andre gjeld når svar er observerte. Begge er vanlegvis korte, og ei mapping som vert stille vil følgje det som gjeld for straumen din.

Samanlikn det talet med intervallet ditt. Ein keepalive på 25 sekund under eit tidsavbrot på 30 sekund verkar; den same keepaliven under eit tidsavbrot på 15 sekund verkar ikkje. Inga mengd nye forsøk endrar den aritmetikken. Nokre forbrukar-rutrar og mobiloperatørar brukar mykje kortare verdiar enn Linux-standardverdien, og difor feilar ein konfigurasjon som verkar på eitt nettverk, på eit anna.

Kontroller lyttaren og brannmuren kvar for seg

Ei levande mapping er naudsynt og ikkje tilstrekkeleg. Applikasjonen på heimeboksen må lytte på rett adresse, og vertsbrannmuren må tillate pakken etter at han er dekryptert.

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

Viss socketen berre er bunde til den fysiske grensesnittadressa og ikkje til tunneladressa, vert pakkar som kjem på tunnelen droppa før brannmuren i det heile vert spurd. Den feilen ser frå skysida identisk ut med eit mapping-problem, og han overlever kvar keepalive-justering.

Sjekken av den tillatne lista er like viktig i den andre retninga. Sky-partnaren må tillate adressa til heimetunnelen som kjelde viss han skal svare, og heimepartnaren må tillate skyadressa som mål. Keepalive-pakkar er autentisert trafikk og brukar dei same reglane, og difor kan ein keepalive som ser ut til å verke, sameksistere med ein applikasjon som ikkje gjer det.

Rull ut endringa og kjenn grensene

Bruk innstillinga, start grensesnittet på nytt viss det er oppdateringsmetoden din, og gjer så inaktivitetstesten på nytt i staden for den umiddelbare testen. Vent lenger enn tidsavbrotet du las tidlegare, gjer ein omvend forespurnad og stadfest at teljarane flytta seg i begge endar.

Noter intervallet og det målte tidsavbrotet ved sida av. Ei framtidig endring av rutarfastvaren, eller ein overgang til ei mobilbinding, kan endre tidsavbrotet. Notatet er det som lèt nokon leie ut verdien på nytt i staden for å kopiere han. To tal på éi linje sparar ei heil undersøking seinare.

Vedvarande keepalives beskyttar tilstand. Dei opnar ikkje ein port, dei legg ikkje til ei oppføring i den tillatne lista, og dei får ikkje ein lyttar til å dukke opp. Når den omvende sambindinga ikkje verkar i det heile, ligg feilen i ein av dei tre, og WireGuard-hurtigstarten skildrar keepalive-innstillinga i dei same snevre omgrepa.