Privat DNS virker i VPC-en, men ikke over VPN-en
Et privat navn som løses opp i EC2, men ikke over VPN-en, er et problem med resolverstien. Les feilformen før du redigerer soneposten.
Et privat navn løses opp fra en EC2-forekomst, men ikke fra en bærbar PC som er koblet til via VPN-en, og sonen ser korrekt ut i konsollen. Impulsen er å redigere posten, noe som nesten aldri er problemet. Posten svarer noen; den svarer bare ikke den bærbare PC-en din. Det som skiller de to kallerne, er hvilken resolver de spør, og om den resolveren har en støttet vei inn i VPC-ens DNS-visning.
Jeg begynner med å bevise at posten finnes, og bruker resten av tiden på spørringsstien. Det er atskilte systemer, og de feiler på forskjellige måter.
Les feilformen før du endrer noe
Tre utfall betyr tre forskjellige ting, og én spørring skiller dem: kjør dig for navnet mot resolveren klienten faktisk bruker.
| 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 |
En tidsavbrudd er en uttalelse om nettverket. NXDOMAIN er en uttalelse om DNS-visningen. Et offentlig svar er en uttalelse om policyen. Den som redigerer en sonepost mens det er tidsavbrudd, kaster bort det eneste nyttige beviset i saken.
Hvorfor VPC-ens pluss-to-adresse ikke er en ekstern resolver
CIDR-pluss-to-adressen er en lokal tjeneste for ressurser inne i VPC-en. AWS dokumenterer at videresending av spørringer fra lokale nettverk, eller fra en annen VPCs DNS-servere, direkte til den adressen ikke støttes og kan gi ustabile resultater.
Det betyr ikke at et eksperiment aldri ser ut til å virke. Det betyr at atferden ikke er en kontrakt du kan sette i et helpdesk-skript. Den støttede retningen er et innkommende Resolver-endepunkt: et adressepar inne i VPC-en din, tilgjengelig fra nettverket du kontrollerer, som godtar spørringer som kommer utenfra AWS.
Bygg stien i den rekkefølgen som feiler rent
Tre hopp må finnes, og hvert har sin egen måte å feile på.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesVideresenderen trenger en rute til endepunktsadressene gjennom VPN-en, og returveien må også virke. For konvensjonell DNS på port 53 svarer endepunktet over UDP og TCP, så begge protokollene må være tillatt, og begge må overleve en tilstandsbasert inspeksjon i midten.
Kontroller deretter DNS-visningen separat. En privat hostet sone er bare synlig for VPC-ene den er knyttet til, eller gjennom en bevisst delingsordning. Et tilgjengelig endepunkt gjør ikke i seg selv enhver privat sone oppløselig i sin oppløsningskontekst.
Et utgående endepunkt tjener motsatt retning og svarer ikke på en spørring som kommer inn fra den bærbare PC-en din.
Verifiser fra begge ender
Spør fra klienten mot videresenderen, deretter fra videresenderen mot endepunktet. Hvis klienten feiler mens videresenderen lykkes, ligger gapet mellom de to.
Hvis begge feiler, se på sikkerhetspolicyen på endepunktet og på kildeadressen det faktisk ser. En videresender bak NAT presenterer NAT-adressen i stedet for den bærbare PC-ens VPN-adresse, og den forskjellen alene er nok til å droppe spørringen. Hvis begge lykkes men applikasjonen fortsatt feiler, kan applikasjonen bruke en annen resolver enn den du testet.
Hold de offentlige og private navnerommene atskilt med vilje. Split DNS er en policy du konfigurerer, ikke en bivirkning av at ett oppslag tilfeldigvis returnerer data.
Hva jeg ikke ville gjort
Jeg ville ikke legge til en NAT-regel som fikk ett oppslag til å virke, og kalle det en design.
Jeg ville ikke peke alle eksterne klienter mot pluss-to-adressen fordi én test en gang returnerte en post. Og jeg ville ikke utvide endepunktets sikkerhetspolicy til hele VPN-poolen når én enkelt videresender trenger tilgang. Kjører organisasjonen allerede en godkjent videresender inne i VPC-en, les den designen først, for det andre endepunktet du legger til, er det ingen dokumenterer.