WireGuard fungerar först när servern skickar: kunskap om slutpunkten

Tunneln verkar fungera först när servern skickar något först. Starta från klienten och ingenting händer, vänta några sekunder, försök igen och det lyckas. Den vanliga diagnosen är en trasig NAT, och den vanliga diagnosen är fel. Det som ändrades är att den ena parten lärde sig var den andra bor.

Kunskap om slutpunkten, inte nåbarhet

En WireGuard-part startar ingen handskakning förrän den vet vart den ska skicka den. Konfigurationen anger det som en slutpunkt av adress och port, och det körande tillståndet följer den slutpunkt den för närvarande tror på.

wg show skriver ut båda sidorna av den bilden, och en part utan slutpunkt i utdata kan inte starta något, hur korrekt den offentliga nyckeln och de tillåtna prefixen än är. Jämför klientens syn med serverns innan du ändrar någon regel, för de två är ofta oense om vem som vet vad.

Hur en part lär sig en slutpunkt

WireGuard är medvetet tyst. När ett korrekt autentiserat paket anländer från en adress som parten inte förväntade sig, uppdaterar implementationen den partens slutpunkt till den nya källan, och det är så roaming fungerar på en bärbar dator som byter nätverk. Det beteendet förklarar riktningsberoendet: om servern skickar först och dess paket når klienten, lär sig klienten serverns nuvarande adress och kan svara. Fram till dess har den ingenstans att skicka. Mekanismen är autentiserad roaming och inte en genväg med tillit vid första användning, eftersom paketet måste vara giltigt innan slutpunkten flyttades.

Verktygsdokumentationen för wg beskriver den uppdateringen, och den är värd att läsa en gång om du ska designa runt det.

Tillståndsbaserad översättning lägger till sin egen riktning

Där UDP passerar en översättande gateway skapar gatewayen tillstånd för det första paket den ser. RFC 4787 beskriver det beteendet och de tidsgränser som till slut tar bort mappningen. En inaktiv mappning löper ut, och ett inkommande paket från den avlägsna sidan släpps då av gatewayen innan det når värden. En tunnel som fungerade hela förmiddagen slutar svara på eftermiddagen just av denna anledning.

Detta är en andra och oberoende mekanism som ger samma riktningsberoende symptom. Både kunskapen om slutpunkten och översättningstillståndet måste vara korrekta, och att åtgärda det ena åtgärdar inte det andra.

Konfigurera den riktning du faktiskt vill ha

För en klient som måste starta anslutningen, sätt serverns slutpunkt i klientens part-avsnitt och låt den vara där. Att förlita sig på att servern skickar först är att förlita sig på ett sammanträffande i trafikordningen som kommer att ändras i ett tyst nätverk. Konfigurationen bör ange den avsedda riktningen, inte upptäcka den.

För en part bakom översättning som måste förbli nåbar, aktivera en beständig keepalive på den sidan. En keepalive var 25:e sekund är det vanliga startvärdet, och syftet är att hålla mappningen öppen snarare än att testa tunneln. Välj en sida att bära den, för att aktivera den på båda sidor fördubblar trafiken och loggbruset utan att förbättra resultatet.

Jämför tillståndet före och efter utlösaren

Fånga de två vyerna i det ögonblick det misslyckas, och sedan igen efter att servern skickat. Det första kommandot visar slutpunkter och handskakningens ålder. Det andra visar om det finns en översättningspost för porten. Fångsten visar vilken riktning som faktiskt gick över ledningen, och ruttkontrollen bekräftar att klienten inte skickar den trafiken någon helt annanstans.

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

Anteckna slutpunktskolumnen och översättningsposten tillsammans. En part utan slutpunkt och en gateway utan mappning är två olika fel. Bara ett av dem åtgärdas av en keepalive.