DNS skubbet af OpenVPN ignoreres: hvilken komponent anvender det

Loggen viser den indstilling, serveren skubbede, tunnelen er oppe, og interne navne fejler stadig. En forespørgsel direkte til resolveren svarer, så serveren er fin, men hver applikation bliver ved med at spørge den lokale router. Det, der nåede klienten, er et tilbud, ikke en ændring i resolveren, og den komponent, der ejer navneopløsning, er forskellig på Linux, Windows og macOS. Når du skiller indstillingen fra dens ejer, dækker fire fejl næsten hver rapport: ingen hook, to konkurrerende hooks, opdelt DNS der virker efter hensigten, eller et kort navn, der har brug for et suffiks i stedet for en server.

En skubbet indstilling er et tilbud, ikke en installation

På serveren beskriver to direktiver hensigt frem for effekt:

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

Klienten modtager ikke en konfigureret resolver. Den modtager miljøvariabler, foreign_option_1 og videre, én per skubbet linje, og noget lokalt skal læse dem og omskrive operativsystemets resolver-tilstand. På Linux gør intet det som standard, og derfor kan en korrekt server og en tilsluttet klient stadig opløse navne via LAN.

Der ligger tre trin mellem de to ender: push skal nå frem, klienten skal blotlægge det, og en hook skal anvende det. Læs det midterste trin i klientloggen og det sidste trin i resolver-tilstanden, aldrig omvendt, for en loglinje beviser kun de to første.

Bekræft, at push nåede frem, og find ejeren

Start med at navngive starteren: en bar openvpn kommando, en systemd-instans, NetworkManager eller en leverandørklient. Det afgør, hvor en hook kan bo. På en vært med systemd-resolved resolvectl status lister hvert link med de DNS-servere og søgedomæner, det faktisk bruger, og tunnel-linket hedder ikke altid tun0.

Hvis den skubbede adresse optræder i loggen men ikke på noget link, mangler integrationen. Hvis den optræder på linket og forespørgslerne stadig går ud andre steder, er problemet hvilke forespørgsler der vælger det link. NetworkManager dns=dnsmasq i filen /etc/NetworkManager/NetworkManager.conf kører en lokal videresender, der med vilje implementerer opdelt DNS: navne i VPN-domænet går til VPN-resolveren, alt andet beholder sin tidligere vej. Den adfærd ligner en fejl, når du forventede, at al trafik skulle flytte sig; kontroller indstillingerne per forbindelse med nmcli connection show "My VPN", hvor ipv4.dns og ipv4.dns-search holder værdierne bag det, enheden rapporterer, før du kalder den ødelagt. Hvis hver forespørgsel virkelig skal nå VPN-resolveren, skal du fjerne dns=dnsmasq fra NetworkManager.conf og genstarte NetworkManager, hvilket giver navneopløsningen tilbage til forbindelsens indstillinger; ellers behold opdelt DNS og ret den skubbede domæneliste.

Linux: giv indstillingerne til resolveren

Distributionspakker leverer en hook til dette, og klienten skal have lov til at køre den. Et typisk arrangement på en vært uden systemd-resolved:

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

Med systemd-resolved ændrer det ældre resolv.conf-script måske intet væsentligt, fordi stub-resolveren holder tilstand per link. update-systemd-resolved hjælperen dokumenterer en hook-form, der bruger up-restart og down-pre, hvilket betyder noget, når en grænseflade overlever ét forbindelsesforsøg. Uanset hvad du vælger, skal én komponent eje tilstanden. Tilføjer du en uvedkommende hook ved siden af NetworkManager, får du to skribenter til samme link, og så afhænger resultatet af rækkefølgen i stedet for af din konfiguration.

Der er også tilfældet, hvor NetworkManager ignorerede den skubbede indstilling helt, indtil serveradressen blev indtastet i forbindelsens IPv4-indstillinger, hvorefter resolver-tilstanden viste, at den blev brugt. Det er værd at prøve, før du omskriver scripts, fordi det flytter problemet fra en shell-hook til den forbindelsesprofil, der allerede bærer tunnelen.

Windows og macOS anvender forskellige dele

Windows-klienten sætter faktisk VPN-adapterens DNS-servere, men Windows vælger stadig en grænseflade efter metrik og har stadig brug for et suffiks for at udvide et kort navn. Bekræft adapterens tilstand frem for profilen:

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

Hvis adressen mangler, sæt den med Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, tilføj derefter suffikset til adapterens IPv4-egenskaber, så fileserver bliver fileserver.corp.example. En SearchList værdi for hele maskinen under Tcpip\Parameters gør det samme. Hvor det lange navn opløses og det bare ikke, er resolveren allerede korrekt, og søgelisten er fejlen. Rettelserne i rækkefølge: skub en DOMAIN så klienten lærer suffikset, føj det suffiks til adapterens eller forbindelsens søgeliste, og sæt som en midlertidig foranstaltning navnet fast i hosts, eller LMHOSTS på Windows; NetBIOS-browsing krydser ikke en router, så den broadcast, der finder et kort navn på kontorets LAN, når aldrig en tunnelklient.

block-outside-dns block-outside-dns er Windows-klientadfærd, ikke en portabel profillinje, og kopiering til en Linux- eller macOS-profil gengiver det ikke der. Hvis offentlige navne virker og interne fejler på Windows, så sammenlign adapterrækkefølgen under Avancerede indstillinger med ipconfig /all. På macOS tilhører resolverrækkefølgen per tjeneste systemet, så brug scutil --dns for at se, hvilken resolver der spørges for hvilket domæne, og betragt enhver enkelt rapporteret profilrettelse som klientafhængig frem for generel.

En virtuel maskine på samme bærbare arver intet af dette. Giv gæsten sin egen resolver-post for det interne domæne, eller lad hypervisorens NAT videresende dens forespørgsler gennem værten, hvilket kun er korrekt, mens værtens tunnel er oppe.

Historik er den tredje årsag. DNS-servere eller suffiksindstillinger fra en tidligere profil kan overleve genopkoblinger, så når adapteren ser korrekt ud og opslag stadig fejler, sammenlign den levende adapter med Get-VpnConnection og ryd eller overskriv den forældede post, før du rører serveren.

Bevis, hvor forespørgslen gik hen

En optagelse under ét opslag afgør diskussionen: tcpdump -ni eth0 port 53 viser forespørgsler på den fysiske grænseflade, hvilket betyder, at de forlader tunnelen, og at resolveren aldrig blev skiftet. dig @10.8.0.1 name.corp.example skiller derefter de to resterende tilfælde. Hvis den direkte forespørgsel svarer, virker resolveren, og klienten bruger den ikke; hvis den timer ud, er resolveren utilgængelig gennem tunnelen, og ingen lokal ændring hjælper.

Hvis resolveren, der stadig bruges, er den, udbyderen udleverede, krypterer tunnelen trafikken, mens navnene forbliver synlige for den udbyder. Det er et lækagespørgsmål frem for et funktionelt, og den samme optagelse svarer på det: en forespørgsel på den fysiske grænseflade går til nogen uden for tunnelen.

Tilgængelighed omfatter firewalled på VPN-værten, som skal tillade UDP og TCP 53 fra poolen. En blokeret port ser præcis ud som et ødelagt push, og det gør en resolver, der kun svarer indefra tunnelnetværket, også. Gentag optagelsen efter én afbrydelse og genopkobling, for indstillinger, der vises ved første forbindelse og forsvinder ved den anden, er en livscyklusfejl i hooken, ikke en manglende indstilling.

Hold én ejer og verificer i rækkefølge

Et script, der omskriver adapterens DNS ud fra en gættet tunneltilstand, duplikerer konfiguration, som profilen allerede bærer, og fejler lydløst første gang, gættet er forkert. Foretræk forbindelsens egne DNS-indstillinger eller én dokumenteret hook, og noter, hvilken du valgte, så den næste ikke tilføjer en anden.

Luk kredsen med fire kontroller: den skubbede adresse til stede på tunnel-linket, det interne navn opløst som fuldt kvalificeret navn, samme navn opløst uden suffikset, og begge stadig sande efter én genopkobling. Én optagelse fortæller, hvilken af de fire der fejlede. OpenVPN 2.6-manualen lister dhcp-option og scriptdirektiver med deres platformsnoter.