Interní názvy na VPN selhávají, veřejné weby se načítají

Jeden uživatel hlásí, že se název hostitele z intranetu přes VPN nepřekládá. Druhé hlášení ze stejného notebooku říká, že test úniku stále ukazuje dotazy odpovídané místním resolverem. Zní to jako jeden problém a jsou to dva, s různými důkazy, a obvyklá oprava prvního zhorší druhý. Oddělte je, než sáhnete na jakékoli nastavení.

Dva příznaky, které nejsou jedna závada

Nepodařilo se přeložit interní název znamená, že dotaz šel někam, kde na něj odpověď není. Dotazy opouštějící tunel znamenají, že dotaz šel na špatné místo, i když odpověď byla k dispozici. To jsou opačné závady: jedna je chybějící odpověď, druhá je nadbytečný cíl.

Past je v tom, že přidání kancelářského resolveru všude opraví první a zaručí druhou. Přidání veřejného resolveru všude udělá opak.

Zapište obě pozorování s časovým razítkem a pak projděte čtyři kontroly níže v pořadí.

Čí resolver adaptéru dostane dotaz

Ve Windows klient DNS vybírá servery podle pořadí vazeb adaptérů a tunelový adaptér není automaticky první. Otevřete rozšířené nastavení adaptéru a přesuňte připojení vzdáleného přístupu nad fyzický adaptér, potom se znovu připojte, aby změna platila v nové relaci.

Pořadí vazeb je jen první polovina. Klient také musí vědět, které názvy k tomu adaptéru patří, a to je otázka sufixu, ne pořadí.

Položte výstup ipconfig /all z funkčního počítače vedle výstupu z notebooku, oba pořízené se zvednutým tunelem. Funkční počítač ukáže sufix DNS specifický pro připojení na svém kancelářském adaptéru a notebook nemusí na tunelu ukázat nic. Ten rozdíl vysvětluje celou třídu hlášení typu server je přímo tam a název přesto selhává, protože bez sufixu se krátký název nikdy nedoplní do zóny, kterou kancelářský resolver obsluhuje.

Krátký název potřebuje sufix dřív než trasu

Psaní nekvalifikovaného názvu hostitele žádá resolver, aby uhodl doménu. Tip přichází ze seznamu sufixů připojeného k připojení, a je-li tento seznam prázdný, dotaz vyjde jako jediný label, kterému žádná privátní zóna neodpovídá.

Zkopírujte sufix z funkčního počítače do vlastností IPv4 adaptéru VPN na kartě DNS a znovu se připojte. V Linuxu je ekvivalentem vyhledávací doména na tunelovém spoji, kterou systemd-resolved vystavuje pro každý spoj, ne globálně.

Držte obě nastavení v poznámkách odděleně. Sufix mění, na co se ptáme; adresa resolveru mění, koho se ptáme. Oprava jednoho, když je druhé špatně, dává výsledek, který vypadá náhodně.

Zeptejte se resolveru přímo, pak názvu

Přímý dotaz na kancelářský resolver odděluje problém názvu od problému cesty, protože úplně obchází volbu resolveru klientem.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

První příkaz se ptá konkrétního serveru na plně kvalifikovaný název. Pokud odpoví, resolver i trasa k němu jsou v pořádku a závada je ve volbě nebo v sufixu. Pokud vyprší čas, adresa je špatná nebo nedostupná a problém je v směrování, ne v DNS. Druhý příkaz ukazuje, co se děje s krátkým názvem, a třetí vypíše konfiguraci resolveru pro každý spoj na hostiteli se systemd.

Sledujte odpovědi typu wildcard, které některé sítě vracejí pro neznámé názvy. Věrohodná odpověď není důkaz, že odpověděl zamýšlený server, proto porovnejte vrácenou adresu s tou, kterou interní služba skutečně používá. Pokud adresa patří parkovací stránce nebo proxy, resolver odpověděl, ale odpověď nikdy nebyla vaše. Ten rozdíl ušetří hodinu honění tunelu, který celou dobu fungoval.

V Linuxu klient VPN, který přepisuje /etc/resolv.conf, nahrazuje místní resolvery úplně. vpnc vystavuje DNSUpdate no, aby tomu zabránil, a systemd-resolved umí na tunelový spoj směrovat jen uvedené domény. Oba přístupy drží veřejné názvy na místním resolveru a posílají interní názvy do kanceláře.

Úniky jsou pravidlo, ne zaškrtávací pole

Překlad názvů je UDP výměna na port 53, takže tunel, který nese webový provoz ale ne UDP, nechává dotaz na fyzické cestě. Dokažte to zachycením na fyzické síťové kartě, zatímco se překládá veřejný název. Dotaz viditelný na tomto rozhraní v čitelné podobě znamená, že ho tunel nenese.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Pokud se dotaz na tomto rozhraní objeví v čitelné podobě, tunel ho nenese. Opravou je pravidlo, které povoluje port 53 jen resolveru, který VPN vnutila, a zahazuje ostatní cíle, plus konfigurace klienta, která vnucenou volbu tiše nezahodí.

Ta poslední část je důležitější, než vypadá. Spusťte OpenVPN s route-nopull a vnucená volba DNS zmizí spolu s trasami, pokud se filtr vytahování nerozšíří, aby ji udržel. A klient, který dhcp-option DNS ignoruje, bude dál používat to, co měl předtím. Jakákoli změna na straně serveru potřebuje novou relaci, protože seznam resolverů se doručuje při zvednutí tunelu a stará relace dál ukazuje starý stav.

Zapište, kterou závadu jste skutečně pozorovali, než tiket zavřete. Chybějící interní odpověď a dotaz unikající z tunelu chtějí různé opravy a změna sufixu, která opraví první, může tiše zhoršit druhou. Kdo tiket převezme po vás, bude věřit popisce, tak popisek udělejte přesný.