DNS som OpenVPN skickar ignoreras: vilken komponent tillämpar det

Loggen visar alternativet servern skickade, tunneln är uppe, och interna namn misslyckas fortfarande. En direkt fråga till resolvern svarar, alltså är servern i ordning, men varje program fortsätter att fråga den lokala routern. Det som nådde klienten är ett erbjudande, inte en ändring i resolvern, och komponenten som äger namnmatchningen skiljer sig på Linux, Windows och macOS. När du skiljer alternativet från ägaren täcker fyra fel nästan varje rapport: ingen hook, två konkurrerande hooks, delad DNS som fungerar som designat, eller ett kort namn som behöver ett suffix och inte en server.

Ett skickat alternativ är ett erbjudande, inte en installation

På servern beskriver två direktiv avsikt, inte effekt:

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

Klienten får ingen konfigurerad resolver. Den får miljövariabler, foreign_option_1 och vidare, en per skickad rad, och något lokalt måste läsa dem och skriva om operativsystemets resolvertillstånd. På Linux gör inget det som standard, därför kan en korrekt server och en ansluten klient fortfarande matcha namn via LAN.

Mellan de två ändarna finns tre steg: skicket måste komma fram, klienten måste exponera det, och en hook måste tillämpa det. Läs det mittersta steget i klientloggen och det sista i resolvertillståndet, aldrig tvärtom, för en loggrada bevisar bara de två första.

Bekräfta att skicket kom fram och hitta ägaren

Börja med att namnge startaren: ett bart openvpn kommando, en systemd-instans, NetworkManager eller en leverantörsklient. Det avgör var en hook kan bo. På en värd med systemd-resolved, resolvectl status listar varje länk med de DNS-servrar och sökdomäner den faktiskt använder, och tunnel-länken heter inte alltid tun0.

Om den skickade adressen syns i loggen men inte på någon länk saknas integrationen. Om den syns på länken och frågorna ändå går ut någon annanstans är problemet vilka frågor som väljer den länken. NetworkManager dns=dnsmasq i filen /etc/NetworkManager/NetworkManager.conf kör en lokal vidarebefordrare som medvetet tillämpar delad DNS: namn inom VPN-domänen går till VPN-resolvern, allt annat behåller sin tidigare väg. Det beteendet ser ut som ett fel när du väntade dig att all trafik skulle flytta; kontrollera inställningarna per anslutning med nmcli connection show "My VPN", där ipv4.dns och ipv4.dns-search håller värdena bakom det enheten rapporterar, innan du kallar det trasigt. Om varje fråga verkligen ska nå VPN-resolvern, ta bort dns=dnsmasq från NetworkManager.conf och starta om NetworkManager, vilket ger namnmatchningen tillbaka till anslutningens inställningar; annars behåll delad DNS och rätta den skickade domänlistan.

Linux: ge alternativen till resolvern

Distributionspaket levererar en hook för detta, och klienten måste få köra den. En typisk uppsättning på en värd utan systemd-resolved:

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

Med systemd-resolved ändrar det äldre resolv.conf-skriptet kanske inget viktigt, eftersom stub-resolvern håller tillstånd per länk. update-systemd-resolved hjälparen dokumenterar en hookform som använder up-restart och down-pre, vilket spelar roll när ett gränssnitt överlever ett enda anslutningsförsök. Vad du än väljer måste en komponent äga tillståndet. Att lägga till en orelaterad hook bredvid NetworkManager ger två skribenter till samma länk, och resultatet beror då på ordningen och inte på din konfiguration.

Det finns också fallet där NetworkManager ignorerade det skickade alternativet helt tills serveradressen skrevs in i anslutningens IPv4-inställningar, och därefter visade resolvertillståndet att den användes. Det är värt att prova innan du skriver om skript, eftersom det flyttar problemet från en shell-hook till anslutningsprofilen som redan bär tunneln.

Windows och macOS tillämpar olika delar

Windows-klienten sätter faktiskt VPN-adapterns DNS-servrar, men Windows väljer fortfarande gränssnitt efter metrik och behöver fortfarande ett suffix för att expandera ett kort namn. Bekräfta adapterns tillstånd och inte profilen:

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

Om adressen saknas, sätt den med Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, lägg sedan till suffixet i adapterns IPv4-egenskaper så att fileserver blir fileserver.corp.example. Ett SearchList värde för hela maskinen under Tcpip\Parameters gör samma sak. Där det långa namnet matchas och det bara inte, är resolvern redan korrekt och söklistan är boven. Rättelserna, i ordning: skicka en DOMAIN så att klienten lär sig suffixet, lägg till suffixet i adapterns eller anslutningens söklista, och fäst namnet tillfälligt i hosts, eller LMHOSTS på Windows; NetBIOS-bläddring korsar inte en router, så utsändningen som hittar ett kort namn på kontorets LAN når aldrig en tunnelklient.

block-outside-dns block-outside-dns är Windows-klientbeteende, inte en flyttbar profilrad, och att kopiera den till en Linux- eller macOS-profil återskapar den inte där. Om offentliga namn fungerar och interna misslyckas på Windows, jämför adapterordningen under Avancerade inställningar med ipconfig /all. På macOS tillhör resolverordningen per tjänst systemet, använd därför scutil --dns för att se vilken resolver som frågas för vilken domän, och behandla varje enskild rapporterad profilrättelse som klientberoende och inte generell.

En virtuell maskin på samma laptop ärver inget av detta. Ge gästen en egen resolverpost för den interna domänen, eller låt hypervisorns NAT vidarebefordra dess frågor genom värden, vilket bara är korrekt så länge värdens tunnel är uppe.

Historiken är den tredje orsaken. DNS-servrar eller suffixinställningar från en tidigare profil kan överleva återanslutningar, så när adaptern ser korrekt ut och uppslag fortfarande misslyckas, jämför den levande adaptern med Get-VpnConnection och rensa eller skriv över den inaktuella posten innan du rör servern.

Bevisa vart frågan tog vägen

En inspelning under ett uppslag avgör saken: tcpdump -ni eth0 port 53 visar frågor på det fysiska gränssnittet, vilket betyder att de lämnar tunneln och att resolvern aldrig byttes. dig @10.8.0.1 name.corp.example skiljer sedan de två återstående fallen. Om den direkta frågan svarar fungerar resolvern och klienten använder den inte; om den tar timeout är resolvern oåtkomlig genom tunneln och ingen lokal ändring hjälper.

Om resolvern som fortfarande används är den leverantören delade ut, krypterar tunneln trafiken medan namnen förblir synliga för den leverantören. Det är en läckagefråga och inte en funktionell, och samma inspelning svarar på den: en fråga på det fysiska gränssnittet går till någon utanför tunneln.

Tillgänglighet omfattar brandväggen på VPN-värden, som måste tillåta UDP och TCP 53 från poolen. En stängd port ser exakt ut som ett trasigt skick, och det gör också en resolver som bara svarar inifrån tunnelnätet. Upprepa inspelningen efter en frånkoppling och återanslutning, eftersom inställningar som dyker upp vid första anslutningen och försvinner vid den andra är ett livscykelfel i hooken, inte ett saknat alternativ.

Håll en ägare och verifiera i ordning

Ett skript som skriver om adapterns DNS utifrån ett antaget tunneltillstånd duplicerar konfiguration som profilen redan bär, och det misslyckas tyst första gången antagandet är fel. Föredra anslutningens egna DNS-inställningar eller en dokumenterad hook, och anteckna vilken du valde så att nästa person inte lägger till en andra.

Stäng slingan med fyra kontroller: den skickade adressen finns på tunnel-länken, det interna namnet matchas som fullt kvalificerat namn, samma namn matchas utan suffixet, och båda gäller fortfarande efter en återanslutning. En inspelning säger vilken av de fyra som misslyckades. Handboken för OpenVPN 2.6 listar dhcp-option och skriptdirektiven med sina plattformsanteckningar.