Il DNS privato funziona nella VPC ma non attraverso la VPN
Un nome privato che si risolve dentro EC2 ma non attraverso la VPN è un problema di percorso del resolver. Leggi la forma del guasto prima di modificare il record della zona.
Un nome privato si risolve da un'istanza EC2 ma non da un portatile collegato tramite la VPN, e la zona sembra corretta nella console. L'istinto è modificare il record, che quasi mai è il problema. Il record risponde a qualcuno; semplicemente non risponde al tuo portatile. Ciò che cambia tra i due chiamanti è quale resolver interrogano e se quel resolver ha un percorso supportato verso la vista DNS della VPC.
Comincio dimostrando che il record esiste e passo il resto del tempo sul percorso della query. Sono sistemi separati e falliscono in modi diversi.
Leggi la forma del guasto prima di cambiare qualcosa
Tre esiti significano tre cose diverse, e una sola query li distingue: esegui dig per il nome contro il resolver che il client sta davvero usando.
| 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 timeout è un'affermazione sulla rete. NXDOMAIN è un'affermazione sulla vista DNS. Una risposta pubblica è un'affermazione sulla policy. Modificare un record di zona mentre c'è un timeout butta via l'unica prova utile del caso.
Perché l'indirizzo più due della VPC non è un resolver remoto
L'indirizzo CIDR più due è un servizio locale per le risorse dentro la VPC. AWS documenta che inoltrare query da reti locali, o dai server DNS di un'altra VPC, direttamente a quell'indirizzo non è supportato e può produrre risultati instabili.
Ciò non significa che un esperimento non sembri mai funzionare. Significa che il comportamento non è un contratto che puoi mettere in uno script di assistenza. La direzione supportata è un endpoint Resolver in ingresso: una coppia di indirizzi dentro la tua VPC, raggiungibile dalla rete che controlli, che accetta query in arrivo da fuori AWS.
Costruisci il percorso nell'ordine in cui fallisce in modo pulito
Devono esistere tre salti, e ognuno ha il proprio modo di fallire.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesIl forwarder ha bisogno di una rotta verso gli indirizzi dell'endpoint attraverso la VPN, e anche il percorso di ritorno deve funzionare. Per il DNS convenzionale sulla porta 53 l'endpoint risponde su UDP e TCP, quindi entrambi i protocolli devono essere consentiti ed entrambi devono sopravvivere a qualsiasi ispezione con stato nel mezzo.
Poi controlla la vista DNS separatamente. Una zona ospitata privata è visibile solo alle VPC con cui è associata, o tramite un accordo di condivisione deliberato. Un endpoint raggiungibile non rende di per sé risolvibile ogni zona privata nel suo contesto di risoluzione.
Un endpoint in uscita serve la direzione opposta e non risponderà a una query in arrivo dal tuo portatile.
Verifica da entrambe le estremità
Interroga dal client verso il forwarder, poi dal forwarder verso l'endpoint. Se il client fallisce mentre il forwarder riesce, il divario è tra quei due.
Se falliscono entrambi, guarda la policy di sicurezza sull'endpoint e l'indirizzo di origine che vede davvero. Un forwarder dietro NAT presenta l'indirizzo NAT invece dell'indirizzo VPN del portatile, e quella differenza da sola basta a scartare la query. Se entrambi riescono ma l'applicazione continua a fallire, l'applicazione potrebbe usare un resolver diverso da quello che hai testato.
Tieni separati di proposito gli spazi dei nomi pubblici e privati. Lo split DNS è una policy che configuri, non un effetto collaterale di una singola interrogazione che per caso restituisce dati.
Cosa non farei
Non aggiungerei una regola NAT che ha fatto funzionare una singola interrogazione e la chiamerei progetto.
Non punterei tutti i client remoti all'indirizzo più due perché un test una volta ha restituito un record. E non allargherei la policy di sicurezza dell'endpoint all'intero pool VPN quando un solo forwarder ha bisogno di accesso. Se l'organizzazione esegue già un forwarder approvato dentro la VPC, leggi prima quel progetto, perché il secondo endpoint che aggiungi è quello che nessuno documenta.