WireGuard PersistentKeepalive: houd de NAT-mapping in leven

De thuisbox opent de tunnel en bereikt de cloudserver zonder problemen. De cloudserver kan de thuisapplicatie nog een of twee minuten bereiken nadat de thuisbox voor het laatst iets heeft verzonden, en stopt daarna. Er verschijnt niets in het WireGuard-log, er wordt geen handshake-fout gemeld, en een herstart van de tunnel lost het kortstondig op. Dat patroon is een mapping die verloopt, geen kapotte tunnel, en de runbook hieronder bevestigt dat voordat er iets wordt gewijzigd.

Bevestig dat het patroon een afloop bij inactiviteit is

Het onderscheidende detail is de timing. Als de omgekeerde verbinding direct werkt nadat de thuispeer verkeer heeft verzonden en na een rustig interval faalt, is het pad in orde en de toestand in het midden niet. Als het nooit heeft gewerkt, zelfs niet direct na verkeer, is dit de verkeerde diagnose.

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

Voer de eerste twee direct uit nadat de thuispeer iets heeft verzonden, wacht vijf minuten en voer ze opnieuw uit. Een handshake-tijdstempel dat volgens schema wordt vernieuwd zonder nieuw eindpunt vertelt je dat de tunnel leeft. Wat veranderde, is het vermogen van ongevraagde pakketten om van buitenaf aan te komen, wat een eigenschap van het pad is en niet van de tunnel.

Doe dan een omgekeerde poging en kijk naar de overdrachtstellers. Als de cloudzijde bytes verzendt en de thuiszijde er geen ontvangt, heeft het pakket de cloud verlaten en is het onderweg in een stateful apparaat gestorven. Dat is de signatuur die je zoekt. Als beide tellers bewegen, heeft de tunnel het pakket afgeleverd en is de applicatie de verdachte.

Zet de keepalive op de peer achter de router

Permanente keepalives houden een NAT-mapping en elke firewaltoestand in leven door volgens een schema een klein geauthenticeerd pakket te verzenden. De instelling hoort op de machine achter de router, in haar vermelding voor de externe peer, omdat dat de zijde is waarvan het uitgaande pakket de toestand creëert.

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

Voeg het samen in het bestaande peergedeelte. Een tweede blok met dezelfde openbare sleutel toevoegen is geen geldige manier om opties toe te voegen, en wg-quick voegt ze niet voor je samen. De gedocumenteerde 25 seconden zijn een voorbeeld dat is gekozen om onder gangbare UDP-time-outs te liggen, geen waarde met een speciale betekenis.

Dezelfde richtlijn aan de cloudzijde zetten helpt niet bij dit probleem. De pakketten van die peer komen al van een openbaar adres, dus er is geen mapping te behouden in de richting die ertoe doet. Het voegt verkeer toe en verandert niets.

Lees de timers in plaats van een interval te raden

Keepalives werken omdat ze vaker aankomen dan de toestand verloopt. Daardoor is de time-out het getal dat je echt nodig hebt, en op Linux is die leesbaar op het apparaat dat de vertaling doet:

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

De eerste waarde is de time-out voor een UDP-stroom die maar in één richting is gezien, en de tweede geldt zodra antwoorden zijn waargenomen. Beide zijn meestal kort, en een mapping die stil wordt, volgt wat op jouw stroom van toepassing is.

Vergelijk dat getal met je interval. Een keepalive van 25 seconden onder een time-out van 30 seconden werkt; dezelfde keepalive onder een time-out van 15 seconden niet. Geen enkele hoeveelheid herhaling verandert die rekenkunde. Sommige consumentenrouters en mobiele providers gebruiken veel kortere waarden dan de Linux-standaard, waardoor een configuratie die op het ene netwerk werkt op het andere faalt.

Controleer de listener en de firewall apart

Een levende mapping is noodzakelijk en niet voldoende. De applicatie op de thuisbox moet op het juiste adres luisteren, en de hostfirewall moet het pakket na ontsleuteling toestaan.

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

Als de socket alleen aan het adres van de fysieke interface is gebonden en niet aan het tunneladres, worden pakketten die op de tunnel aankomen weggegooid voordat de firewall überhaupt wordt geraadpleegd. Die fout ziet er vanaf de cloudzijde identiek uit als een mapping-probleem, en hij overleeft elke keepalive-aanpassing.

De controle van de toegestane lijst is in de andere richting even belangrijk. De cloudpeer moet het adres van de thuistunnel als bron toestaan als hij gaat antwoorden, en de thuispeer moet het cloudadres als bestemming toestaan. Keepalive-pakketten zijn geauthenticeerd verkeer en passen dezelfde regels toe, waardoor een keepalive die lijkt te werken kan samengaan met een applicatie die dat niet doet.

Rol de wijziging uit en ken de grenzen

Pas de instelling toe, herstart de interface als dat je updatemethode is, en herhaal dan de inactiviteitstest in plaats van de directe test. Wacht langer dan de time-out die je eerder las, doe een omgekeerd verzoek en bevestig dat de tellers aan beide uiteinden zijn bewogen.

Noteer het interval en de gemeten time-out ernaast. Een toekomstige wijziging van de routerfirmware, of een overstap naar een mobiele verbinding, kan de time-out veranderen. De notitie is wat iemand in staat stelt de waarde opnieuw af te leiden in plaats van te kopiëren. Twee getallen op één regel besparen later een heel onderzoek.

Permanente keepalives beschermen toestand. Ze openen geen poort, ze voegen geen vermelding aan de toegestane lijst toe, en ze laten geen listener verschijnen. Wanneer de omgekeerde verbinding helemaal niet werkt, ligt de fout in een van die drie, en de WireGuard-snelstart beschrijft de keepalive-instelling in dezelfde nauwe bewoordingen.