OpenVPN pusht DNS, maar je resolver ziet het misschien nooit

Het clientlog toont de gepushte DNS-server, de tunnel is verbonden, en een interne naam lost nog steeds niet op. Er is niets kapot aan het pushen zelf. De optie kwam aan en de resolver van het besturingssysteem gebruikte hem nooit, omdat OpenVPN op de meeste Unix-clients de waarde levert en de toepassing aan het platform overlaat.

Het symptoom: het log toont DNS en namen falen nog steeds

OpenVPN dhcp-option draagt DNS- en domeininformatie, en de client registreert wat hij heeft ontvangen. Bij sommige implementaties past de client die instellingen intern toe; bij andere exporteert hij ze voor een integratiescript of een netwerkdienst. De logregel beschrijft alleen de eerste helft van het verhaal. De tweede helft gebeurt ergens waar de client geen controle over heeft. Daar zit de fout meestal.

Daarom komen een verbonden tunnel en een falende interne naam zo vaak samen voor. De waarde is er, de verbruiker ontbreekt of is verkeerd geconfigureerd, en de resolver blijft stilletjes de publieke server gebruiken die hij voor de verbinding gebruikte.

Ontvangen is niet toegepast

Een client kan een gepushte DNS-waarde loggen terwijl de systeemresolver nog eigendom is van een andere dienst. Een browser kan ook zijn eigen beleid voor versleutelde DNS hebben dat de systeemresolver volledig omzeilt, wat de gedenkwaardige situatie oplevert waarin de ene toepassing interne namen oplost en de andere niet.

Controleer de ondersteunde integratie van de implementatie in plaats van aan te nemen dat elke Unix-client hetzelfde bestand herschrijft. Die aanname is de reden dat mensen een resolverconfiguratie bewerken die niets leest.

Vind de eigenaar van de resolver per platform

Op Windows kan de naamresolutiebeleidstabel specifieke suffixen naar specifieke servers sturen, en de VPN-client kan daar regels installeren. Controleer het beleid, niet alleen de DNS-lijst van de adapter. Op Linux kan NetworkManager of systemd-resolved de configuratie bezitten, en welke van de twee dat doet bepaalt wat een herverbinding behoudt.

Lees de effectieve status met het hulpmiddel dat echt antwoordt op queries: resolvectl query internal.example.net op een systemd-resolved-host, of het equivalent van het platform. Vergelijk dat antwoord dan met de DNS-server die het clientlog zegt te hebben gepusht.

Vermijd meerdere diensten die resolverinstellingen zonder coördinatie overschrijven. Twee eigenaren geven een resultaat dat wisselvallig lijkt, en elke herverbinding lijkt het willekeurig te repareren of te breken.

Scripts en foreign_option

OpenVPN exporteert gepushte opties naar scripts via variabelen met de naam foreign_option_N, en een script kan ze vertalen naar resolveropdrachten. Die regeling is een ondersteunde integratie, geen automatisch gedrag, en ze moet op de client worden geïnstalleerd en aangeroepen.

Als je op een script vertrouwt, log dan de uitvoering en de exitstatus. Een script dat draait maar stil faalt, laat hetzelfde symptoom achter als geen script, en het valt minder op omdat de configuratie compleet lijkt. Controleer de uitvoer van het script, niet het scriptbestand. Een bestand dat bestaat is geen script dat heeft gedraaid.

Test de naam, niet het log

Vraag de client na het verbinden om een alleen-interne hostnaam, vraag dan om een publieke naam, en controleer welke server antwoordde. In een werkende opstelling komen de twee antwoorden van verschillende plekken, en beide zouden bij het ontwerp moeten passen.

Als de naam oplost maar de dienst faalt, ga dan verder naar routering en applicatietoegang in plaats van DNS opnieuw te wijzigen. De OpenVPN-handleiding documenteert dhcp-option en de scriptomgeving; gebruik die om te bevestigen wat je client wordt geacht toe te passen voordat je nog een resolverbestand bewerkt.