Предоставление внутреннего маршрута53 DNS через VPN для локальной ActiveDirectory

Ситуация

Мы переносим наши веб-приложения на AWS. Чтобы соединить нашу локальную сеть и AWS, мы создали VPN-соединение. Это работает без проблем.

На месте у нас есть MS AD (2008 R2), который является авторитетным сервером для (среди прочего) ourcompany.tld (не фактическое имя домена;))

В AWS мы хотим, чтобы все внутренние службы были названы так: *.dev.ourcompany.tld. Этот DNS должен быть разрешен внутренним маршрутом53.

На AWS публичные ресурсы называются *.ourcompany.tld. Этот DNS разрешен нашими собственными серверами имен. (за работой)

Эта проблема

В нашей локальной сети мы хотим разрешить someserver.dev.saa.nl. Чтобы добиться этого, наш MS ActiveDirectory должен выполнить поиск AWS для этого доменного имени.

Внутренний маршрут AWS53 доступен только из AWC VPC. AD не может достичь этого напрямую.

Внутренний маршрут AWS53 доступен только через DNS-сервер пересылки VPC, который не является полномочным.

MS AD требует авторитетного источника для заглушек и условных пересылок.

Что мы сделали / попробовали

  • Создайте DNS-сервер пересылки в VPC. Этот экспедитор не является авторитетным. Это хорошо работает, когда вы устанавливаете DNS-сервер пересылки в качестве основного DNS на самом компьютере. ActiveDirectory не позволяет нам создавать заглушку или условный сервер пересылки с сообщением о том, что сервер не является полномочным.
  • Создайте DNS-сервер с зоной-заглушкой для dev.ourcompany.tld в amazon VPC. При создании зоны-заглушки она будет сообщать о том, что она является доверенной, однако, поскольку мы можем разрешить DNS только через DNS-сервер пересылки VPC (на VPC IP + 2), она отказывается создавать заглушку, поскольку ее источник не является полномочным. Прямое подключение к авторитетному мастеру возвращает состояние ОТКАЗ.

  • искал документы AWS. Единственное правильное решение, которое мы нашли, это https://aws.amazon.com/blogs/security/how-to-set-up-dns-resolution-between-on-premises-networks-and-aws-using-aws-directory-service-and-amazon-route-53/ Однако во франкфуртском регионе (с которым мы связаны правилами) нет простого AD. Полное объявление MS на AWS также будет работать, но мы не готовы платить 300 евро в месяц за пересылку DNS

  • Обратитесь в службу поддержки AWS. После недели долгих ожиданий они все еще не понимают проблему. Мы находимся на плане поддержки бизнеса.

Кто-нибудь может, пожалуйста, дать некоторые указания, как мы можем решить эту проблему с помощью нашей существующей AD?

Обновление. Маршрутизация другого домена на внутренний маршрут 53 AWS работает, просто игнорируя ошибку с условной пересылкой. Однако для поддоменов нам нужно создать делегирование, которое в свою очередь выдает SERVFAIL при запросе.

Обновление 2: это не представляется возможным. Также отказалась от технической поддержки AWS. Теперь мы зарегистрировали другое доменное имя для всех наших серверов и сервисов и использовали фиксированный DNS в нашей AD для настройки сервисов, которые используются не ИТ-отделом. с прокси в EC2, который переводит его в DNS-имена LB.

Источник

3 ответа

Если я правильно понял, у нас есть два ограничения:

  1. Зона dev.ourcompany.tld Route53 может быть разрешена только из VPC, а не через VPN, и
  2. Локальная AD хочет напрямую связаться с авторитетным сервером имен для dev.ourcompany.tld, а не с сервером пересылки.

С учетом этих ограничений мы должны разработать решение, которое 1) заставит AD думать, что он напрямую взаимодействует с Route53, и 2) заставит Route53 думать, что запросы DNS поступают с IP в VPC.

Один из возможных ответов - NAT - трансляция сетевых адресов, вот как я бы это сделал:

  1. Раскрутите небольшой экземпляр EC2 с помощью, например, Amazon Linux и отключите "Проверка источника / назначения" в настройках сети экземпляра. Может быть, дать ему фиксированный частный IP-адрес тоже. И разрешить входящий TCP и UDP-порт 53 в группе безопасности.

  2. Разрешить переадресацию IP в /etc/sysctl.conf установив net.ipv4.ip_forward=1

  3. Настройте iptables в экземпляре перенаправить весь входящий трафик через порт 53 в Route53, то есть в VPC-CIDR + 2. Что-то вроде:

    iptables -t nat -A PREROUTING -p tcp --dport 53 \
         -s <on-prem-cidr> -j DNAT --to <VPC-CIDR+2>

iptables -t nat -A PREROUTING -p udp --dport 53 \
         -s <on-prem-cidr> -j DNAT --to <VPC-CIDR+2>

  4. Укажите AD на частный IP этого экземпляра. DNS-трафик будет передаваться через NAT и перенаправляться на Route53, который будет думать, что он идет от VPC, и ответит на него. Также AD будет счастлив, потому что ответ придет непосредственно от авторитетного сервера имен.

Надеюсь, это поможет:)

Источник

У меня была такая же ситуация, хотя авторитетный сервер не был MS AD в нашей локальной сети. Чтобы решить эту проблему, я написал плагин для CoreDNS, который ведет себя как авторитетный сервер имен, используя Amazon VPC DNS в качестве бэкэнда. Это работает в нашей среде сейчас.

Источник

Вы можете сделать это следующим образом:

  1. На вашем официальном DNS-сервере для нашего company.tld создайте делегирование в dev.ourcompany.tld
  2. В полях NS укажите те же DNS-серверы, которые являются полномочными для ourcompany.tld - это разблокирует вас для настройки Conditional Forwarder на следующем шаге.
  3. Настройте Условный сервер пересылки для dev.ourcompany.tld и укажите его IP-адрес (а) "Экземпляр EC2 с сервером пересылки DNS" (как показано на вашем изображении)

Источник

Источник
Другие вопросы по тегам