wg-quick ødelægger DNS ved forbindelse: læs opsætningsfejlen

Tunnelen kommer op, håndtrykket fuldføres, og navneopløsningen stopper. Intet i peer-konfigurationen er ændret, fordi DNS-linjen aldrig var en del af peer-konfigurationen. Den hører til opsætningshjælperen, hvilket betyder, at fejlen bor i værtens resolver-værktøjer og ikke i WireGuards nøgler.

Læs den første besked, hjælperen udskrev, ikke den sidste, og forskellen mellem et manglende værktøj og en utilgængelig server bliver tydelig.

DNS-linjen er en hjælperfunktion

Kernens konfigurationsfelter beskriver peers, nøgler og tilladte adresser. Navneopløsning lægges ovenpå af det script, der rejser grænsefladen, og hver implementering gør det forskelligt. En skrivebordsklient kan styre DNS via sin egen tjeneste, et distributionsscript kan kalde et af flere resolver-værktøjer, og en container kan gøre ingen af delene. Konfigurationsfilen kan ikke fortælle dig, hvilken af disse veje der er i spil.

Derfor kan en konfigurationsfil være gyldig for protokollen og alligevel fejle under opsætningen: fejlen hører til et hook, som protokollen aldrig ser.

At skrive et udvidet felt i en kernekonfiguration og forvente, at protokollens værktøj accepterer det, skaber samme forvirring fra den modsatte retning. De to parsere læser forskellige filer.

At vide, hvilken der kører, er det første diagnostiske skridt, og det er normalt synligt i den kommando, du skrev, snarere end i konfigurationsfilen.

Læs den første fejl, hjælperen udskriver

Rejs grænsefladen i forgrunden og læs outputtet i rækkefølge. Et manglende resolver-værktøj, et mislykket hook og en utilgængelig server stopper den samme kommando på forskellige punkter, og hver har sin egen reparation.

wg-quick up wg0
resolvectl status wg0
ip route get 10.66.0.1

Den første kommando rapporterer opsætningsfremdrift, den anden viser, hvilke servere grænsefladen nu kræver, og den tredje viser, om resolver-adressen faktisk kan nås gennem tunnelen. En resolver, der er konfigureret men ikke rutbar, giver timeouts i stedet for konfigurationsfejl, og derfor hører de to kontroller sammen. At læse kun statusoutputtet giver en selvsikker og forkert konklusion.

Hvis opsætningen er fuldført, og navneopløsningen stadig fejler, så sammenlign den resolver, hjælperen installerede, med den, netværket brugte før. En privat resolver kræver en rute gennem tunnelen, og en konfiguration, der lister den uden at dække dens præfiks, lader hver forespørgsel vente.

Hvilken resolver værten faktisk har

Moderne Linux-værter kører ofte en lokal stub-resolver, så den adresse, hjælperen installerer, forbruges af den stub i stedet for af programmerne direkte. At redigere en genereret fil i hånden kan se ud til at virke indtil næste genopkobling, hvor hjælperen skriver den igen.

Brug den understøttede integration til distributionen, og lad én komponent eje resolver-tilstanden. To ejere skaber det samme kapløb som to ejere af en grænsefladeadresse, og symptomet er en vært, der opløser korrekt i et par minutter efter hver ændring.

Interne navne fortjener deres egen kontrol. En offentlig resolver kan gendanne almindelig browsing, mens hvert virksomhedsnavn fejler, hvilket er det modsatte af, hvad tunnelen var til. Spørg den tilsigtede server om det interne navn, før du konkluderer, at DNS er rettet.

Oprydning er lige så vigtig som opsætning

Tag grænsefladen ned, og undersøg resolver-tilstanden igen. En hjælper, der gendanner den forrige konfiguration, efterlader værten brugbar; en, der efterlader sine egne servere, skaber den næste fejl, ofte timer senere når tunnelen for længst er væk.

Forældet tilstand er let at få øje på, når man først leder efter den. En resolver-liste kan pege på en adresse på en grænseflade, der ikke findes længere, og et søgedomæne kan overleve et netværk, du forlod i morges. Enhver af dem får den næste forbindelse til at opføre sig uforudsigeligt, og ingen af dem vises i tunnelens eget statusoutput. Kontrollen tager ti sekunder og sparer den næste person en time.

Hold diagnosen adskilt fra reparationen. Hvis hver destination fejler i stedet for kun navneopslag, er ruter og videresendelse de mistænkte, og DNS-linjen er en distraktion. wg-quick-manualen dokumenterer, hvilke felter den håndterer, og hvilke der hører til protokollen, og den grænse er hele svaret på de fleste af disse rapporter.