Troch OpenVPN skood DNS wurdt negearre: hokker komponint past it ta

It logboek lit de opsje sjen dy't de tsjinner skood hat, de tunnel is omheech, en ynterne nammen mislearje noch altyd. In fraach streekrjocht oan de resolver antwurdet, dus de tsjinner is yn oarder, mar elke applikaasje bliuwt de lokale router freegje. Wat by de klient oankaam is in oanbod, gjin feroaring yn de resolver, en de komponint dy't de nameresolúsje besit ferskilt op Linux, Windows en macOS. Sadree't jo de opsje fan syn eigner skiede, dekke fjouwer flaters hast elk rapport: gjin hook, twa konkurrearjende hooks, splitste DNS dy't wurket sa't it ûntwurpen is, of in koarte namme dy't in efterheaksel nedich hat en gjin tsjinner.

In skode opsje is in oanbod, gjin ynstallaasje

Op de tsjinner beskriuwe twa rjochtlinen de bedoeling, net it effekt:

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

De klient krijt gjin konfigurearre resolver. Hy krijt omjouwingsfariabelen, foreign_option_1 en fierder, ien foar elke skode rigel, en eat lokaals moat se lêze en de resolversteat fan it bestjoeringssysteem oerskriuwe. Op Linux docht neat dat standert, dêrom kinne in korrekte tsjinner en in ferbûne klient noch altyd fia it LAN resolvje.

Tusken de beide einen steane trije fazen: de push moat reizgje, de klient moat it bleatlizze, en in hook moat it tapasse. Lês de middelste faze yn it klientlogboek en de lêste faze yn de resolversteat, nea oarsom, want in logrigel bewissiget allinich de earste twa.

Befêstigje dat de push oankaam en fyn de eigner

Begjin mei it beneamen fan de starter: in keale openvpn opdracht, in systemd-eksimplaar, NetworkManager of in leveransiersklient. Dat beslút wêr't in hook libje kin. Op in host mei systemd-resolved, resolvectl status listet elke keppeling mei de DNS-tsjinners en sykdominen dy't it wier brûkt, en de tunnelkeppeling hjit net altyd tun0.

As it skode adres yn it logboek ferskynt mar op gjin inkelde keppeling, ûntbrekt de yntegraasje. As it op de keppeling ferskynt en de fragen geane noch earne oars út, is it probleem hokker fragen dy keppeling kieze. NetworkManager dns=dnsmasq yn it bestân /etc/NetworkManager/NetworkManager.conf rint in lokale trochstjoerder dy't splitste DNS mei opsetsin tapast: nammen yn it VPN-domein geane nei de VPN-resolver, al it oare hâldt syn eardere paad. Dat gedrach liket op in flater as jo ferwachten dat al it ferkear ferhuze; kontrolearje de ynstellings per ferbining mei nmcli connection show "My VPN", wêr't ipv4.dns en ipv4.dns-search de wearden efter wat it apparaat rapportearret hâlde, foardat jo it stikken neame. As elke fraach wier by de VPN-resolver komme moat, ferwiderje dns=dnsmasq út NetworkManager.conf en start NetworkManager opnij, wat de nameresolúsje weromjout oan de ferbiningsynstellings; oars hâld splitste DNS en korrizjearje de skode domeinlist.

Linux: jou de opsjes oan de resolver

Distribúsjepakketten leverje hjirfoar in hook, en de klient moat tastien wurde dy te draaien. In typyske opstelling op in host sûnder systemd-resolved:

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

Mei systemd-resolved feroaret it âldere resolv.conf-skript miskien neat wichtichs, omdat de stub-resolver steat per keppeling hâldt. update-systemd-resolved de helper dokumintearret in hookfoarm dy't up-restart en down-pre brûkt, wat fan belang is as in ynterface ien ferbiningspoging oerlibbet. Wat jo ek kieze, ien komponint moat de steat besitte. In net-relatearre hook njonken NetworkManager jout twa skriuwers oan deselde keppeling, en it resultaat hinget dan fan folchoarder ôf ynstee fan fan jo konfiguraasje.

Der is ek it gefal wêrby't NetworkManager de skode opsje hielendal negearre oant it tsjinneradres yn 'e IPv4-ynstellings fan 'e ferbining ynfierd waard, wêrnei't de resolversteat sjen liet dat it brûkt waard. Dat is it besykjen wurdich foardat jo skripten oerskriuwe, want it ferpleatst it probleem fan in shell-hook nei it ferbiningsprofyl dat de tunnel al draacht.

Windows en macOS passe ferskate dielen ta

De Windows-klient set wol de DNS-tsjinners fan 'e VPN-adapter, mar Windows kiest noch hieltyd in ynterface op metriken en hat noch hieltyd in efterheaksel nedich om in koarte namme út te wreidzjen. Befêstigje de steat fan 'e adapter ynstee fan it profyl:

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

As it adres ûntbrekt, set it dan mei Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, foegje dan it efterheaksel ta oan 'e IPv4-eigenskippen fan 'e adapter sadat fileserver wurdt fileserver.corp.example. In masinebrede SearchList wearde ûnder Tcpip\Parameters docht itselde. Wêr't de lange namme resolvet en de keale net, is de resolver al korrekt en is de syklist de skuld. De ferbetterings, yn folchoarder: skodzje in DOMAIN sadat de klient it efterheaksel leart, foegje dat efterheaksel ta oan 'e syklist fan 'e adapter of ferbining, en fêstigje as tydlike maatregel de namme yn hosts, of LMHOSTS op Windows; NetBIOS-sneupen giet net oer in router, dus de útstjoering dy't in koarte namme op it kantoar-LAN fynt berikt nea in tunnelklient.

block-outside-dns block-outside-dns is gedrach fan 'e Windows-klient, gjin oerdraachbere profylrigel, en it kopiearjen nei in Linux- of macOS-profyl reprodusearret it dêr net. As publike nammen wurkje en ynterne op Windows mislearje, fergelykje dan de adapterfolchoarder ûnder Avansearre ynstellings mei ipconfig /all. Op macOS heart de resolverfolchoarder per tsjinst by it systeem, brûk dus scutil --dns om te sjen hokker resolver foar hokker domein frege wurdt, en behannelje elke inkelde rapportearre profylferbettering as klientôfhinklik ynstee fan algemien.

In firtuele masine op deselde laptop erft hjir neat fan. Jou de gast syn eigen resolverynskriuwing foar it ynterne domein, of lit de NAT fan 'e hypervisor syn fragen fia de host trochstjoere, wat allinnich korrekt is salang't de tunnel fan 'e host omheech is.

Skiednis is de tredde oarsaak. DNS-tsjinners of efterheakselynstellings fan in earder profyl kinne werferbiningen oerlibje, dus as de adapter korrekt liket en sykopdrachten noch mislearje, fergelykje de libbene adapter mei Get-VpnConnection en wiskje of oerskriuw de ferâldere ynskriuwing foardat jo de tsjinner oanreitsje.

Bewiis wêr't de fraach hinne gie

In opname by ien sykopdracht besljochtet de diskusje: tcpdump -ni eth0 port 53 lit fragen op 'e fysike ynterface sjen, wat betsjut dat se bûten de tunnel fuortgeane en de resolver nea omskeakele is. dig @10.8.0.1 name.corp.example skiedt dan de beide oerbleaune gefallen. As de direkte fraach antwurdet, wurket de resolver en brûkt de klient him net; as er ferrint, is de resolver fia de tunnel net berikber en gjin lokale feroaring sil helpe.

As de resolver dy't noch brûkt wurdt dy fan 'e provider is, fersiferet de tunnel it ferkear wylst de nammen sichtber bliuwe foar dy provider. Dat is in fraach fan lekken, net fan funksjonaliteit, en deselde opname antwurdet it: in fraach op 'e fysike ynterface giet nei immen bûten de tunnel.

Berikberens omfettet de firewall op 'e VPN-host, dy't UDP en TCP 53 út 'e pool talitte moat. In sletten poarte liket krekt as in stikken push, en in resolver dy't allinnich fan binnen it tunnelnedwurk antwurdet likegoed. Werhelje de opname nei ien ferbrekking en werferbining, want ynstellings dy't by de earste ferbining ferskine en by de twadde ferdwine binne in libbenssyklusflater yn 'e hook, gjin ûntbrekkende opsje.

Hâld ien eigner en kontrolearje yn folchoarder

In skript dat de adapter-DNS oerskriuwt op grûn fan in raande tunnelsteat duplisearret konfiguraasje dy't it profyl al draacht, en it mislearret stil de earste kear dat de ried ferkeard is. Ferkies de eigen DNS-ynstellings fan 'e ferbining of ien dokumintearre hook, en skriuw op hokker jo keazen hawwe sadat de folgjende persoan gjin twadde tafoeget.

Slút de ring mei fjouwer kontrôles: it skode adres oanwêzich op 'e tunnelkeppeling, de ynterne namme resolvet as folslein kwalifisearre namme, deselde namme resolvet sûnder it efterheaksel, en beide noch wier nei ien werferbining. Ien opname fertelt jo hokker fan 'e fjouwer mislearre. It hânboek fan OpenVPN 2.6 listet dhcp-option en skriptrjochtlinen mei harren platfoarmnotysjes.