Разделен DNS през OpenVPN: какво трябва да прави маршрутизиращият домейн на всяка ОС

Всяка заявка за разделен DNS започва с едно и също изречение: имената на компанията отиват в DNS на компанията, всичко останало продължава да работи. Превръщането на това изречение в конфигурация означава отговор на три въпроса за всяка операционна система, а отговорите използват различни механизми на всяка от тях. Профилите, които работят на лаптоп с Linux, често се провалят на Windows по причини, които нямат нищо общо с тунела. Разликата обикновено е, че настройка на резолвър се бърка с маршрут.

Първо назовете политиката, после изберете примитива на платформата, който я изразява.

Три настройки, които лесно се бъркат

Суфиксът за търсене разширява кратко име: написването на files става files.corp.example, когато резолвърът изпробва суфиксите по ред. Маршрутизиращият домейн избира кой резолвър да отговаря на заявките в дадено пространство от имена. IP маршрутът само прави избрания резолвър достъпен. Тези три живеят в различни слоеве и замяната на едно с друго дава конфигурация, която изглежда правилна и не разрешава нищо.

Бъркотията има цена: добавянето на суфикс за търсене изпраща всяко кратко име към работния резолвър, включително имена, които принадлежат другаде. Изборът на маршрутизиращ домейн оставя несвързаните заявки на локалния резолвър, като същевременно изпраща *.corp.example през тунела.

Linux: домейн само за маршрутизиране, а не суфикс за търсене

В systemd-resolved домейн с префикс тилда е домейн само за маршрутизиране, което означава, че заявките за това пространство от имена отиват към свързания резолвър, без да стават и суфикс за търсене. resolvectl domain tun0 '~corp.example' задава това, а resolvectl dns tun0 10.8.0.1 посочва сървъра. Двете настройки принадлежат на интерфейса, затова изчезват заедно с него. Тилдата е частта, която хората пропускат, и без нея кратките имена започват да се разрешават през работния резолвър.

Не инсталирайте същия домейн и като глобален суфикс за търсене. Двете настройки не се дублират; едната маршрутизира, другата пренаписва написаното от вас.

Windows се нуждае от политика за пространство от имена, не от суфикс

Windows пази политиката за разделен DNS в таблицата с правила за разрешаване на имена, а не в DNS суфикса на адаптера. Правилото свързва пространство от имена с конкретни сървъри: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. Задаването само на суфикса променя вида на кратките имена; то не насочва заявката към друг сървър.

Проверете действащата политика с Get-DnsClientNrptPolicy след свързване, защото правило от предишно свързване може да надживее тунела. Премахвайте правилата по име, когато тунелът падне, и дръжте показваното име стабилно, за да уцели почистването правилния запис.

Дръжте един собственик на резолвъра за всяка платформа

Мениджър на работния плот, up скрипт на OpenVPN и локален демон на резолвър могат да се опитат да запишат една и съща конфигурация. Когато не са съгласни, печели последният записал и резултатът зависи от реда на разглобяване. Изберете един компонент, който да притежава състоянието на резолвъра, оставете другите да докладват, вместо да пишат, и тествайте повторно свързване: политиката трябва да го преживее без дублиране на правила. Тествайте и прекъсване, защото остатъчното състояние е това, което кара следващото свързване да се държи различно.

Приложенията, които носят свой криптиран резолвър, напълно пренебрегват политиката на операционната система. Това е свойство на приложението, а не дефект в тунела.

Проверявайте резултата, а не текста на профила

Разрешете едно име, което трябва да мине през тунела, и едно, което не трябва, на всяка платформа, и потвърдете кой сървър е отговорил. resolvectl query host.corp.example и Resolve-DnsName host.corp.example и двете съобщават сървъра, който е отговорил. Повторете след повторно свързване. След това потвърдете, че резолвърът на тунела е достъпен на адреса, който профилът налага, защото правилна политика, сочеща към недостъпен сървър, се проваля по същия начин като липсата на политика.

Запишете предвиденото поведение в бележките на профила: кой суфикс се маршрутизира, кой сървър отговаря на него и какво се случва с всичко останало. Следващата платформа, която поддържате, ще има нужда от това изречение повече, отколкото от конфигурационния файл.