WireGuard не изпраща DNS: обслужване на частна зона BIND

Ръкостискането носи ключове и разрешени IP адреси, но никога резолвер. Ето готова частна зона BIND 9 плюс клиентска политика за всяка връзка, която я кара да работи.

Вдигнахте WireGuard, тунелът прекарва трафик, а вътрешното име все още не се резолвва. Следващата стъпка обикновено е да търсите DNS настройка в конфигурацията на WireGuard, сякаш партньор може да изпрати резолвер, както правят някои други VPN. Не може. Ръкостискането носи ключове, адреси на интерфейса и разрешени IP адреси и няма поле за DNS сървъри или домейни за търсене. Политиката на резолвера живее на клиента и точно там е мястото на поправката.

Тунелът и резолверът са отделни договори

WireGuard е умишлено малък. Той движи пакети за адресите, които изброите, и удостоверява партньорите; всичко над този слой е вашият дизайн. OpenVPN може да изпрати dhcp-option DNS, защото контролният му канал носи конфигурация, и тази разлика обърква хората, които минават между двете.

Така че работещ тунел не ви казва нищо за резолвването на имена. Клиентът може да има перфектен маршрут до 10.90.0.1 и пак да изпраща заявките си до публичен резолвер; затова симптомът изглежда като “VPN счупи DNS”, а всъщност DNS никога не е бил насочван към VPN.

Обслужвайте зоната, без да ставате рекурсивен резолвер

Страната на сървъра е малка авторитетна зона, не общ резолвер. В този пример шлюзът е 10.90.0.1, клиентите са 10.90.0.0/24, а приложението, което ви интересува, отговаря на 10.60.0.20.

Слейте тези настройки в съществуващия блок options, вместо да създавате втори:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

След това декларирайте зоната и нейния файл:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};
$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

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

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

Отворете UDP и TCP 53 само на VPN интерфейса. Публикуването на частен авторитет на публичния интерфейс кани както заявки, така и изброяване, а allow-transfer трябва да остане затворен, освен ако вторичен наистина не се нуждае.

Насочете клиента към него, за всяка връзка

Приемете, че NetworkManager притежава връзката, а systemd-resolved е резолверът. Прочетете първо съществуващата политика, особено всеки коренов домейн за маршрутизиране, защото запис ~. ще надделее над това, което ще добавите.

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

Тилдата е важният знак. Тя маркира домейна като само-маршрут: имената под corp.example отиват към DNS сървъра на тази връзка и домейнът не се добавя като наставка за търсене на кратко име. Без нея писането на portal започва да резолвва portal.corp.example, което е удобно за вас и изненадващо за всички останали. Дръжте тилдата в кавичките, защото нецитирана тя е shell разширение, което чака да сочи към домашната ви директория.

Приложете промяната чрез мениджъра, който притежава интерфейса, после свържете връзката отново. Не стартирайте втори екземпляр на wg-quick за същия интерфейс; двама собственици ще се бият за маршрути и един от тях ще победи в най-лошия момент.

Проверете пътя преди името

Заявете името от клиента и потвърдете както отговора, така и сървъра, който го е издал:

resolvectl query portal.corp.example

Ако това върне 10.60.0.20, DNS договорът е изпълнен. Ако изтече времето, проверете първо маршрута до 10.90.0.1, после правилото на защитната стена, после allow-query на сървъра. Провалите на резолвване в тази конфигурация почти винаги са достижимост или ACL, не зоновият файл. Работете от клиента навън, защото сървърът не може да ви каже защо заявка не е пристигнала.

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

Какво все още не е автоматично

Приложенията със собствена логика за резолвване напълно игнорират системния резолвер и никакво количество nmcli не променя това. Внедряванията, които валидират DNSSEC, се нуждаят от ясен дизайн на доверителна котва за частната зона; отговорът не е обща инструкция да се изключи валидирането. Тествайте със същия клиентски софтуер, който използват вашите потребители, а не с инструмент, който случайно ползва системния резолвер. Разликата между тези две е целият доклад за грешка.

Флотите могат да автоматизират тази клиентска политика чрез системата си за предоставяне, но политиката остава отделен обект със собственик. Справочникът за BIND 9 покрива контролите за слушане и заявки, използвани по-горе, и е правилното място да потвърдите поведението за вашата инсталирана версия.

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

Подобни статии