WireGuard använder fortfarande den gamla slutpunkten efter DNS-ändringar

Tunneln slutade föra vidare trafik efter att serverns DNS-post flyttades, och namnet slås korrekt upp från samma maskin. De två fakta står inte i konflikt. En WireGuard-konfiguration innehåller en slutpunkt, och verktyget slår upp namnet i det ögonblick det tillämpar konfigurationen, så gränssnittet som körs kan fortsätta använda adressen det hämtade för timmar sedan. Kontrollera vad gränssnittet använder innan du byter nycklar eller rör tunnelområdet.

Namnet slås upp en gång, inte fortlöpande

Grundläggande WireGuard-konfiguration tar en slutpunkt som adress och port, och verktyget som reser ett gränssnitt slår upp ett värdnamn i det ögonblicket. Ingenting i basprotokollet frågar DNS enligt ett schema, och ett klientprogram kan lägga sitt eget uppdateringsbeteende ovanpå. Att anteckna den uppslagna adressen, familjen och porten bredvid namnet gör gapet synligt. Utan den anteckningen ser konfigurationen korrekt ut medan gränssnittet talar med något annat.

Det finns en äkta automatisk uppdatering, och den är värd att känna till eftersom den liknar en DNS-uppdatering utan att vara det. En peers slutpunkt kan flytta sig när korrekt autentiserad trafik kommer från en ny adress, vilket är roaming och inte namnförfrågan. Den följer peeren, så den kan inte upptäcka en orelaterad ny server som den gamla slutpunkten aldrig kontaktade.

Jämför posten med adressen som används

Fråga efter det dokumenterade namnet via den resolver klienten använder och fråga sedan gränssnittet vilken slutpunkt det håller. De två svaren är jämförelsen som avgör resten av den här sidan:

dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes

Manualen för wg(8) dokumenterar de show-underkommandon som dessa rader använder. Jämför även adressfamiljen, inte bara adressen, eftersom en post som fått en IPv6-post är en annan jämförelse än en där IPv4-adressen ändrats. Om slutpunkten skiljer sig från posten kör gränssnittet på inaktuell information och namnet var aldrig problemet. Om de stämmer och tunneln fortfarande misslyckas, gå till lyssnaren och reglerna i stället för till profilen.

Tidsstämpeln för handskakningen står i det blocket eftersom slutpunkten ensam inte säger om peeren nås. En inaktuell tidsstämpel bredvid en korrekt slutpunkt är ett vägproblem, inte ett uppslagsproblem, och den skillnaden ändrar vad du rör härnäst.

Starta om via gränssnittets hanterare

När slutpunkten har bekräftats inaktuell, uppdatera den via mekanismen som äger gränssnittet i stället för att redigera den körande konfigurationen. För ett gränssnitt som startats av wg-quick är det en ned och upp, för en systemd-enhet en omstart, och för ett gränssnitt som ägs av en hanterare en ändring gjord i den hanteraren, eftersom en redigering under körning skrivs över vid nästa tillämpning:

wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0

Bekräfta sedan att den nya lyssnaren och dess identitet är den tjänst du menade. En DNS-flytt är inte en identitetsändring, så den bör aldrig vara anledningen att lita på en nyckel du inte har verifierat. Om gränssnittet nu rapporterar den nya adressen och fortfarande inte ger någon handskakning har felet flyttat sig till den nya nätverksvägen eller lyssnaren, vilket är framsteg och inte samma fel två gånger.

Handskakning först, sedan datavägen

Skilj de två utfallen åt innan du väljer en checklista. En handskakning som lyckas under ett program som misslyckas är ett datavägsproblem: rutter, tillåtna prefix eller DNS inne i tunneln. En handskakning som aldrig sker är ett tillgänglighets- eller identitetsproblem vid slutpunkten. Att blanda de två ger en rapport som ingen kan återskapa och en ändringslogg med tre orelaterade redigeringar.

Anteckna namnet, den uppslagna adressen, slutpunkten som används och om handskakningen fullbordades. De fyra fakta besvarar frågan som det här felet ständigt ställer, och gör nästa förekomst till en kontroll på två minuter. Namnunderhåll och klientinförande förblir separata uppgifter: att rätta posten utför inte införandet, och att starta om gränssnittet rättar inte en post som fortfarande är fel.