Рейтинг:0

Не удалось разрешить частную зону DNS через vpn с DNS bind9

флаг ca

Эта проблема

У меня есть VPC, в котором мне нужно получить доступ к серверам, используя частные полные доменные имена. VPC доступен через wireguard VPN. Сервер VPN также служит DNS-сервером, на котором работает BIND9. Я установил DNS-сервер с частной зоной в соответствии с этим руководство. Изнутри VPC DNS работает должным образом, и я могу получить доступ к серверам по полным доменным именам, определенным в зоне DNS.

При подключении к VPC через VPN-туннель я не могу разрешить эти полные доменные имена, хотя я настроил свой VPN-клиент на использование моего частного DNS-сервера. Я знаю, что VPN-клиент использует мой частный DNS-сервер, потому что когда я запускаю nslookup google.com Я вижу IP-адрес моего DNS, как вы можете видеть в результате ниже:

Сервер: 10.118.0.2
Адрес: 10.118.0.2#53
...

Если я запускаю nslookup myprivate.domain.com с машины, подключенной к VPC через VPN-туннель, я получаю NXDOMAIN, то же самое касается пинг, вылетает с ошибкой Имя или услуга не известны. Однако, если я запускаю ping на частном IP-адресе из VPC, он работает. Так что если мой частный.домен.com размещен на сервере по адресу10.118.0.3, проверка связи по IP-адресу завершается успешно, но по полному доменному имени происходит сбой.

Кроме того, посмотрите результаты раскопок внутри VPC и с машины, подключенной через VPN: копать dev.myprivatedomain.com нс: ОТ ВКК:

;; ->>HEADER<<- код операции: QUERY, статус: NOERROR, id: 51703
;; флаги: qr aa rd ra; ЗАПРОС: 1, ОТВЕТ: 1, ПОЛНОМОЧИЯ: 0, ДОПОЛНИТЕЛЬНО: 1

;; ДОПОЛНИТЕЛЬНЫЙ ПСЕВДОРАЗДЕЛ:
; ЭДНС: версия: 0, флаги:; UDP: 4096
; COOKIE: 9dccc02158dee7f70100000061a7e0a1ce2597e377b9c301 (хорошо)
;; РАЗДЕЛ ВОПРОСОВ:
;dev.myprivatedomain.com. В НС

;; ОТДЕЛ ПОЛНОМОЧИЙ:
nabuinternal.com. 604800 В SOA ns1.myprivateddomain.com. ...

;; Время запроса: 0 мс
;; СЕРВЕР: 10.118.0.2#53(10.118.0.2)
;; КОГДА: ср, 01 декабря, 20:52:49 UTC 2021
;; РАЗМЕР MSG rcvd: 93

ОТ ВПН:

;; Получил ответ:
;; ->>HEADER<<- код операции: QUERY, статус: NXDOMAIN, идентификатор: 57158
;; флаги: qr rd ra; ЗАПРОС: 1, ОТВЕТ: 0, АВТОРИЗАЦИЯ: 1, ДОПОЛНИТЕЛЬНО: 1

;; ДОПОЛНИТЕЛЬНЫЙ ПСЕВДОРАЗДЕЛ:
; ЭДНС: версия: 0, флаги:; УДП: 1232
;; РАЗДЕЛ ВОПРОСОВ:
;dev.myprivatedomain.com. В НС

;; ОТДЕЛ ПОЛНОМОЧИЙ:
ком. 900 В SOA a.gtld-servers.net. nstld.verisign-grs.com. 1638392201 1800 900 604800 86400

;; Время запроса: 44 мс
;; СЕРВЕР: 10.118.0.2#53(10.118.0.2)
;; КОГДА: среда, 1 декабря, 15:57:05 по восточному стандартному времени 2021 г.
;; РАЗМЕР MSG rcvd: 122

Я замечаю, что оба используют один и тот же DNS-сервер, но при запросе из VPN не возвращаются полномочия для моего частного домена.

В заключении, после нескольких часов исследований мне не удалось выяснить, чего не хватает клиентам, подключающимся к VPC через VPN, чтобы иметь возможность разрешать полные доменные имена, определенные моим частным DNS.

Дополнительная информация

  • Сервер Ubuntu 20.04 LTS.
  • Связка 9: BIND 9.16.1-Ubuntu (стабильная версия)
  • проволока: Wireguard-инструменты v1.0.20200513 установлен через проводную скорость
  • UFW включен

IP-адрес VPN и DNS-сервера в VPC 10.118.0.2.

Пул адресов VPN 10.99.0.0/16 и я установил конфигурации BIND9 следующим образом:

список "доверенных" {
    10.118.0.2; # впн и днс сервер
    ...
    10.99.0.0/16; # пул адресов vpn
    
};
параметры {
    директория "/var/cache/bind";
    слушать-на-v6 { любой; };
    рекурсия да;
    разрешить-рекурсию { доверенный; };
    прослушивание { 10.118.0.0/20; 10.99.0.0/16; };  
    разрешить передачу {нет; };
    экспедиторы {
            8.8.8.8;
            8.8.4.4;
    };
};

Зона настроена так:

$TTL 604800
@ В SOA ns1.myprivateddomain.com. admin.myprivatedomain.com. (
                              9; Серийный
                         604800 ; Обновить
                          86400 ; Повторить попытку
                        2419200 ; Срок действия
                         604800 ) ; Отрицательный TTL кэша
;                         
; серверы имен — записи NS
    В NS ns1.myprivateddomain.com.

; серверы имен - записи A
ns1.myprivatedomain.com. В А 10.118.0.2

; 10.118.0.0/20 - записи А
dev.myprivatedomain.com. В А 10.118.0.4
staging.myprivateddomain.com. В А 10.118.0.3

и файл обратной зоны:

$TTL 604800
@ В SOA ns1.myprivateddomain.com. admin.myprivatedomain.com. (
                              7; Серийный
                         604800 ; Обновить
                          86400 ; Повторить попытку
                        2419200 ; Срок действия
                         604800 ) ; Отрицательный TTL кэша
;
; серверы имен — записи NS
    В NS ns1.myprivateddomain.com.

; Записи PTR
2.0 В PTR ns1.myprivatedomain.com. ; 10.118.0.2
4.0 В PTR dev.myprivateddomain.com. ; 10.118.0.4
3.0 В PTR staging.myprivateddomain.com. ; 10.118.0.3

UFW настроен на разрешение порта 53 как для TCP, так и для UDP.

Кроме того, в UFW есть правила, разрешающие трафик из VPN:

*натуральный
:ОТПРАВКА ПРИНЯТИЯ [0:0]
-A POSTROUTING -s 10.99.0.0/16 -o eth1 -j MASQUERADE

Предыдущее правило было настроено, чтобы разрешить клиенту подключаться к VPN-туннелю и использовать частный DNS-сервер. Без этого правила я не смогу получить доступ к Интернету, если не установлю общедоступный DNS-адрес, такой как адрес Google. Я нашел это правило во время своего исследования, однако я еще не очень хорошо знаком с конфигурациями брандмауэра и еще не полностью понимаю его значение. Это помогло мне приблизиться к моей цели, но мне нужно больше читать об этом.

Ниже приведена конфигурация клиента wireguard VPN:

[Интерфейс]
...
DNS = 10.118.0.2
Адрес = 10.99.0.2/16

[Вглядеться]
...
Разрешенные IP-адреса = 10.99.0.0/16, 10.118.0.0/20

флаг cn
Bob
Ваша конфигурация привязки показывает только серверы пересылки, но не свидетельствует о том, что она является авторитетной для вашего частного (под)домена. Как правило, когда вы запускаете собственный DNS-сервер, вам также необходимо настроить одну или несколько зон с вашими частными (или общедоступными) записями DNS.
Arnaud Songa-Côté avatar
флаг ca
@Bob Я обновил свой пост, включив в него файлы зоны и обратной зоны, которые настраивают мои частные поддомены.
djdomi avatar
флаг za
прослушивание настроено неправильно, это может быть IP-адрес сервера или интерфейс

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.