DNS, ktorý OpenVPN pretlačí, sa ignoruje: ktorý komponent ho uplatní

Záznam ukazuje voľbu, ktorú server pretlačil, tunel je up, a interné mená stále zlyhávajú. Dopyt priamo na resolver odpovedá, takže server je v poriadku, ale každá aplikácia sa ďalej pýta lokálneho routera. To, čo ku klientovi dorazilo, je ponuka, nie zmena v resolveri, a komponent, ktorý vlastní preklad mien, sa v Linuxe, Windows a macOS líši. Keď voľbu oddelíte od jej vlastníka, štyri poruchy pokryjú takmer každé hlásenie: chýba hook, dva hooky si konkurujú, rozdelený DNS funguje podľa návrhu, alebo krátke meno potrebuje príponu a nie server.

Pretlačená voľba je ponuka, nie inštalácia

Na serveri dve direktívy opisujú zámer, nie účinok:

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

Klient nedostane nakonfigurovaný resolver. Dostane premenné prostredia, foreign_option_1 a ďalšie, jednu za každý pretlačený riadok, a niečo lokálne ich musí prečítať a prepísať stav resolvera operačného systému. V Linuxe to predvolene nerobí nič, preto správny server a pripojený klient môžu stále prekladať mená cez LAN.

Medzi oboma koncami sú tri fázy: push musí doraziť, klient ho musí vystaviť a hook ho musí uplatniť. Čítajte strednú fázu v zázname klienta a poslednú v stave resolvera, nikdy naopak, pretože riadok záznamu dokazuje len prvé dve.

Overte, že push dorazil, a nájdite vlastníka

Začnite pomenovaním spúšťača: holý openvpn príkaz, inštancia systemd, NetworkManager alebo klientsky softvér výrobcu. To rozhoduje, kde môže hook žiť. Na hostiteľovi so systemd-resolved resolvectl status vypisuje každé rozhranie s DNS servermi a vyhľadávacími doménami, ktoré skutočne používa, a rozhranie tunela sa nie vždy volá tun0.

Ak sa pretlačená adresa objaví v zázname, ale na žiadnom rozhraní, integrácia chýba. Ak sa objaví na rozhraní a dopyty predsa odchádzajú inam, problém je v tom, ktoré dopyty vyberajú toto rozhranie. NetworkManager dns=dnsmasq v súbore /etc/NetworkManager/NetworkManager.conf spúšťa miestny preposielač, ktorý rozdelený DNS uplatňuje zámerne: mená v doméne VPN idú na VPN resolver, všetko ostatné si drží predchádzajúcu cestu. Také správanie vyzerá ako porucha, keď ste čakali, že sa presunie celá prevádzka; skontrolujte nastavenia pre konkrétne pripojenie pomocou nmcli connection show "My VPN", kde ipv4.dns a ipv4.dns-search držia hodnoty za tým, čo zariadenie hlási, než to nazvete pokazeným. Ak má každý dopyt naozaj dospieť na VPN resolver, odoberte dns=dnsmasq zo NetworkManager.conf a reštartujte NetworkManager, čo vráti preklad mien nastaveniam pripojenia; inak ponechajte rozdelený DNS a opravte pretlačený zoznam domén.

Linux: odovzdajte voľby resolveru

Distribučné balíky na to dodávajú hook a klientovi musí byť dovolené ho spustiť. Typické usporiadanie na hostiteľovi bez systemd-resolved:

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

So systemd-resolved starší skript resolv.conf nemusí zmeniť nič podstatné, pretože stub resolver drží stav pre každé rozhranie. update-systemd-resolved pomocník dokumentuje podobu hooku, ktorá používa up-restart a down-pre, čo je dôležité, keď rozhranie prežije jediný pokus o pripojenie. Čokoľvek zvolíte, stav musí vlastniť jeden komponent. Pridanie nesúvisiaceho hooku vedľa NetworkManageru dáva dvom zapisovateľom rovnaké rozhranie a výsledok potom závisí od poradia, nie od vašej konfigurácie.

Existuje aj prípad, keď NetworkManager pretlačenú voľbu úplne ignoroval, až kým sa adresa servera nezadala do nastavení IPv4 pripojenia, a až potom stav resolvera ukázal, že sa používa. Stojí za to to skúsiť pred prepisovaním skriptov, pretože to presúva problém zo shellového hooku do profilu pripojenia, ktorý tunel už nesie.

Windows a macOS uplatňujú rôzne časti

Klient pre Windows DNS servery adaptéra VPN skutočne nastaví, ale Windows stále vyberá rozhranie podľa metriky a stále potrebuje príponu na rozvinutie krátkeho mena. Overte stav adaptéra, nie profilu:

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

Ak adresa chýba, nastavte ju pomocou Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, potom pridajte príponu do vlastností IPv4 adaptéra, aby sa fileserver zmenil na fileserver.corp.example. Hodnota SearchList v celom počítači pod Tcpip\Parameters robí to isté. Kde sa dlhé meno preloží a holé nie, resolver je už správny a vinný je vyhľadávací zoznam. Opravy v poradí: pretlačte DOMAIN aby sa klient naučil príponu, pridajte túto príponu do vyhľadávacieho zoznamu adaptéra alebo pripojenia a ako dočasné opatrenie pripnite meno do hosts, alebo LMHOSTS vo Windows; prehliadanie NetBIOS neprekročí router, takže vysielanie, ktoré na kancelárskej LAN nájde krátke meno, sa ku klientovi tunela nikdy nedostane.

block-outside-dns block-outside-dns je správanie klienta Windows, nie prenosný riadok profilu, a skopírovanie do profilu Linuxu alebo macOS ho tam nezopakuje. Ak vo Windows verejné mená fungujú a interné zlyhávajú, porovnajte poradie adaptérov v Rozšírených nastaveniach s ipconfig /all. V macOS poradie resolverov pre jednotlivé služby patrí systému, preto použite scutil --dns na zistenie, ktorý resolver sa pre ktorú doménu dopytuje, a každú jednotlivú hlásenú opravu profilu berte ako závislú od klienta, nie všeobecnú.

Virtuálny stroj na tom istom notebooku nič z toho nezdedí. Dajte hosťovi vlastný záznam resolvera pre internú doménu alebo nechajte NAT hypervizora preposielať jeho dopyty cez hostiteľa, čo je správne len dovtedy, kým je tunel hostiteľa aktívny.

História je tretia príčina. DNS servery alebo nastavenia prípony z predchádzajúceho profilu môžu prežiť opätovné pripojenia, takže keď adaptér vyzerá správne a vyhľadávania stále zlyhávajú, porovnajte živý adaptér s Get-VpnConnection a zastaraný záznam vymažte alebo prepíšte, než siahnete na server.

Dokážte, kam dopyt odišiel

Zachytenie počas jedného vyhľadávania spor rozrieši: tcpdump -ni eth0 port 53 ukazuje dopyty na fyzickom rozhraní, čo znamená, že odchádzajú mimo tunel a resolver nebol nikdy prepnutý. dig @10.8.0.1 name.corp.example potom oddelí dva zostávajúce prípady. Ak priamy dopyt odpovedá, resolver funguje a klient ho nepoužíva; ak vyprší, resolver je cez tunel nedostupný a žiadna miestna zmena nepomôže.

Ak resolver, ktorý sa stále používa, je ten, ktorý pridelil poskytovateľ, tunel šifruje prevádzku, ale mená zostávajú tomuto poskytovateľovi viditeľné. Je to otázka úniku, nie funkčnosti, a to isté zachytenie ju zodpovie: dopyt na fyzickom rozhraní ide niekomu mimo tunela.

Dostupnosť zahŕňa firewall na hostiteľovi VPN, ktorý musí povoliť UDP a TCP 53 z poolu. Zatvorený port vyzerá presne ako pokazený push, a rovnako aj resolver, ktorý odpovedá len z vnútra tunelovej siete. Zachytenie zopakujte po jednom odpojení a opätovnom pripojení, pretože nastavenia, ktoré sa objavia pri prvom pripojení a pri druhom zmiznú, sú porucha životného cyklu v hooku, nie chýbajúca voľba.

Udržte jedného vlastníka a overujte v poradí

Skript, ktorý prepisuje DNS adaptéra podľa odhadnutého stavu tunela, duplikuje konfiguráciu, ktorú profil už nesie, a ticho zlyhá prvý raz, keď je odhad nesprávny. Uprednostnite vlastné nastavenia DNS pripojenia alebo jeden zdokumentovaný hook a poznamenajte si, ktorý ste zvolili, aby ďalší človek nepridal druhý.

Uzavrite slučku štyrmi kontrolami: pretlačená adresa je na rozhraní tunela, interné meno sa prekladá ako plne kvalifikované meno, to isté meno sa prekladá bez prípony a oboje stále platí po jednom opätovnom pripojení. Jedno zachytenie vám povie, ktorá zo štyroch zlyhala. Príručka OpenVPN 2.6 uvádza dhcp-option a direktívy skriptov s poznámkami k platformám.