O DNS privado funciona na VPC, mas não através da VPN
Um nome privado que resolve dentro do EC2 mas não através da VPN é um problema de caminho do resolver. Leia a forma da falha antes de editar o registo da zona.
Um nome privado resolve a partir de uma instância EC2 mas não a partir de um portátil ligado pela VPN, e a zona parece correta na consola. O instinto é editar o registo, que quase nunca é o problema. O registo responde a alguém; simplesmente não responde ao teu portátil. O que difere entre os dois clientes é que resolver consultam e se esse resolver tem um caminho suportado para a vista DNS da VPC.
Começo por provar que o registo existe e passo o resto do tempo no caminho da consulta. São sistemas separados e falham de formas diferentes.
Leia a forma da falha antes de alterar seja o que for
Três resultados significam três coisas diferentes, e uma só consulta distingue-os: executa dig para o nome contra o resolver que o cliente usa realmente.
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
Um tempo de espera é uma afirmação sobre a rede. NXDOMAIN é uma afirmação sobre a vista DNS. Uma resposta pública é uma afirmação sobre a política. Editar um registo de zona enquanto há um tempo de espera deita fora a única prova útil do caso.
Porque o endereço mais dois da VPC não é um resolver remoto
O endereço CIDR mais dois é um serviço local para recursos dentro da VPC. A AWS documenta que encaminhar consultas de redes locais, ou dos servidores DNS de outra VPC, diretamente para esse endereço não é suportado e pode produzir resultados instáveis.
Isso não significa que uma experiência nunca pareça funcionar. Significa que o comportamento não é um contrato que possas pôr num script de apoio. A direção suportada é um endpoint de Resolver de entrada: um par de endereços dentro da tua VPC, alcançável a partir da rede que controlas, que aceita consultas vindas de fora da AWS.
Constrói o caminho na ordem em que falha de forma limpa
Têm de existir três saltos, e cada um tem o seu próprio modo de falha.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesO encaminhador precisa de uma rota para os endereços do endpoint através da VPN, e o caminho de retorno também tem de funcionar. Para DNS convencional na porta 53 o endpoint responde por UDP e TCP, por isso ambos os protocolos têm de ser permitidos e ambos têm de sobreviver a qualquer inspeção com estado pelo meio.
Depois verifica a vista DNS em separado. Uma zona alojada privada só é visível para as VPC com que está associada, ou através de um acordo de partilha deliberado. Um endpoint alcançável não torna, por si só, todas as zonas privadas resolúveis no seu contexto de resolução.
Um endpoint de saída serve a direção oposta e não responderá a uma consulta vinda do teu portátil.
Verifica a partir de ambos os extremos
Consulta do cliente contra o encaminhador e depois do encaminhador contra o endpoint. Se o cliente falha enquanto o encaminhador acerta, a lacuna está entre esses dois.
Se ambos falharem, olha para a política de segurança do endpoint e para o endereço de origem que ele vê de facto. Um encaminhador atrás de NAT apresenta o endereço NAT em vez do endereço VPN do portátil, e só essa diferença basta para descartar a consulta. Se ambos acertarem mas a aplicação continuar a falhar, a aplicação pode estar a usar um resolver diferente do que testaste.
Mantém separados de propósito os espaços de nomes públicos e privados. O DNS dividido é uma política que configuras, não um efeito secundário de uma consulta devolver dados por acaso.
O que eu não faria
Não acrescentaria uma regra NAT que fez uma única consulta funcionar e chamaria a isso um desenho.
Não apontaria todos os clientes remotos para o endereço mais dois porque um teste devolveu um registo uma vez. E não alargaria a política de segurança do endpoint a toda a pool de VPN quando um único encaminhador precisa de acesso. Se a organização já executa um encaminhador aprovado dentro da VPC, lê esse desenho primeiro, porque o segundo endpoint que acrescentares é o que ninguém documenta.