DNS som OpenVPN dyttar blir ignorert: kva komponent brukar det

Loggen viser valet tenaren dytta, tunnelen er oppe, og interne namn feilar framleis. Ei direkte spørjing til resolvaren svarar, så tenaren er i orden, men kvar applikasjon held fram med å spørje den lokale rutaren. Det som nådde klienten, er eit tilbod, ikkje ei endring i resolvaren, og komponenten som eig namneoppslaget er ulik på Linux, Windows og macOS. Når du skil valet frå eigaren, dekkjer fire feil nesten kvar rapport: ingen hook, to konkurrerande hooks, delt DNS som verkar etter hensikta, eller eit kort namn som treng eit suffiks og ikkje ein tenar.

Eit dytta val er eit tilbod, ikkje ein installasjon

På tenaren skildrar to direktiv hensikt, ikkje effekt:

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

Klienten får ikkje ein konfigurert resolvar. Han får miljøvariablar, foreign_option_1 og vidare, éin per dytta linje, og noko lokalt må lese dei og skrive om resolvarens tilstand i operativsystemet. På Linux gjer ingenting dette som standard, og difor kan ein korrekt tenar og ein tilkopla klient framleis slå opp namn via LAN.

Mellom dei to endane ligg tre trinn: dyttet må kome fram, klienten må synleggjere det, og ein hook må bruke det. Les det midtre trinnet i klientloggen og det siste i resolvarens tilstand, aldri omvendt, for ei logglinje beviser berre dei to første.

Stadfest at dyttet kom fram, og finn eigaren

Start med å namngje oppstartaren: ein bar openvpn kommando, ein systemd-instans, NetworkManager eller ein leverandørklient. Det avgjer kvar ein hook kan bu. På ein vert med systemd-resolved resolvectl status listar kvar lenkje med DNS-tenarane og søkjedomena ho faktisk brukar, og tunnellenkja heiter ikkje alltid tun0.

Viss den dytta adressa står i loggen men ikkje på noka lenkje, manglar integrasjonen. Viss ho står på lenkja og spørjingane framleis går ut andre stader, er problemet kva spørjingar som vel den lenkja. NetworkManager dns=dnsmasq i fila /etc/NetworkManager/NetworkManager.conf køyrer ein lokal vidaresendar som med vilje brukar delt DNS: namn i VPN-domenet går til VPN-resolvaren, alt anna held på den førre vegen sin. Denne åtferda ser ut som ein feil når du venta at all trafikk skulle flytte seg; sjekk innstillingane per tilkopling med nmcli connection show "My VPN", der ipv4.dns og ipv4.dns-search held verdiane bak det eininga rapporterer, før du kallar det øydelagt. Viss kvar spørjing verkeleg skal nå VPN-resolvaren, fjern dns=dnsmasq frå NetworkManager.conf og start NetworkManager på nytt, noko som gjev namneoppslaget tilbake til tilkoplingsinnstillingane; elles hald på delt DNS og rett den dytta domenelista.

Linux: gje vala til resolvaren

Distribusjonspakkar leverer ein hook for dette, og klienten må få lov til å køyre han. Eit typisk oppsett på ein vert utan systemd-resolved:

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

Med systemd-resolved endrar det eldre resolv.conf-skriptet kanskje ingenting viktig, fordi stub-resolvaren held tilstand per lenkje. update-systemd-resolved hjelparen dokumenterer ein hookform som brukar up-restart og down-pre, noko som tel når eit grensesnitt overlever eitt tilkoplingsforsøk. Kva du enn vel, ein komponent må eige tilstanden. Å leggje til ein ubeslekta hook ved sida av NetworkManager gjev to skribentar til same lenkja, og resultatet avheng då av rekkjefølgja og ikkje av konfigurasjonen din.

Det finst også tilfellet der NetworkManager ignorerte det dytta valet heilt til tenaradressa vart skriven inn i tilkoplinga sine IPv4-innstillingar, og då viste resolvarens tilstand at ho var i bruk. Det er verdt eit forsøk før du skriv om skript, fordi det flyttar problemet frå ein shell-hook til tilkoplingsprofilen som alt ber tunnelen.

Windows og macOS brukar ulike delar

Windows-klienten set faktisk DNS-tenarane til VPN-adapteren, men Windows vel framleis grensesnitt etter metrikk og treng framleis eit suffiks for å utvide eit kort namn. Stadfest adaptertilstanden og ikkje profilen:

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

Viss adressa manglar, set ho med Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, legg så til suffikset i adapteren sine IPv4-eigenskapar slik at fileserver blir fileserver.corp.example. Ein SearchList verdi for heile maskinen under Tcpip\Parameters gjer det same. Der det lange namnet blir løyst og det bare ikkje, er resolvaren alt korrekt, og søkelista er skulda. Rettleiingane, i rekkjefølgje: dytt ein DOMAIN slik at klienten lærer suffikset, legg til suffikset i søkelista til adapteren eller tilkoplinga, og fest namnet mellombels i hosts, eller LMHOSTS på Windows; NetBIOS-blaing kryssar ikkje ein rutar, så kringkastinga som finn eit kort namn på kontor-LANet når aldri ein tunnelklient.

block-outside-dns block-outside-dns er Windows-klientåtferd, ikkje ei flyttbar profillinje, og å kopiere han til ein Linux- eller macOS-profil attgjev han ikkje der. Viss offentlege namn verkar og interne feilar på Windows, samanlikn adapterrekkjefølgja under Avanserte innstillingar med ipconfig /all. På macOS høyrer resolvarens rekkjefølgje per teneste til systemet, så bruk scutil --dns for å sjå kven resolvar som blir spurt for kva domene, og handsam kvar einskild rapportert profilretting som klientavhengig og ikkje generell.

Ein virtuell maskin på same berbare datamaskina arvar ingenting av dette. Gje gjesten si eiga resolvaroppføring for det interne domenet, eller la NAT-en til hypervisoren sende spørjingane hans gjennom verten, noko som berre er rett så lenge tunnelen til verten er oppe.

Historia er den tredje årsaka. DNS-tenarar eller suffiksinnstillingar frå ein tidlegare profil kan overleve nye tilkoplingar, så når adapteren ser rett ut og oppslag framleis feilar, samanlikn den levande adapteren med Get-VpnConnection og slett eller skriv over den utdaterte oppføringa før du rører tenaren.

Bevis kvar spørjinga gjekk

Eit opptak under eitt oppslag avgjer saka: tcpdump -ni eth0 port 53 viser spørjingar på det fysiske grensesnittet, som tyder at dei går ut utanfor tunnelen og at resolvaren aldri vart bytt. dig @10.8.0.1 name.corp.example skil så dei to attverande tilfella. Viss den direkte spørjinga svarar, verkar resolvaren og klienten brukar han ikkje; viss ho går ut på tid, er resolvaren utilgjengeleg gjennom tunnelen og inga lokal endring hjelper.

Viss resolvaren som framleis blir brukt er den leverandøren delte ut, krypterer tunnelen trafikken medan namna blir verande synlege for den leverandøren. Det er eit lekkasjespørsmål og ikkje eit funksjonelt, og det same opptaket svarar på det: ei spørjing på det fysiske grensesnittet går til nokon utanfor tunnelen.

Tilgjenge omfattar brannmuren på VPN-verten, som må tillate UDP og TCP 53 frå bassenget. Ein stengd port ser nøyaktig ut som eit øydelagt dytt, og det gjer òg ein resolvar som berre svarar frå innsida av tunnelnettet. Gjenta opptaket etter éi fråkopling og ny tilkopling, fordi innstillingar som dukkar opp ved første tilkopling og forsvinn ved den andre, er ein livssyklusfeil i hooken og ikkje eit manglande val.

Hald éin eigar og stadfest i rekkjefølgje

Eit skript som skriv om adapteren sin DNS ut frå ein gissa tunneltilstand dupliserer konfigurasjon profilen alt ber, og det feilar stille første gong gissinga er feil. Føretrekk dei eigne DNS-innstillingane til tilkoplinga eller éin dokumentert hook, og noter kva du valde slik at neste person ikkje legg til ein ny.

Lukk sløyfa med fire kontrollar: den dytta adressa til stades på tunnellenkja, det interne namnet løyst som fullt kvalifisert namn, same namn løyst utan suffikset, og begge framleis sanne etter éi ny tilkopling. Eitt opptak fortel kva av dei fire som feila. Handboka for OpenVPN 2.6 listar dhcp-option og skriptdirektiva med plattformnotatane sine.