Proč privátní názvy DNS selhávají na klientech VPN a kde to zkontrolovat

Otevřete notebook v hotelovém pokoji, spustíte klienta, napíšete název interního souborového serveru a nic nedostanete. Tunel hlásí připojeno a ping na adresu ve stejné podsíti stále odpovídá, takže transport samotný je v pořádku. Selhává jen název, a ta mezera zužuje problém na dvě místa: na který resolver se klient ptal a zda se odpověď, kterou dostal, může vrátit tunelem. Opravte jedno a druhé vynechejte, a závada se prostě posune.

Než začnete upravovat jakýkoli profil, ověřte, co klient s názvem dělá. Na Linuxu resolvectl query files.corp.example ukáže, přes které rozhraní a který resolver odpověď vznikla. Na Windows Resolve-DnsName files.corp.example ukáže server, který odpověděl, a adresu, kterou vrátil.

Přečtěte si odpověď, než cokoli změníte

Pokud se název vrátí jako NXDOMAIN během několika milisekund, dotaz se k vaší zóně nikdy nedostal a odpověděl nějaký veřejný nebo hotelový resolver. Pokud se vrátí až po dlouhé pauze, něco cestou zahazuje UDP port 53 a klient nakonec sáhl po záloze. Pokud odpoví správnou adresou, ale spojení stále visí, překlad je v pořádku a váš problém je v routingu nebo v samotné službě.

Tohle rozdělení na tři ušetří hodinu hádání. Také vám řekne, zda se do VPN vůbec pouštět: název, který se přeloží na správnou privátní adresu, už důkaz cesty resolveru podal, takže zbývající práce je na datové cestě.

Rozdejte resolver zevnitř tunelu

Klienti se dělí do dvou skupin. Jedné může server resolver předat při navazování spojení; druhá drží nastavení v místním souboru, který žádná brána nedokáže změnit na dálku.

OpenVPN patří do první skupiny. Na serveru putují push "dhcp-option DNS 10.8.0.53" a push "dhcp-option DOMAIN corp.example" řídicím kanálem, ale jen když má konfigurace klienta stále zapnuté pull. Ručně upravený klient s pull-filter ignore "dhcp-option" je nikdy neuvidí, a ten jediný řádek vysvětluje překvapivě mnoho případů typu „server to posílá, ale můj notebook nesouhlasí“.

WireGuard patří do druhé skupiny, protože protokol nemá vůbec žádné vyjednávání voleb. Resolver a vyhledávací doména jdou do vlastního bloku [Interface] klienta jako DNS = 10.8.0.53, corp.example. wg-quick to aplikuje přes resolvconf nebo systemd-resolved a ve Windows oficiální klient nainstaluje pravidla NRPT, která existují jen po dobu, kdy je tunel nahoru: Get-DnsClientNrptPolicy je vypíše, což z něj dělá rychlý způsob, jak zjistit, zda klient váš soubor vůbec aplikoval.

IPsec/IKEv2 stojí mezi nimi. Plugin attr od strongSwanu může vrátit DNS server vytažený z poolu a windowsový klient ho obvykle přijme, ale profil, který si prosazuje vlastní jmenný server, vyhraje nad čímkoli, co brána nabídne. Na linuxovém klientovi je ekvivalentním ručním krokem resolvectl dns wg0 10.8.0.53 následované resolvectl domain wg0 '~corp.example'; obojí zmizí spolu s rozhraním, což je přesně to, co u nastavení vázaného na tunel chcete.

Vymezte sufix místo toho, abyste spolkli každý dotaz

Nasměrovat celý seznam resolverů klienta na váš interní server je snadné a většinou špatné. Každý veřejný název se pak překládá přes výstup vašeho datového centra, CDN vracejí vzdálené adresy a jeden výpadek resolveru s sebou vezme i prohlížení uživatele.

Posílejte dovnitř jen privátní sufix. V systemd-resolved je doména začínající na ~ jen pro routing, takže ~corp.example znamená, že dotazy pod tímto sufixem jdou na servery toho rozhraní, zatímco všechno ostatní dál používá fyzickou síť. Windows dělá totéž pomocí pravidel NRPT vymezených na jmenný prostor a macOS pomocí doplňkového souboru resolveru v /etc/resolver/.

Multicastové názvy si zaslouží vlastní odpověď. Názvy .local jsou z podstaty link-local (RFC 6762) a tun rozhraní typu bod-bod tento multicastový kanál nenese, takže přidání veřejného resolveru je nezveřejní a dotaz na interní unicastový resolver vrátí NXDOMAIN. Reflector, jako je avahi v režimu reflector, dokáže spojit dva segmenty, ale to je rozhodnutí na straně serveru, které žádný klient nemůže vyžádat. Pokud musí být tiskárna nebo NAS dostupné podle názvu, dejte jim raději záznam A ve své zóně.

Dokažte, že se odpověď může vrátit

Správná odpověď ukazující na nedosažitelnou adresu vypadá přesně jako problém resolveru, dokud si nezkontrolujete trasu. Zeptejte se jádra, kam by odpověď šla: ip route get 10.20.5.20 pojmenuje rozhraní a užitečněji zdrojovou adresu, kterou by použilo.

Sledujte samotnou adresu resolveru. Klient s DNS = 10.8.0.53 vedle AllowedIPs = 10.20.0.0/16 posílá své dotazy ven fyzickou NIC, kde tiše umírají, protože resolver neleží v žádném prefixu, který tunel nárokuje. Ten rozpor je nejčastější jednopříčinná závada v celé této oblasti a zůstává neviditelný, dokud neporovnáte nastavení DNS s povolenými prefixy řádek po řádku.

Překrývající se rozsahy způsobují opačnou závadu. Odpověď je správná, trasa existuje a ukazuje na špatný hostitel, protože 192.168.0.0/24 doma je konkrétnější než trasa tunelu do stejného rozsahu. Přečíslujte jednu stranu nebo protlačte užší trasu, pak ověřte firewall a zpáteční cestu hostitele služby; poznámky strongSwanu o předávání pokrývají stránku sysctl této cesty.

Certifikáty jsou samostatná kontrola identity, kterou lidé svádějí na DNS. Pokud prohlížeč hlásí neshodu názvu místo chyby překladu, vyhledání už fungovalo a opravit je třeba SAN v certifikátu. Testujte HTTPS proti názvu, nikdy proti holé IP.

Otestujte to znovu z klienta, ne z brány

Testujte v aplikaci, na kterou si uživatel stěžuje, protože vyhledání z příkazové řádky nedokazuje, že prohlížeč jde stejnou cestou. Zabezpečené DNS Chromu a network.trr.mode ve Firefoxu mohou systémový resolver úplně obejít, a když to udělají, privátní název buď selže, nebo unikne veřejnému resolveru. Porovnání resolvectl query s ručně spuštěným dig @10.8.0.53 files.corp.example vám řekne, který z těch dvou případů nastal.

Potom se odpojte a připojte znovu, než to prohlásíte za opravené. Nastavení zadaná ručně na rozhraní zmizí spolu s rozhraním a profil, který vypadal správně jen kvůli zapomenuté místní úpravě, selže při příštím startu.

Krátký kontrolní seznam pro další stroj: název se přeloží přes resolver tunelu, sufix je vymezený, ne globální, adresa resolveru leží uvnitř povolených prefixů, hostitel z odpovědi odpovídá na portu služby a certifikát pokrývá název, který uživatel napsal.