Rozdělený DNS přes OpenVPN: co musí směrovací doména dělat na každém operačním systému

Každý požadavek na rozdělený DNS začíná stejnou větou: názvy firmy jdou do firemního DNS, všechno ostatní funguje dál. Převést tuto větu na konfiguraci znamená odpovědět na tři otázky pro každý operační systém a odpovědi používají na každém jiné mechanismy. Profily, které fungují na notebooku s Linuxem, často na Windowsu selhávají z důvodů, které s tunelem nemají nic společného. Rozdíl bývá v tom, že se nastavení resolveru zamění za trasu.

Nejprve pojmenujte zásadu, pak vyberte primitivum platformy, které ji vyjadřuje.

Tři nastavení, která je snadné si splést

Sufix prohledávání rozšiřuje krátký název: napsání files se změní na files.corp.example, když resolver zkouší sufixy popořadě. Směrovací doména vybírá, který resolver odpovídá na dotazy v daném jmenném prostoru. IP trasa jen zpřístupní zvolený resolver. Tyto tři věci žijí v různých vrstvách a záměna jedné za druhou vytvoří konfiguraci, která vypadá správně a nic nevyřeší.

Záměna má cenu: přidání sufixu prohledávání pošle každý krátký název firemnímu resolveru, včetně názvů, které patří jinam. Volba směrovací domény ponechá nesouvisející dotazy na místním resolveru a přitom stále posílá *.corp.example tunelem.

Linux: doména jen pro směrování, ne sufix prohledávání

V systemd-resolved je doména s vlnovkou na začátku doménou jen pro směrování, což znamená, že dotazy pro tento jmenný prostor jdou propojenému resolveru, aniž by se zároveň staly sufixem prohledávání. resolvectl domain tun0 '~corp.example' to nastaví a resolvectl dns tun0 10.8.0.1 pojmenuje server. Obě nastavení patří rozhraní, takže s ním zmizí. Vlnovka je část, kterou lidé vynechávají, a bez ní se krátké názvy začnou překládat přes firemní resolver.

Neinstalujte stejnou doménu také jako globální sufix prohledávání. Tato dvě nastavení nejsou nadbytečná; jedno směruje a druhé přepisuje to, co jste napsali.

Windows potřebuje zásadu jmenného prostoru, ne sufix

Windows uchovává zásadu rozděleného DNS v tabulce zásad překladu názvů, ne v DNS sufixu adaptéru. Pravidlo přiřazuje jmenný prostor konkrétním serverům: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. Nastavení samotného sufixu mění podobu krátkých názvů; neposílá dotaz na jiný server.

Po připojení zkontrolujte platnou zásadu pomocí Get-DnsClientNrptPolicy, protože pravidlo z dřívějšího připojení může tunel přežít. Když tunel spadne, odstraňte pravidla podle názvu a držte zobrazovaný název stabilní, aby úklid zasáhl správnou položku.

Mějte jednoho vlastníka resolveru na platformu

Správce pracovní plochy, skript up pro OpenVPN a místní démon resolveru mohou všichni zkoušet zapsat stejnou konfiguraci. Když se neshodnou, vyhraje ten, kdo zapisoval naposledy, a výsledek závisí na pořadí rozebrání. Vyberte jednu komponentu, která vlastní stav resolveru, nechte ostatní hlásit místo zapisovat a otestujte opětovné připojení: zásada by ho měla přežít bez duplikování pravidel. Otestujte i odpojení, protože zbytkový stav je to, co způsobí, že se příští připojení chová jinak.

Aplikace, které si přinášejí vlastní šifrovaný resolver, ignorují zásadu operačního systému úplně. To je vlastnost aplikace, ne vada tunelu.

Ověřujte výsledek, ne text profilu

Na každé platformě přeložte jeden název, který má jít tunelem, a jeden, který nemá, a potvrďte, který server odpověděl. resolvectl query host.corp.example i Resolve-DnsName host.corp.example hlásí server, který odpověděl. Po opětovném připojení to zopakujte. Pak potvrďte, že resolver tunelu je dostupný na adrese, kterou profil vnutí, protože správná zásada mířící na nedostupný server selhává stejně jako žádná zásada.

Poznamenejte zamýšlené chování do poznámek profilu: který sufix se směruje, který server na něj odpovídá a co se stane se vším ostatním. Příští platforma, kterou podpoříte, bude tu větu potřebovat víc než konfigurační soubor.