OpenVPN sender DNS, men din resolver ser det måske aldrig

Klientloggen viser den sendte DNS-server, tunnelen er forbundet, og et internt navn slår stadig ikke op. Der er intet i vejen med selve afsendelsen. Indstillingen ankom, og operativsystemets resolver brugte den aldrig, fordi OpenVPN på de fleste Unix-klienter leverer værdien og overlader anvendelsen til platformen.

Symptomet: loggen viser DNS, og navnene fejler stadig

OpenVPN dhcp-option bærer DNS- og domæneoplysninger, og klienten registrerer, hvad den modtog. I nogle implementeringer anvender klienten indstillingerne internt; i andre eksporterer den dem til et integrationsscript eller en netværkstjeneste. Loglinjen beskriver kun den første halvdel af historien. Den anden halvdel sker et sted, klienten ikke styrer. Det er der, fejlen normalt bor.

Derfor optræder en forbundet tunnel og et fejlende internt navn så ofte sammen. Værdien er der, forbrugeren mangler eller er fejlkonfigureret, og resolveren bruger stille den offentlige server, den brugte før forbindelsen.

Modtaget er ikke anvendt

En klient kan logge en sendt DNS-værdi, mens systemets resolver stadig ejes af en anden tjeneste. En browser kan også have sin egen politik for krypteret DNS, der helt omgår systemets resolver, hvilket giver den mindeværdige situation, hvor én applikation slår interne navne op og en anden ikke.

Tjek implementeringens understøttede integration i stedet for at antage, at enhver Unix-klient omskriver den samme fil. Den antagelse er grunden til, at folk redigerer en resolverkonfiguration, som intet læser.

Find resolverens ejer pr. platform

På Windows kan navneopløsningspolitiktabellen sende bestemte suffikser til bestemte servere, og VPN-klienten kan installere regler der. Tjek politikken, ikke kun adapterens DNS-liste. På Linux kan NetworkManager eller systemd-resolved eje konfigurationen, og hvilken af dem der ejer den, afgør, hvad en genopkobling bevarer.

Læs den effektive tilstand med det værktøj, der faktisk svarer på forespørgsler: resolvectl query internal.example.net på en systemd-resolved-vært eller platformens ækvivalent. Sammenlign derefter det svar med den DNS-server, klientloggen hævder at have sendt.

Undgå at køre flere tjenester, der overskriver resolverindstillinger uden koordinering. To ejere giver et resultat, der ser periodisk ud, og hver genopkobling ser ud til at rette eller ødelægge det tilfældigt.

Scripts og foreign_option

OpenVPN eksporterer sendte indstillinger til scripts via variabler med navnet foreign_option_N, og et script kan oversætte dem til resolverkommandoer. Den ordning er en understøttet integration, ikke automatisk adfærd, og den skal installeres og kaldes på klienten.

Hvis du er afhængig af et script, så log dets kørsel og dets exitstatus. Et script, der kører, men fejler lydløst, efterlader det samme symptom som intet script, og det er sværere at bemærke, fordi konfigurationen ser komplet ud. Tjek scriptets output, ikke scriptfilen. En fil, der findes, er ikke et script, der kørte.

Test navnet, ikke loggen

Spørg klienten om et kun internt værtsnavn efter forbindelsen, spørg derefter om et offentligt navn, og tjek så, hvilken server der svarede. I et fungerende setup kommer de to svar fra forskellige steder, og begge bør passe til designet.

Hvis navnet slår op, men tjenesten fejler, så gå videre til routing og applikationsadgang i stedet for at ændre DNS igen. OpenVPN-manualen dokumenterer dhcp-option og scriptmiljøet; brug den til at bekræfte, hvad din klient forventes at anvende, før du redigerer endnu en resolverfil.