WireGuard werkt pas nadat de server stuurt: kennis van het eindpunt

De tunnel lijkt pas te werken nadat de server eerst iets stuurt. Start vanaf de client en er gebeurt niets, wacht een paar seconden, probeer opnieuw en het lukt. De gebruikelijke diagnose is een kapotte NAT, en de gebruikelijke diagnose is onjuist. Wat veranderd is, is dat de ene peer heeft geleerd waar de andere woont.

Kennis van het eindpunt, niet bereikbaarheid

Een WireGuard-peer begint geen handshake voordat hij weet waarheen die moet. De configuratie levert dat als een eindpunt van adres en poort, en de actieve toestand volgt het eindpunt waar hij op dit moment in gelooft.

wg show drukt beide kanten van dat beeld af, en een peer zonder eindpunt in de uitvoer kan niets beginnen, hoe correct zijn publieke sleutel en toegestane prefixen ook zijn. Vergelijk de kijk van de client met die van de server voordat je een regel wijzigt, want de twee zijn het vaak oneens over wie wat weet.

Hoe een peer een eindpunt leert

WireGuard is bewust stil. Wanneer een correct geauthenticeerd pakket aankomt van een adres dat de peer niet verwachtte, werkt de implementatie het eindpunt van die peer bij naar de nieuwe bron, en zo werkt roaming op een laptop die van netwerk wisselt. Dat gedrag verklaart de richtingsafhankelijkheid: als de server eerst stuurt en zijn pakket de client bereikt, leert de client het huidige adres van de server en kan antwoorden. Tot die tijd heeft hij niets om naartoe te sturen. Het mechanisme is geauthenticeerde roaming en geen sluiproute van vertrouwen bij eerste gebruik, omdat het pakket geldig moest zijn voordat het eindpunt verschoof.

De tooldocumentatie voor wg beschrijft die bijwerking, en het is de moeite waard die één keer te lezen als je eromheen gaat ontwerpen.

Stateful vertaling voegt zijn eigen richting toe

Waar UDP door een vertalende gateway gaat, maakt de gateway toestand aan voor het eerste pakket dat hij ziet. RFC 4787 beschrijft dat gedrag en de time-outs die de koppeling uiteindelijk verwijderen. Een ongebruikte koppeling verloopt, en een inkomend pakket van de andere kant wordt dan door de gateway weggegooid voordat het de host bereikt. Een tunnel die de hele ochtend werkte, stopt in de middag met antwoorden precies om deze reden.

Dit is een tweede en onafhankelijk mechanisme dat hetzelfde richtingsymptoom geeft. Zowel de kennis van het eindpunt als de vertaaltoestand moeten kloppen, en het ene repareren repareert het andere niet.

Configureer de richting die je echt wilt

Voor een client die de verbinding moet beginnen, zet het eindpunt van de server in de peer-sectie van de client en laat het daar. Vertrouwen op de server die eerst stuurt, is vertrouwen op een toeval in de volgorde van het verkeer dat op een stil netwerk zal veranderen. De configuratie hoort de bedoelde richting te vermelden, niet te ontdekken.

Voor een peer achter vertaling die bereikbaar moet blijven, schakel aan die kant een blijvende keepalive in. Een keepalive elke 25 seconden is de gebruikelijke beginwaarde, en het doel is de koppeling openhouden in plaats van de tunnel te testen. Kies één kant om hem te dragen, want inschakelen aan beide kanten verdubbelt het verkeer en de logruis zonder het resultaat te verbeteren.

Vergelijk de toestand voor en na de trigger

Leg de twee beelden vast op het moment dat het mislukt, en daarna opnieuw nadat de server stuurt. De eerste opdracht toont eindpunten en de leeftijd van de handshake. De tweede toont of er een vertaalinvoer voor de poort bestaat. De opname toont welke richting werkelijk over de draad ging, en de routecontrole bevestigt dat de client dat verkeer niet heel ergens anders heen stuurt.

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

Noteer de eindpuntkolom en de vertaalinvoer samen. Een peer zonder eindpunt en een gateway zonder koppeling zijn twee verschillende fouten. Slechts één ervan wordt door een keepalive verholpen.