WireGuard gebruikt na DNS-wijzigingen nog steeds het oude eindpunt

De tunnel stopte met het doorgeven van verkeer nadat het DNS-record van de server verschoof, en de naam wordt vanaf dezelfde machine correct opgelost. Die twee feiten zijn niet in tegenspraak. Een WireGuard-configuratie bevat een eindpunt, en het gereedschap lost de naam op op het moment dat het die configuratie toepast, dus de draaiende interface kan het adres blijven gebruiken dat hij uren geleden heeft opgezocht. Controleer wat de interface gebruikt voordat u sleutels vervangt of het tunnelbereik aanraakt.

De naam wordt één keer opgelost, niet voortdurend

De basisconfiguratie van WireGuard neemt een eindpunt als adres en poort, en het gereedschap dat een interface opzet lost op dat moment een hostnaam op. Niets in het basisprotocol vraagt DNS volgens een schema, en een clientapplicatie kan er zijn eigen vernieuwingsgedrag bovenop leggen. Het vastleggen van het opgeloste adres, de familie en de poort naast de naam maakt de kloof zichtbaar. Zonder die aantekening lijkt de configuratie juist terwijl de interface met iets anders praat.

Er is één echte automatische update, en die is de moeite waard om te kennen omdat hij op een DNS-vernieuwing lijkt zonder er een te zijn. Het eindpunt van een peer kan verschuiven wanneer correct geauthenticeerd verkeer van een nieuw adres aankomt, wat roaming is en geen naamresolutie. Het volgt de peer, dus het kan geen ongerelateerde nieuwe server ontdekken die het oude eindpunt nooit heeft benaderd.

Vergelijk het record met het adres dat in gebruik is

Vraag de gedocumenteerde naam op via de resolver die de client gebruikt, en vraag daarna de interface welk eindpunt hij vasthoudt. De twee antwoorden zijn de vergelijking die de rest van deze pagina bepaalt:

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

De handleiding van wg(8) documenteert de show-subcommando's die deze regels gebruiken. Vergelijk ook de adresfamilie, niet alleen het adres, want een record dat een IPv6-vermelding heeft gekregen is een andere vergelijking dan een waarvan het IPv4-adres is gewijzigd. Als het eindpunt van het record afwijkt, draait de interface op verouderde informatie en was de naam nooit het probleem. Als ze overeenkomen en de tunnel blijft falen, ga dan naar de luisteraar en de regels in plaats van naar het profiel.

De tijdstempel van de handshake staat in dat blok omdat het eindpunt alleen niet zegt of de peer bereikbaar is. Een verouderde tijdstempel naast een correct eindpunt is een padprobleem, geen resolutieprobleem, en dat onderscheid verandert wat u hierna aanraakt.

Herstart via de beheerder van de interface

Zodra het eindpunt als verouderd is bevestigd, vernieuw het via het mechanisme dat de interface bezit in plaats van de actieve configuratie te bewerken. Voor een interface die door wg-quick is gestart is dat een neer en op, voor een systemd-unit een herstart, en voor een interface die eigendom is van een beheerder een wijziging in die beheerder, omdat een bewerking tijdens runtime bij de volgende toepassing wordt overschreven:

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

Bevestig daarna dat de vervangende luisteraar en zijn identiteit de dienst zijn die u bedoelde. Een DNS-verhuizing is geen identiteitswijziging, dus het mag nooit de aanleiding zijn om een sleutel te vertrouwen die u niet hebt geverifieerd. Als de interface nu het nieuwe adres meldt en er nog steeds geen handshake ontstaat, is de fout naar het nieuwe netwerkpad of de luisteraar verschoven, wat vooruitgang is en niet dezelfde fout twee keer.

Eerst de handshake, dan het datapad

Scheid de twee uitkomsten voordat u een checklist kiest. Een handshake die slaagt onder een applicatie die faalt is een datapadprobleem: routes, toegestane prefixen of DNS binnen de tunnel. Een handshake die nooit gebeurt is een bereikbaarheids- of identiteitsprobleem bij het eindpunt. De twee vermengen levert een rapport op dat niemand kan reproduceren en een wijzigingslog met drie ongerelateerde bewerkingen.

Noteer de naam, het opgeloste adres, het gebruikte eindpunt en of de handshake is voltooid. Die vier feiten beantwoorden de vraag die deze fout blijft stellen, en maken de volgende keer een controle van twee minuten. Naamonderhoud en clientadoptie blijven gescheiden taken: het record corrigeren voert de adoptie niet uit, en de interface herstarten repareert geen record dat nog steeds fout is.