WireGuard bruker fortsatt det gamle endepunktet etter DNS-endringer

Tunnelen sluttet å føre trafikk etter at DNS-oppføringen til serveren flyttet seg, og navnet slås korrekt opp fra samme maskin. De to fakta er ikke i konflikt. En WireGuard-konfigurasjon inneholder et endepunkt, og verktøyet slår opp navnet i det øyeblikket det bruker konfigurasjonen, så grensesnittet som kjører kan fortsette å bruke adressen det fant for timer siden. Kontroller hva grensesnittet bruker før du bytter nøkler eller rører tunnelområdet.

Navnet slås opp én gang, ikke fortløpende

Grunnleggende WireGuard-konfigurasjon tar et endepunkt som adresse og port, og verktøyet som reiser et grensesnitt slår opp et vertsnavn i det øyeblikket. Ingenting i basisprotokollen spør DNS etter en tidsplan, og en klientapplikasjon kan legge sin egen oppfriskningsatferd oppå. Å notere den oppslåtte adressen, familien og porten ved siden av navnet gjør gapet synlig. Uten den noten ser konfigurasjonen riktig ut mens grensesnittet snakker med et annet sted.

Det finnes én ekte automatisk oppdatering, og den er verdt å kjenne fordi den ligner en DNS-oppfrisking uten å være det. Et peer-endepunkt kan flytte seg når korrekt autentisert trafikk kommer fra en ny adresse, noe som er roaming og ikke navneoppslag. Den følger peeren, så den kan ikke oppdage en urelatert ny server som det gamle endepunktet aldri kontaktet.

Sammenlign oppføringen med adressen som brukes

Spør på det dokumenterte navnet gjennom resolveren klienten bruker, og spør deretter grensesnittet hvilket endepunkt det holder. De to svarene er sammenligningen som avgjør resten av denne siden:

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

Manualen for wg(8) dokumenterer show-underkommandoene som disse linjene bruker. Sammenlign også adressefamilien, ikke bare adressen, fordi en oppføring som har fått en IPv6-oppføring er en annen sammenligning enn en der IPv4-adressen er endret. Hvis endepunktet avviker fra oppføringen, kjører grensesnittet på utdatert informasjon, og navnet var aldri problemet. Hvis de stemmer og tunnelen fortsatt feiler, gå til lytteren og reglene i stedet for til profilen.

Tidsstempelet for håndtrykket står i den blokken fordi endepunktet alene ikke sier om peeren nås. Et utdatert tidsstempel ved siden av et riktig endepunkt er et veiproblem, ikke et oppslagsproblem, og den forskjellen endrer hva du rører neste gang.

Start på nytt gjennom administratoren for grensesnittet

Når endepunktet er bekreftet utdatert, oppfrisk det gjennom mekanismen som eier grensesnittet i stedet for å redigere den kjørende konfigurasjonen. For et grensesnitt startet av wg-quick er det en ned og opp, for en systemd-enhet er det en omstart, og for et grensesnitt som eies av en administrator er det en endring gjort i den administratoren, fordi en redigering under kjøring overskrives ved neste bruk:

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

Bekreft deretter at den nye lytteren og identiteten dens er tjenesten du mente. En DNS-flytting er ikke en identitetsendring, så den bør aldri være anledningen til å stole på en nøkkel du ikke har verifisert. Hvis grensesnittet nå rapporterer den nye adressen og fortsatt ikke gir noe håndtrykk, har feilen flyttet seg til den nye nettverksveien eller lytteren, noe som er fremgang og ikke den samme feilen to ganger.

Håndtrykk først, deretter datastien

Skill de to utfallene før du velger en sjekkliste. Et håndtrykk som lykkes under en applikasjon som feiler, er et datasti-problem: ruter, tillatte prefikser eller DNS inne i tunnelen. Et håndtrykk som aldri skjer, er et tilgjengelighets- eller identitetsproblem ved endepunktet. Å blande de to gir en rapport ingen kan gjenskape, og en endringslogg med tre urelaterte rettelser.

Noter navnet, den oppslåtte adressen, endepunktet som brukes og om håndtrykket ble fullført. De fire faktaene svarer på spørsmålet denne feilen stadig stiller, og gjør neste forekomst til en sjekk på to minutter. Navnevedlikehold og klientinnføring forblir separate oppgaver: å rette oppføringen utfører ikke innføringen, og å starte grensesnittet på nytt retter ikke en oppføring som fortsatt er feil.