O DNS privado funciona na VPC pero non a través da VPN
Un nome privado que resolve dentro de EC2 pero non a través da VPN é un problema de ruta do resolver. Le a forma do fallo antes de editar o rexistro da zona.
Un nome privado resolve desde unha instancia EC2 pero non desde un portátil conectado pola VPN, e a zona semella correcta na consola. O instinto é editar o rexistro, que case nunca é o problema. O rexistro responde a alguén; simplemente non responde ao teu portátil. O que cambia entre os dous clientes é que resolver consultan e se ese resolver ten unha ruta admitida cara á vista DNS da VPC.
Comezo demostrando que o rexistro existe e dedico o resto do tempo á ruta da consulta. Son sistemas separados e fallan de maneiras distintas.
Le a forma do fallo antes de cambiar nada
Tres resultados significan tres cousas distintas, e unha soa consulta distíngueos: executa dig para o nome contra o resolver que o cliente usa de verdade.
| 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 |
Un tempo de espera é unha afirmación sobre a rede. NXDOMAIN é unha afirmación sobre a vista DNS. Unha resposta pública é unha afirmación sobre a política. Editar un rexistro de zona mentres hai un tempo de espera tira á basura a única proba útil do caso.
Por que o enderezo máis dous da VPC non é un resolver remoto
O enderezo CIDR máis dous é un servizo local para os recursos dentro da VPC. AWS documenta que reenviar consultas desde redes locais, ou desde os servidores DNS doutra VPC, directamente a ese enderezo non está admitido e pode producir resultados inestables.
Iso non significa que un experimento nunca pareza funcionar. Significa que o comportamento non é un contrato que poidas pór nun guión de soporte. A dirección admitida é un endpoint de Resolver de entrada: un par de enderezos dentro da túa VPC, accesible desde a rede que controlas, que acepta consultas que chegan desde fóra de AWS.
Constrúe a ruta na orde en que falla limpiamente
Teñen que existir tres saltos, e cada un ten a súa propia forma de fallar.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesO reenviador precisa unha ruta cara aos enderezos do endpoint a través da VPN, e a ruta de volta tamén ten que funcionar. Para o DNS convencional no porto 53 o endpoint responde por UDP e TCP, así que hai que permitir ambos os protocolos e ambos teñen que sobrevivir a calquera inspección con estado polo medio.
Despois revisa a vista DNS por separado. Unha zona aloxada privada só é visible para as VPC coas que está asociada, ou mediante un acordo de compartición deliberado. Un endpoint accesible non fai por si só que todas as zonas privadas sexan resolubles no seu contexto de resolución.
Un endpoint de saída serve na dirección oposta e non responderá a unha consulta que chegue desde o teu portátil.
Verifica desde ambos os extremos
Consulta desde o cliente contra o reenviador e logo desde o reenviador contra o endpoint. Se o cliente falla mentres o reenviador acerta, a fenda está entre eses dous.
Se fallan ambos, mira a política de seguranza do endpoint e o enderezo de orixe que ve realmente. Un reenviador detrás de NAT presenta o enderezo NAT en lugar do enderezo VPN do portátil, e esa diferenza por si soa abonda para descartar a consulta. Se ambos acertan pero a aplicación segue fallando, pode que a aplicación use un resolver distinto do que probaches.
Mantén separados a propósito os espazos de nomes públicos e privados. O DNS dividido é unha política que configuras, non un efecto secundario de que unha consulta devolva datos por casualidade.
O que non faría
Non engadiría unha regra NAT que fixo funcionar unha soa consulta e chamaríalle deseño.
Non apuntaría todos os clientes remotos ao enderezo máis dous porque unha proba devolveu un rexistro unha vez. E non ampliaría a política de seguranza do endpoint a toda a pool de VPN cando un só reenviador precisa acceso. Se a organización xa executa un reenviador aprobado dentro da VPC, le ese deseño primeiro, porque o segundo endpoint que engadas é o que ninguén documenta.