Rozdelený DNS cez OpenVPN: čo musí doména smerovania robiť v každom operačnom systéme

Každá požiadavka rozdeleného DNS sa začína tou istou vetou: mená firmy idú do DNS firmy, všetko ostatné funguje ďalej. Prementiť tú vetu na konfiguráciu znamená odpovedať na tri otázky pre každý operačný systém, a odpovede v každom používajú iné mechanizmy. Profily, ktoré fungujú na notebooku s Linuxom, často zlyhávajú vo Windows z dôvodov, ktoré nemajú nič spoločné s tunelom. Rozdiel je zvyčajne nastavenie prekladača považované za trasu.

Najprv pomenujte politiku, potom vyberte primitív platformy, ktorý ju vyjadruje.

Tri nastavenia, ktoré sa ľahko pomýlia

Sufix vyhľadávania rozširuje krátke meno: napísanie files sa zmení na files.corp.example, keď prekladač skúša sufixy po poradí. Doména smerovania vyberá, ktorý prekladač odpovedá na dopyty v rámci menného priestoru. IP trasa robí dostupným iba vybraný prekladač. Tieto tri žijú v rôznych vrstvách, a nahradenie jedného druhým dá konfiguráciu, ktorá vyzerá správne a nič nerieši.

Zmätok má svoju cenu: pridanie sufixu vyhľadávania pošle každé krátke meno na pracovný prekladač, vrátane mien, ktoré patria inam. Výber domény smerovania ponechá nesúvisiace dopyty na lokálnom prekladači a napriek tomu pošle *.corp.example cez tunel.

Linux: doména iba pre trasu, nie sufix vyhľadávania

V systemd-resolved je doména s vlnovkou na začiatku doménou iba pre trasu, čo znamená, že dopyty pre ten menný priestor idú na prepojený prekladač bez toho, aby sa stali aj sufixom vyhľadávania. resolvectl domain tun0 '~corp.example' to nastaví, a resolvectl dns tun0 10.8.0.1 pomenuje server. Obe nastavenia patria rozhraniu, takže zmiznú spolu s ním. Vlnovka je tá časť, ktorú ľudia vynechávajú, a bez nej sa krátke mená začnú prekladať cez pracovný prekladač.

Neinštalujte tú istú doménu aj ako globálny sufix vyhľadávania. Obe nastavenia nie sú nadbytočné; jedno smeruje a druhé prepisuje to, čo ste napísali.

Windows potrebuje politiku menného priestoru, nie sufix

Windows uchováva politiku rozdeleného DNS v Name Resolution Policy Table, nie v DNS sufixe adaptéra. Pravidlo priraďuje menný priestor konkrétnym serverom: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. Nastavenie iba sufixu mení vzhľad krátkych mien; nepresmeruje dopyt na iný server.

Po pripojení skontrolujte účinnú politiku pomocou Get-DnsClientNrptPolicy, pretože pravidlo z predchádzajúceho pripojenia môže tunel prežiť. Odstraňujte pravidlá podľa mena, keď tunel padne, a udržujte zobrazované meno stabilné, aby čistenie zasiahlo správny záznam.

Jeden vlastník prekladača na platformu

Správca pracovnej plochy, up skript OpenVPN a lokálny démon prekladača môžu všetci skúsiť zapísať tú istú konfiguráciu. Keď sa nezhodnú, vyhrá posledný pisateľ a výsledok závisí od poradia demontáže. Vyberte jeden komponent, ktorý vlastní stav prekladača, nechajte ostatných reportovať namiesto písania, a otestujte opätovné pripojenie: politika by ho mala prežiť bez duplikovania pravidiel. Otestujte aj odpojenie, pretože práve zostávajúci stav spôsobuje, že ďalšie pripojenie sa správa inak.

Aplikácie, ktoré si prinášajú vlastný šifrovaný prekladač, ignorujú politiku operačného systému úplne. Je to vlastnosť aplikácie, nie chyba tunela.

Skontrolujte výsledok, nie text profilu

Vyriešte jedno meno, ktoré má prejsť tunelom, a jedno, ktoré nemá, na každej platforme, a potvrďte, ktorý server odpovedal. resolvectl query host.corp.example a Resolve-DnsName host.corp.example oba hlásia server, ktorý odpovedal. Zopakujte po opätovnom pripojení. Potom potvrďte, že prekladač tunela je dostupný na adrese, ktorú profil tlačí, pretože správna politika ukazujúca na nedostupný server zlyhá rovnako ako žiadna politika.

Zaznamenajte zamýšľané správanie do poznámok profilu: ktorý sufix smeruje, ktorý server naň odpovedá a čo sa deje so všetkým ostatným. Ďalšia podporovaná platforma bude tú vetu potrebovať viac než konfiguračný súbor.