OpenVPN sender DNS, men resolveren din ser det kanskje aldri

Klientloggen viser den sendte DNS-serveren, tunnelen er tilkoblet, og et internt navn løses fortsatt ikke. Ingenting er ødelagt i selve sendingen. Alternativet kom frem, og operativsystemets resolver brukte det aldri, fordi OpenVPN på de fleste Unix-klienter leverer verdien og overlater bruken til plattformen.

Symptomet: loggen viser DNS, og navnene feiler fortsatt

OpenVPN dhcp-option bærer DNS- og domeninformasjon, og klienten registrerer det den mottok. I noen implementasjoner bruker klienten innstillingene internt; i andre eksporterer den dem til et integrasjonsskript eller en nettverkstjeneste. Logglinjen beskriver bare første halvdel av historien. Andre halvdel skjer et sted klienten ikke kontrollerer. Det er der feilen vanligvis bor.

Derfor opptrer en tilkoblet tunnel og et feilende internt navn så ofte sammen. Verdien finnes, forbrukeren mangler eller er feilkonfigurert, og resolveren bruker stille den offentlige serveren den brukte før tilkoblingen.

Mottatt er ikke brukt

En klient kan logge en sendt DNS-verdi mens systemets resolver fortsatt eies av en annen tjeneste. En nettleser kan også ha sin egen policy for kryptert DNS som omgår systemets resolver helt, noe som gir den minneverdige situasjonen der én applikasjon løser interne navn og en annen ikke.

Sjekk implementasjonens støttede integrasjon i stedet for å anta at enhver Unix-klient skriver om den samme filen. Den antakelsen er grunnen til at folk redigerer en resolverkonfigurasjon som ingenting leser.

Finn resolverens eier per plattform

På Windows kan navneoppløsningspolitikk-tabellen sende bestemte suffikser til bestemte servere, og VPN-klienten kan installere regler der. Sjekk politikken, ikke bare adapterens DNS-liste. På Linux kan NetworkManager eller systemd-resolved eie konfigurasjonen, og hvilken av dem som eier den avgjør hva en gjenoppkobling bevarer.

Les den effektive tilstanden med verktøyet som faktisk svarer på spørringer: resolvectl query internal.example.net på en systemd-resolved-vert, eller plattformens ekvivalent. Sammenlign deretter svaret med DNS-serveren klientloggen hevder å ha sendt.

Unngå å kjøre flere tjenester som overskriver resolverinnstillinger uten koordinering. To eiere gir et resultat som virker periodisk, og hver gjenoppkobling ser ut til å reparere eller ødelegge det tilfeldig.

Skript og foreign_option

OpenVPN eksporterer sendte alternativer til skript via variabler kalt foreign_option_N, og et skript kan oversette dem til resolverkommandoer. Den ordningen er en støttet integrasjon, ikke automatisk atferd, og den må installeres og kalles på klienten.

Hvis du er avhengig av et skript, loggfør kjøringen og utgangsstatusen. Et skript som kjører men feiler lydløst, etterlater samme symptom som ingen skript, og det er vanskeligere å legge merke til fordi konfigurasjonen ser komplett ut. Sjekk skriptets utdata, ikke skriptfilen. En fil som finnes er ikke et skript som har kjørt.

Test navnet, ikke loggen

Spør klienten om et bare internt vertsnavn etter tilkobling, spør deretter om et offentlig navn, og sjekk hvilken server som svarte. I et fungerende oppsett kommer de to svarene fra forskjellige steder, og begge bør stemme med designet.

Hvis navnet løses men tjenesten feiler, gå videre til ruting og applikasjonstilgang i stedet for å endre DNS igjen. OpenVPN-håndboken dokumenterer dhcp-option og skriptmiljøet; bruk den til å bekrefte hva klienten din forventes å bruke før du redigerer nok en resolverfil.