OpenVPN sender DNS, men resolveren din ser det kanskje aldri

Klientloggen viser den sende DNS-serveren, tunnelen er tilkopla, og eit internt namn løyser framleis ikkje. Ingenting er øydelagt i sjølve sendinga. Alternativet kom fram, og resolveren til operativsystemet brukte det aldri, fordi OpenVPN på dei fleste Unix-klientar leverer verdien og overlèt bruken til plattforma.

Symptomet: loggen viser DNS, og namna feilar framleis

OpenVPN dhcp-option ber DNS- og domeninformasjon, og klienten registrerer det han fekk. I nokre implementasjonar brukar klienten innstillingane internt; i andre eksporterer han dei til eit integrasjonsskript eller ei nettverksteneste. Logglinja skildrar berre fyrste halvdelen av historia. Andre halvdelen skjer ein stad klienten ikkje kontrollerer. Det er der feilen vanlegvis bur.

Difor opptrer ein tilkopla tunnel og eit feilande internt namn så ofte saman. Verdien finst, forbrukaren manglar eller er feilkonfigurert, og resolveren brukar stille den offentlege serveren han brukte før tilkoplinga.

Motteke er ikkje brukt

Ein klient kan logge ein send DNS-verdi medan systemresolveren framleis er eigd av ei anna teneste. Ein nettlesar kan òg ha sin eigen policy for kryptert DNS som omgår systemresolveren heilt, noko som gir den minneverdige situasjonen der éin applikasjon løyser interne namn og ein annan ikkje.

Sjekk den støtta integrasjonen til implementasjonen i staden for å anta at kvar Unix-klient skriv om den same fila. Den antekninga er grunnen til at folk redigerer ein resolverkonfigurasjon som ingenting les.

Finn eigaren til resolveren per plattform

På Windows kan namneoppløysingspolitikk-tabellen sende bestemte suffiks til bestemte serverar, og VPN-klienten kan installere reglar der. Sjekk politikken, ikkje berre DNS-lista til adapteren. På Linux kan NetworkManager eller systemd-resolved eige konfigurasjonen, og kven av dei som eig han avgjer kva ei attkopling bevarer.

Les den effektive tilstanden med verktøyet som faktisk svarar på spørjingar: resolvectl query internal.example.net på ein systemd-resolved-vert, eller ekvivalenten til plattforma. Samanlikn deretter svaret med DNS-serveren klientloggen hevdar å ha sendt.

Unngå å køyre fleire tenester som overskriv resolverinnstillingar utan koordinering. To eigarar gir eit resultat som verkar periodisk, og kvar attkopling ser ut til å reparere eller øydeleggje det tilfeldig.

Skript og foreign_option

OpenVPN eksporterer sende alternativ til skript via variablar kalla foreign_option_N, og eit skript kan omsetje dei til resolverkommandoar. Den ordninga er ein støtta integrasjon, ikkje automatisk åtferd, og ho må installerast og kallast på klienten.

Viss du er avhengig av eit skript, loggfør køyringa og utgangsstatusen. Eit skript som køyrer men feilar lydlaust, etterlèt same symptom som ingen skript, og det er vanskelegare å leggje merke til fordi konfigurasjonen ser komplett ut. Sjekk utdata frå skriptet, ikkje skriptfila. Ei fil som finst er ikkje eit skript som har køyrt.

Test namnet, ikkje loggen

Spør klienten om eit berre internt vertsnamn etter tilkopling, spør deretter om eit offentleg namn, og sjekk kva server som svara. I eit fungerande oppsett kjem dei to svara frå ulike stader, og begge bør stemme med designet.

Viss namnet løyser men tenesta feilar, gå vidare til ruting og applikasjonstilgang i staden for å endre DNS igjen. OpenVPN-handboka dokumenterer dhcp-option og skriptmiljøet; bruk ho til å stadfeste kva klienten din er venta å bruke før du redigerer endå ei resolverfil.