DNS som OpenVPN dytter blir ignorert: hvilken komponent bruker det

Loggen viser alternativet serveren dyttet, tunnelen er oppe, og interne navn feiler fortsatt. Et direkte spørsmål til resolveren svarer, så serveren er i orden, men hver applikasjon fortsetter å spørre den lokale ruteren. Det som nådde klienten, er et tilbud, ikke en endring i resolveren, og komponenten som eier navneoppslaget er forskjellig på Linux, Windows og macOS. Når du skiller alternativet fra eieren, dekker fire feil nesten hver rapport: ingen hook, to konkurrerende hooks, delt DNS som virker etter hensikten, eller et kort navn som trenger et suffiks og ikke en server.

Et dyttet alternativ er et tilbud, ikke en installasjon

På serveren beskriver to direktiver hensikt, ikke effekt:

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

Klienten får ikke en konfigurert resolver. Den får miljøvariabler, foreign_option_1 og videre, én per dyttet linje, og noe lokalt må lese dem og skrive om resolvertilstanden til operativsystemet. På Linux gjør ingenting dette som standard, og derfor kan en korrekt server og en tilkoblet klient fortsatt slå opp navn via LAN.

Mellom de to endene ligger tre trinn: dyttet må komme frem, klienten må eksponere det, og en hook må bruke det. Les det midterste trinnet i klientloggen og det siste i resolvertilstanden, aldri omvendt, for en logglinje beviser bare de to første.

Bekreft at dyttet kom frem, og finn eieren

Start med å navngi oppstarteren: en bar openvpn kommando, en systemd-instans, NetworkManager eller en leverandørklient. Det avgjør hvor en hook kan bo. På en vert med systemd-resolved resolvectl status lister hver lenke med DNS-serverne og søkedomenene den faktisk bruker, og tunnel-lenken heter ikke alltid tun0.

Hvis den dyttede adressen vises i loggen men ikke på noen lenke, mangler integrasjonen. Hvis den vises på lenken og spørringene fortsatt går ut andre steder, er problemet hvilke spørringer som velger den lenken. NetworkManager dns=dnsmasq i filen /etc/NetworkManager/NetworkManager.conf kjører en lokal videresender som bevisst implementerer delt DNS: navn i VPN-domenet går til VPN-resolveren, alt annet beholder sin tidligere vei. Denne oppførselen ser ut som en feil når du forventet at all trafikk skulle flytte seg; sjekk innstillingene per tilkobling med nmcli connection show "My VPN", der ipv4.dns og ipv4.dns-search holder verdiene bak det enheten rapporterer, før du kaller den ødelagt. Hvis hver spørring virkelig skal nå VPN-resolveren, fjern dns=dnsmasq fra NetworkManager.conf og start NetworkManager på nytt, noe som gir navneoppslaget tilbake til tilkoblingsinnstillingene; ellers behold delt DNS og rett den dyttede domenelisten.

Linux: gi alternativene til resolveren

Distribusjonspakker leverer en hook for dette, og klienten må få lov til å kjøre den. Et typisk oppsett på en vert uten systemd-resolved:

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

Med systemd-resolved endrer det eldre resolv.conf-skriptet kanskje ingenting viktig, fordi stub-resolveren holder tilstand per lenke. update-systemd-resolved hjelperen dokumenterer en hook-form som bruker up-restart og down-pre, noe som betyr noe når et grensesnitt overlever ett tilkoblingsforsøk. Uansett hva du velger, må én komponent eie tilstanden. Å legge til en uvedkommende hook ved siden av NetworkManager gir to skribenter til samme lenke, og resultatet avhenger da av rekkefølgen og ikke av konfigurasjonen din.

Det finnes også tilfellet der NetworkManager ignorerte det dyttede alternativet helt til serveradressen ble skrevet inn i tilkoblingens IPv4-innstillinger, og deretter viste resolvertilstanden at den var i bruk. Det er verdt et forsøk før du skriver om skript, fordi det flytter problemet fra en shell-hook til tilkoblingsprofilen som allerede bærer tunnelen.

Windows og macOS bruker forskjellige deler

Windows-klienten setter faktisk DNS-serverne til VPN-adapteren, men Windows velger fortsatt grensesnitt etter metrikk og trenger fortsatt et suffiks for å utvide et kort navn. Bekreft adaptertilstanden og ikke profilen:

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

Hvis adressen mangler, sett den med Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, legg deretter til suffikset i adapterens IPv4-egenskaper slik at fileserver blir fileserver.corp.example. En SearchList verdi for hele maskinen under Tcpip\Parameters gjør det samme. Der det lange navnet slås opp og det bare ikke, er resolveren allerede korrekt, og søkelisten er feilen. Rettelsene, i rekkefølge: dytt en DOMAIN slik at klienten lærer suffikset, legg til suffikset i søkelisten til adapteren eller tilkoblingen, og fest navnet midlertidig i hosts, eller LMHOSTS på Windows; NetBIOS-blaing krysser ikke en ruter, så kringkastingen som finner et kort navn på kontorets LAN når aldri en tunnelklient.

block-outside-dns block-outside-dns er Windows-klientatferd, ikke en flyttbar profillinje, og å kopiere den til en Linux- eller macOS-profil gjenskaper den ikke der. Hvis offentlige navn virker og interne feiler på Windows, sammenlign adapterrekkefølgen under Avanserte innstillinger med ipconfig /all. På macOS tilhører resolverrekkefølgen per tjeneste systemet, så bruk scutil --dns for å se hvilken resolver som spørres for hvilket domene, og behandle enhver enkelt rapportert profilrettelse som klientavhengig og ikke generell.

En virtuell maskin på samme laptop arver ingenting av dette. Gi gjesten sin egen resolveroppføring for det interne domenet, eller la hypervisorens NAT videresende spørringene gjennom verten, noe som bare er riktig så lenge vertens tunnel er oppe.

Historikken er den tredje årsaken. DNS-servere eller suffiksinnstillinger fra en tidligere profil kan overleve gjentilkoblinger, så når adapteren ser riktig ut og oppslag fortsatt feiler, sammenlign den levende adapteren med Get-VpnConnection og slett eller overskriv den utdaterte oppføringen før du rører serveren.

Bevis hvor spørringen gikk

En opptak under ett oppslag avgjør saken: tcpdump -ni eth0 port 53 viser spørringer på det fysiske grensesnittet, som betyr at de forlater tunnelen og at resolveren aldri ble byttet. dig @10.8.0.1 name.corp.example skiller deretter de to gjenværende tilfellene. Hvis det direkte spørsmålet svarer, virker resolveren og klienten bruker den ikke; hvis det går ut på tid, er resolveren utilgjengelig gjennom tunnelen og ingen lokal endring hjelper.

Hvis resolveren som fortsatt brukes er den leverandøren delte ut, krypterer tunnelen trafikken mens navnene forblir synlige for den leverandøren. Det er et lekkasjespørsmål og ikke et funksjonelt, og det samme opptaket svarer på det: en spørring på det fysiske grensesnittet går til noen utenfor tunnelen.

Tilgjengelighet omfatter brannmuren på VPN-verten, som må tillate UDP og TCP 53 fra poolen. En stengt port ser nøyaktig ut som et ødelagt dytt, og det gjør også en resolver som bare svarer fra innsiden av tunnelnettet. Gjenta opptaket etter én frakobling og gjentilkobling, fordi innstillinger som dukker opp ved første tilkobling og forsvinner ved den andre, er en livssyklusfeil i hooken og ikke et manglende alternativ.

Hold én eier og verifiser i rekkefølge

Et skript som skriver om adapterens DNS basert på en gjettet tunnelstatus, dupliserer konfigurasjon profilen allerede bærer, og det feiler stille første gang gjetningen er feil. Foretrekk tilkoblingens egne DNS-innstillinger eller én dokumentert hook, og noter hvilken du valgte slik at neste person ikke legger til en ny.

Lukk sløyfen med fire kontroller: den dyttede adressen til stede på tunnel-lenken, det interne navnet slått opp som fullt kvalifisert navn, samme navn slått opp uten suffikset, og begge fortsatt sanne etter én gjentilkobling. Ett opptak forteller deg hvilken av de fire som feilet. OpenVPN 2.6-håndboken lister dhcp-option og skriptdirektivene med sine plattformnotater.