Privat DNS verkar i VPC-en, men ikkje over VPN-en
Eit privat namn som blir løyst opp i EC2, men ikkje over VPN-en, er eit problem med resolverstien. Les feilforma før du redigerer soneposten.
Eit privat namn blir løyst opp frå ein EC2-forekomst, men ikkje frå ein berbar PC som er kopla til via VPN-en, og sona ser korrekt ut i konsollen. Impulsen er å redigere posten, noko som nesten aldri er problemet. Posten svarar nokon; han svarar berre ikkje den berbare PC-en din. Det som skil dei to kallarane, er kva resolver dei spør, og om den resolveren har ein støtta veg inn i DNS-visninga til VPC-en.
Eg byrjar med å prove at posten finst, og brukar resten av tida på spørjestien. Det er skilde system, og dei feilar på ulike måtar.
Les feilforma før du endrar noko
Tre utfall tyder tre ulike ting, og éi spørjing skil dei: køyr dig for namnet mot resolveren klienten faktisk brukar.
| 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 |
Ein tidsavbrot er ei utsegn om nettverket. NXDOMAIN er ei utsegn om DNS-visninga. Eit offentleg svar er ei utsegn om policyen. Den som redigerer ein sonepost medan det er tidsavbrot, kastar bort det einaste nyttige beviset i saka.
Kvifor pluss-to-adressa til VPC-en ikkje er ein ekstern resolver
CIDR-pluss-to-adressa er ei lokal teneste for ressursar inne i VPC-en. AWS dokumenterer at videresending av spørjingar frå lokale nettverk, eller frå DNS-tenarane til ein annan VPC, direkte til den adressa ikkje er støtta og kan gje ustabile resultat.
Det tyder ikkje at eit eksperiment aldri ser ut til å verke. Det tyder at åtferda ikkje er ein kontrakt du kan setje i eit helpdesk-skript. Den støtta retninga er eit innkomande Resolver-endepunkt: eit adressepar inne i VPC-en din, tilgjengeleg frå nettverket du kontrollerer, som tek imot spørjingar som kjem utanfrå AWS.
Bygg stien i den rekkjefølgja som feilar reint
Tre hopp må finnast, og kvart har sin eigen måte å feile på.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesVideresendaren treng ein rute til endepunktsadressene gjennom VPN-en, og returvegen må også verke. For konvensjonell DNS på port 53 svarar endepunktet over UDP og TCP, så begge protokollane må vere tillatne, og begge må overleve ein tilstandsbasert inspeksjon i midten.
Kontroller deretter DNS-visninga separat. Ei privat hosta sone er berre synleg for dei VPC-ane ho er knytt til, eller gjennom ei medviten delingsordning. Eit tilgjengeleg endepunkt gjer ikkje i seg sjølv kvar privat sone oppløyseleg i oppløysingskonteksten sin.
Eit utgåande endepunkt tener motsett retning og svarar ikkje på ei spørjing som kjem inn frå den berbare PC-en din.
Verifiser frå begge endar
Spør frå klienten mot videresendaren, deretter frå videresendaren mot endepunktet. Viss klienten feilar medan videresendaren lykkast, ligg gapet mellom dei to.
Viss begge feilar, sjå på sikkerheitspolicyen på endepunktet og på kjeldeadressa det faktisk ser. Ein videresendar bak NAT presenterer NAT-adressa i staden for VPN-adressa til den berbare PC-en, og den skilnaden åleine er nok til å sleppe spørjinga. Viss begge lykkast men applikasjonen framleis feilar, kan applikasjonen bruke ein annan resolver enn den du testa.
Hald dei offentlege og private namneromma skilde med vilje. Split DNS er ein policy du konfigurerer, ikkje ein bieffekt av at eitt oppslag tilfeldigvis returnerer data.
Kva eg ikkje ville gjort
Eg ville ikkje leggje til ein NAT-regel som fekk eitt oppslag til å verke, og kalle det ein design.
Eg ville ikkje peike alle eksterne klientar mot pluss-to-adressa fordi éin test ein gong returnerte ein post. Og eg ville ikkje utvide sikkerheitspolicyen til endepunktet til heile VPN-poolen når éin einaste videresendar treng tilgang. Køyrer organisasjonen allereie ein godkjend videresendar inne i VPC-en, les den designen først, for det andre endepunktet du legg til, er det ingen dokumenterer.