wg-quick ødelegger DNS ved tilkobling: les oppsettfeilen
DNS-linjen tilhører oppsetthjelperen, ikke peer-protokollen. Les den første feilen, kontroller resolver-ruten og bekreft at oppryddingen gjenoppretter den gamle tilstanden.
Tunnelen kommer opp, håndtrykket fullføres, og navneoppslaget stopper. Ingenting i peer-konfigurasjonen er endret, fordi DNS-linjen aldri var en del av peer-konfigurasjonen. Den tilhører oppsetthjelperen, som betyr at feilen bor i vertens resolver-verktøy og ikke i WireGuards nøkler.
Les den første meldingen hjelperen skrev ut, ikke den siste, og forskjellen mellom et manglende verktøy og en utilgjengelig server blir tydelig.
DNS-linjen er en hjelperfunksjon
Kjernefeltene i konfigurasjonen beskriver peers, nøkler og tillatte adresser. Navneoppslag legges på toppen av skriptet som reiser grensesnittet, og hver implementasjon gjør det forskjellig. En skrivebordsklient kan styre DNS via sin egen tjeneste, et distribusjonsskript kan kalle ett av flere resolver-verktøy, og en container gjør kanskje ingen av delene. Konfigurasjonsfilen kan ikke fortelle deg hvilken av disse veiene som er i spill.
Derfor kan en konfigurasjonsfil være gyldig for protokollen og likevel feile under oppsettet: feilen tilhører en hook som protokollen aldri ser.
Å skrive et utvidet felt i en kjernekonfigurasjon og forvente at protokollverktøyet godtar det, skaper samme forvirring fra motsatt retning. De to parserne leser forskjellige filer.
Å vite hvilken som kjører er det første diagnostiske trinnet, og det er vanligvis synlig i kommandoen du skrev, ikke i konfigurasjonsfilen.
Les den første feilen hjelperen skriver ut
Reis grensesnittet i forgrunnen og les utdata i rekkefølge. Et manglende resolver-verktøy, en mislykket hook og en utilgjengelig server stopper den samme kommandoen på forskjellige punkter, og hver har sin egen reparasjon.
wg-quick up wg0
resolvectl status wg0
ip route get 10.66.0.1
Den første kommandoen rapporterer oppsettets fremdrift, den andre viser hvilke servere grensesnittet nå krever, og den tredje viser om resolver-adressen faktisk er nåbar gjennom tunnelen. En resolver som er konfigurert men ikke rutbar, gir tidsavbrudd i stedet for konfigurasjonsfeil, og derfor hører de to kontrollene sammen. Å lese bare statusutdata gir en selvsikker og feil konklusjon.
Hvis oppsettet fullføres og navneoppslaget fortsatt feiler, sammenlign resolveren hjelperen installerte med den nettverket brukte før. En privat resolver trenger en rute gjennom tunnelen, og en konfigurasjon som lister den uten å dekke prefikset, lar hver spørring vente.
Hvilken resolver verten faktisk har
Moderne Linux-verter kjører ofte en lokal stub-resolver, så adressen hjelperen installerer forbrukes av den stubben og ikke av applikasjonene direkte. Å redigere en generert fil for hånd kan se ut til å virke til neste gjenoppkobling, da hjelperen skriver den på nytt.
Bruk den støttede integrasjonen for distribusjonen og la én komponent eie resolver-tilstanden. To eiere lager det samme kappløpet som to eiere av en grensesnittadresse, og symptomet er en vert som løser riktig i noen minutter etter hver endring.
Interne navn fortjener sin egen kontroll. En offentlig resolver kan gjenopprette vanlig surfing mens hvert bedriftsnavn feiler, som er det motsatte av det tunnelen var ment for. Spør den tiltenkte serveren om det interne navnet før du konkluderer med at DNS er reparert.
Opprydding er like viktig som oppsett
Ta grensesnittet ned og undersøk resolver-tilstanden igjen. En hjelper som gjenoppretter den forrige konfigurasjonen etterlater verten brukbar; en som etterlater sine egne servere skaper den neste feilen, ofte timer senere når tunnelen for lengst er borte.
Utdatert tilstand er lett å få øye på når man først leter. En resolver-liste kan peke på en adresse på et grensesnitt som ikke finnes lenger, og et søkedomene kan overleve et nettverk du forlot i morges. Enhver av dem gjør neste tilkobling uforutsigbar, og ingen av dem vises i tunnelens eget statusutdata. Kontrollen tar ti sekunder og sparer neste person en time.
Hold diagnosen atskilt fra reparasjonen. Hvis hver destinasjon feiler og ikke bare navneoppslag, er ruter og videresending de mistenkte, og DNS-linjen er en distraksjon. wg-quick-håndboken dokumenterer hvilke felt den håndterer og hvilke som tilhører protokollen, og den grensen er hele svaret på de fleste av disse rapportene.