Door OpenVPN gepushte DNS wordt genegeerd: welke component past hem toe

Het log toont de optie die de server pushte, de tunnel staat, en interne namen falen nog steeds. Een rechtstreekse query aan de resolver antwoordt, dus de server is in orde, maar elke toepassing blijft de lokale router vragen. Wat bij de client aankwam is een aanbod, geen wijziging in de resolver, en de component die de naamresolutie bezit verschilt op Linux, Windows en macOS. Zodra u de optie van zijn eigenaar scheidt, dekken vier fouten bijna elk rapport: geen hook, twee concurrerende hooks, gesplitste DNS die werkt zoals ontworpen, of een korte naam die een achtervoegsel nodig heeft en geen server.

Een gepushte optie is een aanbod, geen installatie

Op de server beschrijven twee richtlijnen de bedoeling, niet het effect:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

De client krijgt geen geconfigureerde resolver. Hij krijgt omgevingsvariabelen, foreign_option_1 en volgende, één per gepushte regel, en iets lokaals moet ze lezen en de resolverstatus van het besturingssysteem herschrijven. Op Linux doet niets dat standaard, daarom kunnen een correcte server en een verbonden client nog steeds via het LAN namen oplossen.

Tussen de twee uiteinden liggen drie fasen: de push moet aankomen, de client moet hem blootleggen, en een hook moet hem toepassen. Lees de middelste fase in het clientlog en de laatste in de resolverstatus, nooit omgekeerd, want een logregel bewijst alleen de eerste twee.

Bevestig dat de push aankwam en vind de eigenaar

Begin met de starter te benoemen: een kale openvpn opdracht, een systemd-instantie, NetworkManager of een leveranciersclient. Dat bepaalt waar een hook kan leven. Op een host met systemd-resolved, resolvectl status somt elke link op met de DNS-servers en zoekdomeinen die hij werkelijk gebruikt, en de tunnel-link heet niet altijd tun0.

Als het gepushte adres in het log staat maar op geen enkele link, ontbreekt de integratie. Staat het op de link en verlaten queries nog steeds elders, dan is het probleem welke queries die link kiezen. NetworkManager dns=dnsmasq in het bestand /etc/NetworkManager/NetworkManager.conf draait een lokale doorstuurder die gesplitste DNS bewust toepast: namen binnen het VPN-domein gaan naar de VPN-resolver, al het overige behoudt zijn vorige pad. Dat gedrag lijkt een fout wanneer u verwachtte dat al het verkeer zou verhuizen; controleer de instellingen per verbinding met nmcli connection show "My VPN", waar ipv4.dns en ipv4.dns-search de waarden achter wat het apparaat meldt vasthouden, voordat u het kapot noemt. Als elke query werkelijk de VPN-resolver moet bereiken, verwijder dns=dnsmasq uit NetworkManager.conf en herstart NetworkManager, wat de resolutie teruggeeft aan de verbindingsinstellingen; anders houdt u gesplitste DNS en corrigeert u de gepushte domeinlijst.

Linux: geef de opties aan de resolver

Distributiepakketten leveren hiervoor een hook, en de client moet hem mogen uitvoeren. Een typische opstelling op een host zonder systemd-resolved:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Met systemd-resolved verandert het oudere resolv.conf-script misschien niets belangrijks, omdat de stub-resolver status per link bijhoudt. update-systemd-resolved de helper documenteert een hookvorm die up-restart en down-pre gebruikt, wat telt wanneer een interface één verbindingspoging overleeft. Wat u ook kiest, één component moet de status bezitten. Een ongerelateerde hook naast NetworkManager geeft twee schrijvers aan dezelfde link, en het resultaat hangt dan van de volgorde af en niet van uw configuratie.

Er is ook het geval waarin NetworkManager de gepushte optie volledig negeerde totdat het serveradres in de IPv4-instellingen van de verbinding werd ingevoerd, waarna de resolverstatus hem in gebruik toonde. Dat is een poging waard voordat u scripts herschrijft, omdat het het probleem van een shell-hook naar het verbindingsprofiel verplaatst dat de tunnel al draagt.

Windows en macOS passen verschillende delen toe

De Windows-client stelt wel de DNS-servers van de VPN-adapter in, maar Windows kiest nog steeds een interface op metriek en heeft nog steeds een achtervoegsel nodig om een korte naam uit te breiden. Bevestig de adapterstatus en niet het profiel:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Ontbreekt het adres, stel het in met Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, voeg daarna het achtervoegsel toe aan de IPv4-eigenschappen van de adapter zodat fileserver wordt fileserver.corp.example. Een SearchList waarde voor de hele machine onder Tcpip\Parameters doet hetzelfde. Waar de lange naam oplost en de kale niet, is de resolver al correct en is de zoeklijst de schuldige. De correcties, in volgorde: push een DOMAIN zodat de client het achtervoegsel leert, voeg dat achtervoegsel toe aan de zoeklijst van de adapter of verbinding, en pin de naam als tijdelijke maatregel in hosts, of LMHOSTS op Windows; NetBIOS-browsen gaat niet over een router, dus de broadcast die op het kantoor-LAN een korte naam vindt, bereikt nooit een tunnelclient.

block-outside-dns block-outside-dns is Windows-clientgedrag, geen overdraagbare profielregel, en het kopiëren naar een Linux- of macOS-profiel reproduceert het daar niet. Als openbare namen werken en interne falen op Windows, vergelijk dan de adaptervolgorde onder Geavanceerde instellingen met ipconfig /all. Op macOS hoort de resolvervolgorde per service bij het systeem, gebruik dus scutil --dns om te zien welke resolver voor welk domein wordt gevraagd, en behandel elke afzonderlijk gemelde profielcorrectie als clientafhankelijk en niet als algemeen.

Een virtuele machine op dezelfde laptop erft hier niets van. Geef de gast zijn eigen resolververmelding voor het interne domein, of laat de NAT van de hypervisor zijn queries via de host doorsturen, wat alleen klopt zolang de tunnel van de host staat.

De geschiedenis is de derde oorzaak. DNS-servers of achtervoegselinstellingen uit een eerder profiel kunnen herverbindingen overleven, dus wanneer de adapter correct lijkt en opzoekingen nog steeds falen, vergelijk de levende adapter met Get-VpnConnection en wis of overschrijf de verouderde vermelding voordat u de server aanraakt.

Bewijs waar de query heen ging

Een opname tijdens één opzoeking beslecht de discussie: tcpdump -ni eth0 port 53 toont queries op de fysieke interface, wat betekent dat ze de tunnel verlaten en de resolver nooit is omgeschakeld. dig @10.8.0.1 name.corp.example scheidt daarna de twee resterende gevallen. Als de rechtstreekse query antwoordt, werkt de resolver en gebruikt de client hem niet; als hij verloopt, is de resolver via de tunnel onbereikbaar en helpt geen enkele lokale wijziging.

Als de resolver die nog wordt gebruikt degene is die de provider uitdeelde, versleutelt de tunnel het verkeer terwijl de namen zichtbaar blijven voor die provider. Dat is een lek vraag en geen functionele, en dezelfde opname beantwoordt hem: een query op de fysieke interface gaat naar iemand buiten de tunnel.

Bereikbaarheid omvat de firewall op de VPN-host, die UDP en TCP 53 uit de pool moet toestaan. Een gesloten poort ziet er precies uit als een kapotte push, en een resolver die alleen van binnen het tunnelnetwerk antwoordt ook. Herhaal de opname na één keer verbreken en opnieuw verbinden, want instellingen die bij de eerste verbinding verschijnen en bij de tweede verdwijnen zijn een levenscyclusfout in de hook, geen ontbrekende optie.

Houd één eigenaar en verifieer in volgorde

Een script dat de adapter-DNS herschrijft op basis van een vermoede tunnelstatus dupliceert configuratie die het profiel al draagt, en het faalt stil de eerste keer dat de aanname verkeerd is. Geef de voorkeur aan de eigen DNS-instellingen van de verbinding of één gedocumenteerde hook, en noteer welke u koos zodat de volgende persoon geen tweede toevoegt.

Sluit de lus met vier controles: het gepushte adres aanwezig op de tunnel-link, de interne naam opgelost als volledig gekwalificeerde naam, dezelfde naam opgelost zonder het achtervoegsel, en beide nog waar na één herverbinding. Eén opname vertelt u welke van de vier faalde. De handleiding van OpenVPN 2.6 somt dhcp-option en de scriptrichtlijnen op met hun platformnotities.