DNS prosazovaný OpenVPN se ignoruje: která komponenta ho uplatní

Log ukazuje volbu, kterou server prosadil, tunel běží, a interní jména přesto selhávají. Dotaz přímo na resolver odpovídá, takže server je v pořádku, ale každá aplikace se dál ptá místního routeru. Co ke klientovi dorazilo, je nabídka, ne změna v resolveru, a komponenta, která vlastní překlad jmen, se na Linuxu, Windows a macOS liší. Jakmile volbu oddělíte od jejího vlastníka, čtyři závady pokryjí téměř každé hlášení: chybí hook, dva hooky si konkurují, split DNS funguje podle návrhu, nebo krátké jméno potřebuje sufix, a ne server.

Prosazená volba je nabídka, ne instalace

Na serveru dvě direktivy popisují záměr, ne účinek:

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

Klient nedostane nakonfigurovaný resolver. Dostane proměnné prostředí, foreign_option_1 a další, jednu za každý prosazený řádek, a něco místního je musí přečíst a přepsat stav resolveru operačního systému. Na Linuxu to ve výchozím stavu nedělá nic, proto správný server a připojený klient mohou jména stále překládat přes LAN.

Mezi oběma konci stojí tři fáze: push musí dorazit, klient ho musí vystavit a hook ho musí uplatnit. Čtěte prostřední fázi v logu klienta a poslední fázi ve stavu resolveru, nikdy naopak, protože řádek v logu dokazuje jen první dvě.

Ověřte, že push dorazil, a najděte vlastníka

Začněte pojmenováním spouštěče: holý openvpn příkaz, instance systemd, NetworkManager nebo klientský software výrobce. To rozhoduje, kde může hook žít. Na hostiteli se systemd-resolved resolvectl status vypisuje každé rozhraní s DNS servery a vyhledávacími doménami, které skutečně používá, a rozhraní tunelu se ne vždy jmenuje tun0.

Pokud se prosazená adresa objeví v logu, ale na žádném rozhraní, integrace chybí. Pokud se objeví na rozhraní a dotazy přesto odcházejí jinam, problém je v tom, které dotazy vybírají toto rozhraní. NetworkManager dns=dnsmasq v souboru /etc/NetworkManager/NetworkManager.conf spouští místní přeposílač, který split DNS uplatňuje záměrně: jména v doméně VPN jdou na VPN resolver, vše ostatní si drží předchozí cestu. Takové chování vypadá jako závada, když jste čekali, že se přesune veškerý provoz; zkontrolujte nastavení pro konkrétní připojení pomocí nmcli connection show "My VPN", kde ipv4.dns a ipv4.dns-search drží hodnoty za tím, co zařízení hlásí, než to nazvete rozbitým. Pokud má každý dotaz opravdu dojít na VPN resolver, odeberte dns=dnsmasq ze NetworkManager.conf a restartujte NetworkManager, což vrátí překlad jmen nastavení připojení; jinak ponechte split DNS a opravte prosazený seznam domén.

Linux: předejte volby resolveru

Distribuční balíčky pro to dodávají hook a klientovi musí být dovoleno ho spustit. Typické uspořádání na hostiteli bez systemd-resolved:

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

Se systemd-resolved starší skript resolv.conf nemusí změnit nic podstatného, protože stub resolver drží stav pro každé rozhraní. update-systemd-resolved pomocník dokumentuje podobu hooku, která používá up-restart a down-pre, což je důležité, když rozhraní přežije jediný pokus o připojení. Ať zvolíte cokoli, stav musí vlastnit jedna komponenta. Přidání nesouvisejícího hooku vedle NetworkManageru dává dvěma zapisovatelům stejné rozhraní a výsledek pak závisí na pořadí, ne na vaší konfiguraci.

Existuje i případ, kdy NetworkManager prosazenou volbu úplně ignoroval, dokud se adresa serveru nezadala do nastavení IPv4 připojení, a teprve pak stav resolveru ukázal, že se používá. Stojí za to to zkusit, než přepíšete skripty, protože to přesouvá problém ze shellového hooku do profilu připojení, který tunel už nese.

Windows a macOS uplatňují různé části

Klient pro Windows DNS servery adaptéru VPN skutečně nastaví, ale Windows stále vybírá rozhraní podle metriky a stále potřebuje sufix k rozvinutí krátkého jména. Ověřte stav adaptéru, ne profil:

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

Pokud adresa chybí, nastavte ji pomocí Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, pak přidejte sufix do vlastností IPv4 adaptéru, aby se fileserver změnil na fileserver.corp.example. Hodnota SearchList v celém počítači pod Tcpip\Parameters dělá totéž. Kde se dlouhé jméno přeloží a holé ne, je resolver už správný a vinna je vyhledávací seznam. Opravy v pořadí: prosazujte DOMAIN aby se klient naučil sufix, přidejte tento sufix do vyhledávacího seznamu adaptéru nebo připojení, a jako dočasné opatření zapište jméno do hosts, nebo LMHOSTS na Windows; procházení NetBIOS nepřekročí router, takže broadcast, který na kancelářské LAN najde krátké jméno, se ke klientovi tunelu nikdy nedostane.

block-outside-dns block-outside-dns je chování klienta Windows, ne přenositelný řádek profilu, a zkopírování do profilu Linuxu nebo macOS ho tam nezopakuje. Pokud na Windows veřejná jména fungují a interní selhávají, porovnejte pořadí adaptérů v Rozšířených nastaveních s ipconfig /all. Na macOS pořadí resolverů pro jednotlivé služby patří systému, takže použijte scutil --dns ke zjištění, který resolver se pro který doménu dotazuje, a každou jednotlivou hlášenou opravu profilu berte jako závislou na klientovi, ne obecnou.

Virtuální stroj na stejném notebooku nic z toho nedědí. Dejte hostovi vlastní záznam resolveru pro interní doménu, nebo nechte NAT hypervizoru přeposílat jeho dotazy přes hostitele, což je správně jen dokud je tunel hostitele aktivní.

Historie je třetí příčina. DNS servery nebo nastavení sufixu z dřívějšího profilu mohou přežít opětovná připojení, takže když adaptér vypadá správně a vyhledávání stále selhává, porovnejte živý adaptér s Get-VpnConnection a zastaralý záznam vymažte nebo přepište, než sáhnete na server.

Dokažte, kam dotaz odešel

Zachycení během jednoho vyhledávání spor rozřeší: tcpdump -ni eth0 port 53 ukazuje dotazy na fyzickém rozhraní, což znamená, že odcházejí mimo tunel a resolver nebyl nikdy přepnut. dig @10.8.0.1 name.corp.example pak oddělí dva zbývající případy. Pokud přímý dotaz odpovídá, resolver funguje a klient ho nepoužívá; pokud vyprší, resolver je přes tunel nedostupný a žádná místní změna nepomůže.

Pokud resolver, který se stále používá, je ten, který přidělil poskytovatel, tunel šifruje provoz, ale jména zůstávají tomuto poskytovateli viditelná. To je otázka úniku, ne funkčnosti, a stejné zachycení ji zodpoví: dotaz na fyzickém rozhraní jde někomu mimo tunel.

Dostupnost zahrnuje firewall na hostiteli VPN, který musí povolit UDP a TCP 53 z poolu. Zavřený port vypadá přesně jako rozbitý push, a stejně i resolver, který odpovídá jen zevnitř tunelové sítě. Zachycení zopakujte po jednom odpojení a opětovném připojení, protože nastavení, která se objeví při prvním připojení a při druhém zmizí, jsou závada životního cyklu v hooku, ne chybějící volba.

Udržte jednoho vlastníka a ověřujte v pořadí

Skript, který přepisuje DNS adaptéru podle odhadnutého stavu tunelu, duplikuje konfiguraci, kterou profil už nese, a tiše selže poprvé, když je odhad špatný. Dejte přednost vlastnímu nastavení DNS připojení nebo jednomu zdokumentovanému hooku a poznamenejte si, který jste zvolili, aby další člověk nepřidal druhý.

Uzavřete smyčku čtyřmi kontrolami: prosazená adresa je na rozhraní tunelu, interní jméno se překládá jako plně kvalifikované jméno, stejné jméno se překládá bez sufixu a obojí platí i po jednom opětovném připojení. Jedno zachycení vám řekne, která ze čtyř selhala. Příručka OpenVPN 2.6 uvádí dhcp-option a direktivy skriptů s poznámkami k platformám.