DNS, ki ga potisne OpenVPN, je prezrt: katera komponenta ga uporabi

Dnevnik kaže možnost, ki jo je potisnil strežnik, tunel je vzpostavljen, notranja imena pa še vedno ne uspejo. Neposredna poizvedba na razreševalnik odgovori, torej je strežnik v redu, a vsaka aplikacija še naprej sprašuje lokalni usmerjevalnik. Kar je prišlo do odjemalca, je ponudba, ne sprememba v razreševalniku, in komponenta, ki ima razreševanje imen, se v Linuxu, Windows in macOS razlikuje. Ko možnost ločite od njenega lastnika, štiri napake pokrijejo skoraj vsako poročilo: ni hooka, dva tekmujoča hooka, razdeljeni DNS deluje po načrtu, ali kratko ime potrebuje pripono in ne strežnika.

Potisnjena možnost je ponudba, ne namestitev

Na strežniku dve direktivi opisujeta namen, ne učinka:

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

Odjemalec ne dobi nastavljenega razreševalnika. Dobi okoljske spremenljivke, foreign_option_1 in nadaljnje, eno za vsako potisnjeno vrstico, in nekaj lokalnega jih mora prebrati in prepisati stanje razreševalnika operacijskega sistema. V Linuxu privzeto tega ne počne nič, zato lahko pravilen strežnik in povezan odjemalec še vedno razrešujeta imena prek LAN.

Med obema koncema so tri faze: potiskanje mora priti, odjemalec ga mora razkriti in hook ga mora uporabiti. Preberite srednjo fazo v dnevniku odjemalca in zadnjo v stanju razreševalnika, nikoli obratno, ker vrstica v dnevniku dokazuje le prvi dve.

Potrdite, da je potiskanje prispelo, in poiščite lastnika

Začnite z poimenovanjem zagonskega programa: goli openvpn ukaz, instanca systemd, NetworkManager ali odjemalec ponudnika. To odloči, kje lahko živi hook. Na gostitelju s systemd-resolved, resolvectl status izpiše vsako povezavo s strežniki DNS in iskalnimi domenami, ki jih dejansko uporablja, povezava tunela pa se ne imenuje vedno tun0.

Če se potisnjeni naslov pojavi v dnevniku, a ne na nobeni povezavi, integracija manjka. Če se pojavi na povezavi in poizvedbe vseeno odhajajo drugam, je težava v tem, katere poizvedbe izberejo to povezavo. NetworkManager dns=dnsmasq v datoteki /etc/NetworkManager/NetworkManager.conf zažene lokalnega posredovalnika, ki razdeljeni DNS uporablja namerno: imena znotraj domene VPN gredo na razreševalnik VPN, vse ostalo obdrži prejšnjo pot. Takšno vedenje je videti kot napaka, ko ste pričakovali, da se bo premaknil ves promet; preverite nastavitve za posamezno povezavo z nmcli connection show "My VPN", kjer ipv4.dns in ipv4.dns-search hranita vrednosti za tem, kar poroča naprava, preden to imenujete pokvarjeno. Če mora vsaka poizvedba res doseči razreševalnik VPN, odstranite dns=dnsmasq iz NetworkManager.conf in znova zaženite NetworkManager, kar vrne razreševanje imen nastavitvam povezave; sicer obdržite razdeljeni DNS in popravite potisnjeni seznam domen.

Linux: predajte možnosti razreševalniku

Distribucijski paketi za to prinašajo hook, odjemalcu pa mora biti dovoljeno, da ga zažene. Tipična postavitev na gostitelju brez systemd-resolved:

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

S systemd-resolved starejša skripta resolv.conf morda ne spremeni ničesar pomembnega, ker stub razreševalnik hrani stanje za vsako povezavo. update-systemd-resolved pomočnik dokumentira obliko hooka, ki uporablja up-restart in down-pre, kar je pomembno, ko vmesnik preživi en sam poskus povezave. Karkoli izberete, stanje mora imeti ena komponenta. Dodajanje nepovezanega hooka ob NetworkManageru da dvema piscema isto povezavo in rezultat je potem odvisen od vrstnega reda, ne od vaše konfiguracije.

Obstaja tudi primer, ko je NetworkManager potisnjeno možnost popolnoma prezrl, dokler naslov strežnika ni bil vnesen v nastavitve IPv4 povezave, nato pa je stanje razreševalnika pokazalo, da se uporablja. Vredno je poskusiti pred prepisovanjem skript, ker premakne težavo iz lupinskega hooka v profil povezave, ki tunel že nosi.

Windows in macOS uporabljata različne dele

Odjemalec za Windows res nastavi strežnike DNS adapterja VPN, a Windows še vedno izbira vmesnik po metriki in še vedno potrebuje pripono za razširitev kratkega imena. Potrdite stanje adapterja, ne profila:

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

Če naslova ni, ga nastavite s Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, nato dodajte pripono med lastnosti IPv4 adapterja, da fileserver postane fileserver.corp.example. Vrednost SearchList za celoten računalnik pod Tcpip\Parameters naredi isto. Kjer se dolgo ime razreši, golo pa ne, je razreševalnik že pravilen in kriv je iskalni seznam. Popravki po vrsti: potisnite DOMAIN da se odjemalec nauči pripone, dodajte to pripono na iskalni seznam adapterja ali povezave in kot začasen ukrep pripnite ime v hosts, ali v LMHOSTS v Windows; brskanje NetBIOS ne prestopi usmerjevalnika, zato oddajanje, ki v pisarniškem LAN najde kratko ime, nikoli ne doseže odjemalca tunela.

block-outside-dns block-outside-dns je vedenje odjemalca Windows, ne prenosna vrstica profila, in kopiranje v profil Linuxa ali macOS ga tam ne ponovi. Če v Windows javna imena delujejo, notranja pa ne, primerjajte vrstni red adapterjev v Dodatnih nastavitvah s ipconfig /all. V macOS vrstni red razreševalnikov za posamezno storitev pripada sistemu, zato uporabite scutil --dns da vidite, kateri razreševalnik se sprašuje za katero domeno, in vsak posamezen sporočen popravek profila obravnavajte kot odvisen od odjemalca, ne splošen.

Navidezni stroj na istem prenosniku ne podeduje ničesar od tega. Dajte gostu lasten vnos razreševalnika za notranjo domeno ali pustite, da NAT hipervizorja posreduje njegove poizvedbe prek gostitelja, kar je pravilno le, dokler je tunel gostitelja vzpostavljen.

Zgodovina je tretji vzrok. Strežniki DNS ali nastavitve pripone iz prejšnjega profila lahko preživijo ponovne povezave, zato ko je adapter videti pravilen in iskanja še vedno ne uspejo, primerjajte živi adapter z Get-VpnConnection in izbrišite ali prepišite zastarel vnos, preden se dotaknete strežnika.

Dokažite, kam je odšla poizvedba

Zajem med enim iskanjem razreši spor: tcpdump -ni eth0 port 53 prikaže poizvedbe na fizičnem vmesniku, kar pomeni, da odhajajo zunaj tunela in razreševalnik ni bil nikoli preklopljen. dig @10.8.0.1 name.corp.example nato loči preostala dva primera. Če neposredna poizvedba odgovori, razreševalnik deluje in odjemalec ga ne uporablja; če poteče čas, razreševalnik po tunelu ni dosegljiv in nobena lokalna sprememba ne bo pomagala.

Če je razreševalnik, ki se še uporablja, tisti, ki ga je razdelil ponudnik, tunel šifrira promet, imena pa ostanejo vidna temu ponudniku. To je vprašanje uhajanja, ne delovanja, in isti zajem nanj odgovori: poizvedba na fizičnem vmesniku gre nekomu zunaj tunela.

Dosegljivost vključuje požarni zid na gostitelju VPN, ki mora dovoliti UDP in TCP 53 iz bazena. Zaprta vrata so videti natanko kot pokvarjeno potiskanje, enako pa tudi razreševalnik, ki odgovarja le iz notranjosti tunelskega omrežja. Zajem ponovite po eni prekinitvi in ponovni povezavi, ker so nastavitve, ki se pojavijo ob prvi povezavi in izginejo ob drugi, napaka življenjskega cikla v hooku, ne manjkajoča možnost.

Ohranite enega lastnika in preverjajte po vrsti

Skripta, ki prepiše DNS adapterja na podlagi domnevnega stanja tunela, podvaja konfiguracijo, ki jo profil že nosi, in tiho odpove prvič, ko je domneva napačna. Prednost dajte lastnim nastavitvam DNS povezave ali enemu dokumentiranemu hooku in zabeležite, katerega ste izbrali, da naslednja oseba ne doda drugega.

Zaprite zanko s štirimi preverjanji: potisnjeni naslov je na povezavi tunela, notranje ime se razreši kot polno kvalificirano ime, isto ime se razreši brez pripone in oboje še vedno velja po eni ponovni povezavi. En zajem vam pove, katero od štirih ni uspelo. Priročnik OpenVPN 2.6 navaja dhcp-option in direktive skriptov z opombami o platformah.