Privat DNS virker i VPC'en, men ikke over VPN'en
Et privat navn, der slår op i EC2 men ikke over VPN'en, er et problem med resolverstien. Læs fejlformen, før du redigerer zoneposten.
Et privat navn slår op fra en EC2-instans, men ikke fra en laptop, der er forbundet via VPN'en, og zonen ser korrekt ud i konsollen. Impulsen er at redigere posten, hvilket næsten aldrig er problemet. Posten svarer nogen; den svarer blot ikke din laptop. Det, der adskiller de to kaldere, er hvilken resolver de spørger, og om den resolver har en understøttet vej ind i VPC'ens DNS-visning.
Jeg starter med at bevise, at posten findes, og bruger resten af tiden på forespørgselsstien. Det er adskilte systemer, og de fejler på forskellige måder.
Læs fejlformen, før du ændrer noget
Tre udfald betyder tre forskellige ting, og én forespørgsel skelner dem: kør dig for navnet mod den resolver, klienten faktisk bruger.
| 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 timeout er en udtalelse om netværket. NXDOMAIN er en udtalelse om DNS-visningen. Et offentligt svar er en udtalelse om politikken. Den, der redigerer en zonepost, mens der er timeout, smider sagens eneste brugbare bevis væk.
Hvorfor VPC'ens plus-to-adresse ikke er en ekstern resolver
CIDR-plus-to-adressen er en lokal tjeneste for ressourcer inde i VPC'en. AWS dokumenterer, at videresendelse af forespørgsler fra lokale netværk eller fra en anden VPC's DNS-servere direkte til den adresse ikke understøttes og kan give ustabile resultater.
Det betyder ikke, at et eksperiment aldrig ser ud til at virke. Det betyder, at adfærden ikke er en kontrakt, man kan sætte i et helpdesk-script. Den understøttede retning er et indgående Resolver-endpoint: et adressepar inde i din VPC, tilgængeligt fra det netværk, du styrer, som accepterer forespørgsler, der kommer udefra AWS.
Byg stien i den rækkefølge, der fejler rent
Der skal findes tre hop, og hvert har sin egen fejlmåde.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesVideresenderen skal have en rute til endpoint-adresserne gennem VPN'en, og returvejen skal også virke. Til konventionel DNS på port 53 svarer endpointet over UDP og TCP, så begge protokoller skal være tilladte, og begge skal overleve en tilstandsfuld inspektion i midten.
Kontroller derefter DNS-visningen separat. En privat hostet zone er kun synlig for de VPC'er, den er knyttet til, eller gennem en bevidst delingsordning. Et tilgængeligt endpoint gør ikke i sig selv enhver privat zone opløselig i sin opløsningskontekst.
Et udgående endpoint tjener den modsatte retning og besvarer ikke en forespørgsel, der kommer ind fra din laptop.
Kontroller fra begge ender
Forespørg fra klienten mod videresenderen, derefter fra videresenderen mod endpointet. Hvis klienten fejler, mens videresenderen lykkes, ligger kløften mellem de to.
Fejler begge, se på sikkerhedspolitikken på endpointet og på kildeadressen, den faktisk ser. En videresender bag NAT præsenterer NAT-adressen i stedet for laptopens VPN-adresse, og den forskel alene er nok til at droppe forespørgslen. Lykkes begge, men applikationen fejler stadig, bruger applikationen måske en anden resolver end den, du testede.
Hold de offentlige og private navnerum adskilt med vilje. Split DNS er en politik, du konfigurerer, ikke en bivirkning af, at ét opslag tilfældigt returnerer data.
Hvad jeg ikke ville gøre
Jeg ville ikke tilføje en NAT-regel, der fik ét opslag til at virke, og kalde det et design.
Jeg ville ikke pege alle eksterne klienter mod plus-to-adressen, fordi én test en gang returnerede en post. Og jeg ville ikke udvide endpointets sikkerhedspolitik til hele VPN-puljen, når én enkelt videresender har brug for adgang. Kører organisationen allerede en godkendt videresender inde i VPC'en, så læs det design først, for det andet endpoint, du tilføjer, er det, ingen dokumenterer.