WireGuard PersistentKeepalive: hou die NAT-kartering lewendig

Die tuisboks maak die tonnel oop en bereik die wolkbediener sonder probleme. Die wolkbediener kan die tuistoepassing ’n minuut of twee lank bereik nadat die tuisboks laas iets gestuur het, en dan stop dit. Niks verskyn in die WireGuard-logboek nie, geen handskudfout word gerapporteer nie, en die tonnel herbegin maak dit kortstondig reg. Daardie patroon is ’n kartering wat verval, nie ’n stukkende tonnel nie, en die runbook hieronder bevestig dit voordat enigiets verander word.

Bevestig dat die patroon deur onaktiwiteit verval

Die onderskeidende besonderheid is tydsberekening. As die omgekeerde verbinding onmiddellik werk nadat die tuisportuur verkeer gestuur het en na ’n stil interval misluk, is die pad reg en die toestand in die middel nie. As dit nooit gewerk het nie, selfs reg ná verkeer, is dit die verkeerde diagnose.

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

Voer die eerste twee onmiddellik uit nadat die tuisportuur iets gestuur het, wag vyf minute en voer hulle weer uit. ’n Handskudtydstempel wat volgens skedule vernuwe word sonder ’n nuwe eindpunt, sê vir jou die tonnel leef. Wat verander het, is die vermoë van onversoekte pakkette om van buite te arriveer, wat ’n eienskap van die pad is eerder as van die tonnel.

Maak dan ’n omgekeerde poging en kyk na die oordragtellers. As die wolkkant grepe stuur en die tuiskant ontvang niks, het die pakket die wolk verlaat en in ’n toestandvolle toestel op pad in gesterf. Dit is die handtekening waarna jy soek. As albei tellers beweeg, het die tonnel die pakket afgelewer en is die toepassing die verdagte.

Plaas die lewendighouding op die portuur agter die roeteerder

Aanhoudende lewendighoudings hou ’n NAT-kartering en enige vuurmuurtoestand lewendig deur op ’n skedule ’n klein geoutentiseerde pakket te stuur. Die instelling hoort op die masjien agter die roeteerder, in sy inskrywing vir die afgeleë portuur, want dit is die kant wie se uitgaande pakket die toestand skep.

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

Voeg dit by die bestaande portuurafdeling in. Om ’n tweede blok met dieselfde publieke sleutel by te voeg is nie ’n geldige manier om opsies by te voeg nie, en wg-quick sal dit nie vir jou saamvoeg nie. Die gedokumenteerde 25 sekondes is ’n voorbeeld wat gekies is om onder algemene UDP-tydverstrykings te sit, nie ’n waarde met enige spesiale betekenis nie.

Om dieselfde richtlijn op die wolkkant te plaas, help nie hierdie probleem nie. Daardie portuur se pakkette arriveer reeds van ’n publieke adres, so daar is geen kartering om in die rigting wat saak maak te bewaar nie. Dit voeg verkeer by en verander niks.

Lees die tydhouers in plaas daarvan om ’n interval te raai

Lewendighoudings werk omdat hulle meer dikwels arriveer as wat die toestand verval. Dit maak die tydverstryking die getal wat jy eintlik nodig het, en op Linux is dit leesbaar op die toestel wat die vertaling doen:

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

Die eerste waarde is die tydverstryking vir ’n UDP-vloei wat net in een rigting gesien is, en die tweede geld sodra antwoorde waargeneem is. Albei is gewoonlik kort, en ’n kartering wat stil raak sal volg wat ook al op jou vloei van toepassing is.

Vergelyk daardie getal met jou interval. ’n Lewendighouding van 25 sekondes onder ’n tydverstryking van 30 sekondes werk; dieselfde lewendighouding onder ’n tydverstryking van 15 sekondes werk nie. Geen hoeveelheid herprobeer verander daardie rekenkunde nie. Sommige verbruikersroeteerders en mobiele netwerke gebruik baie korter waardes as die Linux-verstek, en daarom misluk ’n konfigurasie wat op een netwerk werk op ’n ander.

Kontroleer die luisteraar en die vuurmuur afsonderlik

’n Lewende kartering is nodig en nie voldoende nie. Die toepassing op die tuisboks moet op die regte adres luister, en die gasheervuurmuur moet die pakket toelaat nadat dit ontsyfer is.

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

As die sok slegs aan die fisiese koppelvlakadres gebind is eerder as aan die tonneladres, word pakkette wat op die tonnel aankom, verwerp voordat die vuurmuur geraadpleeg word. Daardie fout lyk van die wolkkant identies aan ’n karteringsprobleem, en dit oorleef elke lewendighoudingaanpassing.

Die kontrole van die toegelaatlys is ewe belangrik in die ander rigting. Die wolkportuur moet die tuistonneladres as ’n bron toelaat as dit gaan antwoord, en die tuisportuur moet die wolkadres as ’n bestemming toelaat. Lewendighoudingpakkette is geoutentiseerde verkeer en hulle oefen dieselfde reëls uit, en daarom kan ’n lewendighouding wat werk saam met ’n toepassing wat nie werk nie bestaan.

Rol die verandering uit en ken sy grense

Pas die instelling toe, herbegin die koppelvlak as dit jou opdateringsmetode is, en herhaal dan die onaktiwiteitstoets eerder as die onmiddellike toets. Wag langer as die tydverstryking wat jy vroeër gelees het, maak ’n omgekeerde versoek en bevestig dat die tellers aan albei kante beweeg het.

Teken die interval en die tydverstryking wat jy gemeet het, langs dit aan. ’n Toekomstige verandering aan die roeteerder se firmware, of ’n skuif na ’n mobiele verbinding, kan die tydverstryking verander. Die nota is wat iemand in staat stel om die waarde weer af te lei in plaas daarvan om dit te kopieer. Twee getalle op ’n lyn spaar later ’n hele ondersoek.

Aanhoudende lewendighoudings beskerm toestand. Hulle maak nie ’n poort oop nie, hulle voeg nie ’n toegelaatlys-inskrywing by nie, en hulle laat nie ’n luisteraar verskyn nie. Wanneer die omgekeerde verbinding glad nie werk nie, is die fout een van daardie drie, en die WireGuard-vinnige begin beskryf die lewendighoudinginstelling in dieselfde eng terme.