El DNS privat funciona a la VPC però no a través de la VPN
Un nom privat que resol dins d'EC2 però no a través de la VPN és un problema de camí del resolver. Llegeix la forma del fall abans d'editar el registre de la zona.
Un nom privat resol des d'una instància EC2 però no des d'un portàtil connectat per la VPN, i la zona es veu correcta a la consola. L'instint és editar el registre, que gairebé mai no és el problema. El registre respon a algú; simplement no respon al teu portàtil. El que canvia entre els dos clients és quin resolver consulten i si aquest resolver té un camí admès cap a la vista DNS de la VPC.
Començo demostrant que el registre existeix i dedico la resta del temps al camí de la consulta. Són sistemes separats i fallen de maneres diferents.
Llegeix la forma del fall abans de canviar res
Tres resultats signifiquen tres coses diferents, i una sola consulta els distingeix: executa dig per al nom contra el resolver que el client fa servir realment.
| 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 temps d'espera és una afirmació sobre la xarxa. NXDOMAIN és una afirmació sobre la vista DNS. Una resposta pública és una afirmació sobre la política. Editar un registre de zona mentre hi ha un temps d'espera llença a les escombraries l'única prova útil del cas.
Per què l'adreça més dos de la VPC no és un resolver remot
L'adreça CIDR més dos és un servei local per als recursos dins de la VPC. AWS documenta que reenviar consultes des de xarxes locals, o des dels servidors DNS d'una altra VPC, directament a aquesta adreça no està admès i pot produir resultats inestables.
Això no vol dir que un experiment no arribi mai a semblar que funciona. Vol dir que el comportament no és un contracte que puguis posar en un guió de suport. La direcció admesa és un endpoint de Resolver d'entrada: un parell d'adreces dins de la teva VPC, accessible des de la xarxa que controles, que accepta consultes que arriben de fora d'AWS.
Construeix el camí en l'ordre en què falla netament
Hi han d'existir tres salts, i cadascun té la seva pròpia manera de fallar.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesEl reenviador necessita una ruta cap a les adreces de l'endpoint a través de la VPN, i la ruta de tornada també ha de funcionar. Per al DNS convencional al port 53 l'endpoint respon per UDP i TCP, així que cal permetre tots dos protocols i tots dos han de sobreviure a qualsevol inspecció amb estat pel mig.
Després revisa la vista DNS per separat. Una zona allotjada privada només és visible per a les VPC amb què està associada, o mitjançant un acord de compartició deliberat. Un endpoint accessible no fa per si sol que totes les zones privades siguin resolubles en el seu context de resolució.
Un endpoint de sortida serveix en la direcció oposada i no respondrà una consulta que arribi des del teu portàtil.
Verifica des de tots dos extrems
Consulta des del client contra el reenviador i després des del reenviador contra l'endpoint. Si el client falla mentre el reenviador encerta, la bretxa és entre aquests dos.
Si fallen tots dos, mira la política de seguretat de l'endpoint i l'adreça d'origen que ve realment. Un reenviador darrere de NAT presenta l'adreça NAT en lloc de l'adreça VPN del portàtil, i aquesta diferència per si sola prou per descartar la consulta. Si tots dos encerten però l'aplicació continua fallant, potser l'aplicació fa servir un resolver diferent del que vas provar.
Mantén separats a propòsit els espais de noms públics i privats. El DNS dividit és una política que configures, no un efecte secundari que una consulta retorni dades per casualitat.
Què no faria
No afegiria una regla NAT que va fer funcionar una sola consulta i ho anomenaria disseny.
No apuntaria tots els clients remots a l'adreça més dos perquè una prova va retornar un registre una vegada. I no eixamplaria la política de seguretat de l'endpoint a tota la pool de VPN quan un sol reenviador necessita accés. Si l'organització ja executa un reenviador aprovat dins de la VPC, llegeix aquell disseny primer, perquè el segon endpoint que afegeixis és el que ningú no documenta.