OpenVPN stumiamas DNS ignoruojamas: kuri komponentė jį pritaiko

Žurnale matomas serverio stumtas variantas, tunelis veikia, o vidiniai vardai vis tiek nepavyksta. Tiesioginė užklausa rezolveriui atsako, vadinasi, serveris tvarkingas, bet kiekviena programa vis dar klausia vietinio maršrutizatoriaus. Tai, kas pasiekė klientą, yra pasiūlymas, o ne rezolverio pakeitimas, ir komponentė, kuri valdo vardų sprendimą, skiriasi Linux, Windows ir macOS sistemose. Kai atskirsite variantą nuo jo savininko, keturi gedimai apima beveik kiekvieną pranešimą: nėra hook, du konkuruojantys hook, padalytas DNS veikia taip, kaip suprojektuotas, arba trumpam vardui reikia priesagos, o ne serverio.

Stumiamas variantas yra pasiūlymas, o ne įdiegimas

Serveryje dvi direktyvos apibūdina ketinimą, o ne poveikį:

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

Klientas negauna sukonfigūruoto rezolverio. Jis gauna aplinkos kintamuosius, foreign_option_1 ir tolesnius, po vieną kiekvienai stumtai eilutei, ir kažkas vietinio turi juos perskaityti ir perrašyti operacinės sistemos rezolverio būseną. Linux sistemoje pagal nutylėjimą niekas to nedaro, todėl teisingas serveris ir prisijungęs klientas vis tiek gali spręsti vardus per LAN.

Tarp abiejų galų yra trys etapai: stūmimas turi atkeliauti, klientas turi jį atskleisti, o hook turi jį pritaikyti. Skaitykite vidurinį etapą kliento žurnale, o paskutinį – rezolverio būsenoje, niekada atvirkščiai, nes žurnalo eilutė įrodo tik pirmuosius du.

Įsitikinkite, kad stūmimas atkeliavo, ir raskite savininką

Pradėkite įvardydami paleidiklį: paprasta openvpn komanda, systemd egzempliorius, NetworkManager arba tiekėjo klientas. Tai nulemia, kur hook gali gyventi. Hoste su systemd-resolved, resolvectl status išvardija kiekvieną jungtį su DNS serveriais ir paieškos domenais, kuriuos ji iš tikrųjų naudoja, o tunelio jungtis ne visada vadinama tun0.

Jei stumtas adresas matomas žurnale, bet nė vienoje jungtyje, integracijos trūksta. Jei jis yra jungtyje, o užklausos vis tiek išeina kitur, problema yra ta, kurios užklausos pasirenka tą jungtį. NetworkManager dns=dnsmasq faile /etc/NetworkManager/NetworkManager.conf paleidžia vietinį peradresuotoją, kuris padalytą DNS įgyvendina tyčia: vardai VPN domene eina į VPN rezolverį, visa kita išlaiko ankstesnį kelią. Toks elgesys atrodo kaip gedimas, kai tikėjotės, kad persikels visas srautas; patikrinkite kiekvieno ryšio nustatymus su nmcli connection show "My VPN", kur ipv4.dns ir ipv4.dns-search laiko reikšmes, esančias už to, ką praneša įrenginys, prieš vadindami tai sulaužytu. Jei kiekviena užklausa tikrai turi pasiekti VPN rezolverį, pašalinkite dns=dnsmasq iš NetworkManager.conf ir perkraukite NetworkManager, kuris grąžina vardų sprendimą ryšio nustatymams; kitu atveju palikite padalytą DNS ir pataisykite stumtą domenų sąrašą.

Linux: perduokite variantus rezolveriui

Platinimo paketai tam pateikia hook, o klientui turi būti leista jį vykdyti. Įprastas išdėstymas hoste be systemd-resolved:

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

Su systemd-resolved senesnis resolv.conf scenarijus gali nieko svarbaus nepakeisti, nes stub rezolveris laiko būseną kiekvienai jungčiai. update-systemd-resolved pagalbinė priemonė dokumentuoja hook formą, kuri naudoja up-restart ir down-pre, o tai svarbu, kai sąsaja išgyvena vieną prisijungimo bandymą. Kad ir ką pasirinktumėte, būseną turi valdyti viena komponentė. Nesusijusio hook pridėjimas šalia NetworkManager duoda du rašytojus tai pačiai jungčiai, ir rezultatas tada priklauso nuo tvarkos, o ne nuo jūsų konfigūracijos.

Pasitaiko ir atvejis, kai NetworkManager visiškai ignoravo stumtą variantą, kol serverio adresas nebuvo įrašytas į ryšio IPv4 nustatymus, o paskui rezolverio būsena parodė, kad jis naudojamas. Verta pabandyti prieš perrašant scenarijus, nes tai perkelia problemą iš shell hook į ryšio profilį, kuris jau neša tunelį.

Windows ir macOS pritaiko skirtingas dalis

Windows klientas tikrai nustato VPN adapterio DNS serverius, bet Windows vis dar renkasi sąsają pagal metriką ir vis dar reikia priesagos trumpam vardui išplėsti. Patikrinkite adapterio būseną, o ne profilį:

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

Jei adreso nėra, nustatykite jį su Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, tada pridėkite priesagą prie adapterio IPv4 savybių, kad fileserver taptų fileserver.corp.example. Visos mašinos SearchList reikšmė Tcpip\Parameters apačioje daro tą patį. Kai ilgas vardas išsprendžiamas, o plikas ne, rezolveris jau teisingas, o kaltas paieškos sąrašas. Pataisymai iš eilės: stumkite DOMAIN kad klientas išmoktų priesagą, pridėkite tą priesagą prie adapterio ar ryšio paieškos sąrašo, o kaip laikiną priemonę įtvirtinkite vardą hosts faile, arba LMHOSTS Windows sistemoje; NetBIOS naršymas neperžengia maršrutizatoriaus, todėl transliacija, kuri biuro LAN tinkle randa trumpą vardą, niekada nepasiekia tunelio kliento.

block-outside-dns block-outside-dns yra Windows kliento elgsena, o ne perkeliama profilio eilutė, ir nukopijavus jį į Linux ar macOS profilį jis ten neatsikartoja. Jei Windows sistemoje vieši vardai veikia, o vidiniai nepavyksta, palyginkite adapterių tvarką išplėstiniuose nustatymuose su ipconfig /all. macOS sistemoje kiekvienos paslaugos rezolverio tvarka priklauso sistemai, todėl naudokite scutil --dns norėdami pamatyti, kuris rezolveris klausiamas dėl kurio domeno, ir vertinkite bet kurią atskirą praneštą profilio pataisą kaip priklausomą nuo kliento, o ne bendrą.

Virtualioji mašina tame pačiame nešiojamajame kompiuteryje nieko iš to nepaveldi. Duokite svečiui savo rezolverio įrašą vidiniam domenui arba leiskite hipervizoriaus NAT perduoti jo užklausas per hostą, o tai teisinga tik tol, kol hosto tunelis veikia.

Istorija yra trečioji priežastis. Ankstesnio profilio DNS serveriai ar priesagos nustatymai gali išgyventi pakartotinius prisijungimus, todėl kai adapteris atrodo tvarkingas, o paieškos vis tiek nepavyksta, palyginkite gyvą adapterį su Get-VpnConnection ir ištrinkite ar perrašykite pasenusį įrašą, prieš liesdami serverį.

Įrodykite, kur nuėjo užklausa

Vienos paieškos metu atliktas fiksavimas išsprendžia ginčą: tcpdump -ni eth0 port 53 rodo užklausas fizinėje sąsajoje, o tai reiškia, kad jos išeina už tunelio ir rezolveris niekada nebuvo perjungtas. dig @10.8.0.1 name.corp.example tada atskiria du likusius atvejus. Jei tiesioginė užklausa atsako, rezolveris veikia ir klientas jo nenaudoja; jei baigiasi laikas, rezolveris per tunelį nepasiekiamas ir jokia vietinė pataisa nepadės.

Jei vis dar naudojamas rezolveris yra tas, kurį išdavė tiekėjas, tunelis šifruoja srautą, bet vardai lieka matomi tam tiekėjui. Tai nuotėkio, o ne funkcionalumo klausimas, ir tas pats fiksavimas į jį atsako: užklausa fizinėje sąsajoje eina kažkam už tunelio ribų.

Pasiekiamumas apima VPN hosto ugniasienę, kuri turi leisti UDP ir TCP 53 iš baseino. Uždarytas prievadas atrodo lygiai kaip sulaužytas stūmimas, ir taip pat rezolveris, kuris atsako tik iš tunelio tinklo vidaus. Pakartokite fiksavimą po vieno atsijungimo ir prisijungimo, nes nustatymai, kurie pasirodo per pirmąjį ryšį ir dingsta per antrąjį, yra hook gyvavimo ciklo gedimas, o ne trūkstamas variantas.

Laikykitės vieno savininko ir tikrinkite iš eilės

Scenarijus, kuris perrašo adapterio DNS remdamasis spėjama tunelio būsena, dubliuoja konfigūraciją, kurią profilis jau neša, ir tyliai sugenda pirmą kartą, kai spėjimas klaidingas. Pirmenybę teikite paties ryšio DNS nustatymams arba vienam dokumentuotam hook, ir užsirašykite, kurį pasirinkote, kad kitas žmogus nepridėtų antro.

Uždarykite ciklą keturiomis patikromis: stumtas adresas yra tunelio jungtyje, vidinis vardas sprendžiamas kaip visiškai kvalifikuotas vardas, tas pats vardas sprendžiamas be priesagos, ir abu vis dar teisingi po vieno pakartotinio prisijungimo. Vienas fiksavimas pasako, kuri iš keturių nepavyko. OpenVPN 2.6 vadovas išvardija dhcp-option ir scenarijų direktyvas su jų platformų pastabomis.