Expor rota interna53 DNS sobre VPN para ActiveDirectory no local

Question

A situação

Estamos migrando nossos aplicativos da web para a AWS. Para conectar nossa rede local e a AWS, criamos uma conexão VPN. Isso funciona sem problemas.

No local, temos um MS AD (2008 R2) que é um servidor autoritativo para (entre outros) nossaempresa.tld (nome de domínio não real;))

Na AWS, queremos que todos os serviços internos sejam nomeados como: * .dev.ourcompany.tld. Esse DNS deve ser resolvido pela rota interna53.

No AWS, os recursos públicos são denominados *. ourcompany.tld. Este DNS é resolvido pelos nossos próprios servidores de nomes. (trabalhando)

O problema

Na nossa rede local, queremos ser capazes de resolver someserver.dev.saa.nl. Para conseguir isso, nosso MS ActiveDirectory precisa ser avisado para fazer uma pesquisa na AWS para este nome de domínio.

A rota interna da AWS53 é acessível somente a partir do AWS VPC. A AD não pode alcançar isso diretamente.

A rota interna da AWS53 é acessível somente por meio de um encaminhador de DNS da VPC que não seja autoritativo.

O MS AD requer uma fonte autorizada para zonas de stub e encaminhadores condicionais.

O que fizemos / tentamos

• Crie um encaminhador de DNS no VPC . Este encaminhador não é autoritativo. Funciona bem quando você configura o encaminhador de DNS como DNS primário no próprio computador. O ActiveDirectory não nos permite criar uma zona de stub ou encaminhador condicional com a mensagem de que o servidor não é autoritativo.
• Crie um servidor DNS com uma zona de stub para dev.ourcompany.tld no amazon VPC . Ao criar uma zona de stub, ela será reportada como sendo autoritativa, no entanto, como só podemos resolver o DNS sobre o encaminhador VPC DNS (no VPC IP + 2), ela se recusa a criar o stub, pois sua origem não é autoritativa. Conexão direta com o mestre autoritativo retorna o estado RECUSADO.

• pesquisou documentos da AWS . A única solução adequada que encontramos é link No entanto, a região de frankfurt (à qual estamos sujeitos por regulamentos) não possui AD simples. Um MS AD completo na AWS também funcionará, mas não estamos preparados para pagar € 300 + por mês por um forwarder de DNS

• Entre em contato com o suporte da AWS . Após uma semana de longas esperas eles ainda não parecem entender o problema. Estamos no plano de suporte de negócios.

Alguém pode, por favor, dar algumas orientações sobre como podemos resolver isso usando nosso AD existente?

Atualização: Rotear outro domínio para a rota interna da AWS 53 simplesmente ignora o erro com um encaminhamento condicional. No entanto, para um subdomínio, precisaríamos fazer uma delegação que, por sua vez, gera um SERVFAIL quando consultada.

Atualização 2: Não parece ser possível. O suporte técnico da AWS também desistiu. Registramos agora outro nome de domínio para todos os nossos servidores e serviços e usamos um DNS fixo em nosso AD para configurar os serviços usados por outras pessoas que não o departamento de TI. com um proxy no EC2 que o traduz para os nomes DNS LB.

    

Answer 1

Se eu acertar, temos duas restrições:

1. A zona dev.ourcompany.tld Route53 só pode ser resolvida a partir do VPC e não através da VPN e
2. O AD no local deseja falar diretamente com o servidor de nomes autoritativo para dev.ourcompany.tld e não com um encaminhador.

Com essas limitações, precisamos projetar uma solução que: 1) faça o AD pensar que ele converse diretamente com o Route53 e 2) faça o Route53 pensar que as solicitações de DNS estão vindo de um IP no VPC.

Uma resposta possível é NAT - Tradução de endereços de rede , é assim que eu faria:

1. Aumente uma pequena instância do EC2 com, por exemplo, Amazon Linux e Desativar "Verificação de Origem / Destino" nas configurações de Rede da instância. Talvez dê um endereço IP privado fixo também. E permitir entrada TCP e UDP porta 53 no grupo de segurança.

2. Permitir o encaminhamento de IP em /etc/sysctl.conf definindo net.ipv4.ip_forward=1

3. Configure o iptables na instância para redirecionar todo o tráfego de entrada na porta 53 para o Route53, ou seja, para VPC-CIDR + 2 . Algo como:

   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. Aponte AD para o IP privado desta instância. O tráfego de DNS será NAT'ed e encaminhado para Route53, que vai pensar que é proveniente da VPC e irá respondê-lo. Além disso, o AD ficará feliz porque a resposta virá diretamente do servidor de nomes oficial.

Espero que ajude:)

    

Answer 2

Eu tive a mesma situação, embora um servidor autoritativo não fosse o MS AD no nosso local. Para resolver o problema, eu escrevi um plugin para o CoreDNS que se comporta como um servidor de nomes autoritativo usando o DNS do Amazon VPC como backend. Funciona no nosso ambiente agora.