Privé-DNS werkt in de VPC, maar niet via de VPN

Een privénaam resolvet vanaf een EC2-instantie, maar niet vanaf een laptop die via de VPN is verbonden, en de zone ziet er in de console correct uit. De reflex is om de record aan te passen, wat bijna nooit het probleem is. De record antwoordt iemand; hij antwoordt alleen niet je laptop. Wat verschilt tussen de twee vragers is welke resolver ze vragen, en of die resolver een ondersteund pad heeft naar de DNS-weergave van de VPC.

Ik begin met te bewijzen dat de record bestaat, en besteed de rest van de tijd aan het querypad. Dat zijn gescheiden systemen, en ze falen op verschillende manieren.

Lees de faalvorm voordat je iets verandert

Drie uitkomsten betekenen drie verschillende dingen, en één query onderscheidt ze: voer dig uit voor de naam tegen de resolver die de client werkelijk gebruikt.

Een time-out is een uitspraak over het netwerk. NXDOMAIN is een uitspraak over de DNS-weergave. Een openbaar antwoord is een uitspraak over het beleid. Wie een zonerecord aanpast terwijl er een time-out is, gooit het enige bruikbare bewijs in de zaak weg.

Waarom het plus-twee-adres van de VPC geen externe resolver is

Het CIDR-plus-twee-adres is een lokale dienst voor resources binnen de VPC. AWS documenteert dat het doorsturen van queries uit on-premises netwerken, of van de DNS-servers van een andere VPC, rechtstreeks naar dat adres niet wordt ondersteund en onstabiele resultaten kan geven.

Dat betekent niet dat een experiment nooit lijkt te werken. Het betekent dat het gedrag geen contract is dat je in een helpdeskscript kunt zetten. De ondersteunde richting is een inkomend Resolver-endpoint: een adrespaar binnen je VPC, bereikbaar vanaf het netwerk dat je beheert, dat queries accepteert die van buiten AWS komen.

Bouw het pad in de volgorde waarin het schoon faalt

Er moeten drie hops bestaan, en elk heeft zijn eigen manier van falen.

VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addresses

De forwarder heeft een route nodig naar de endpointadressen via de VPN, en ook het retourpad moet werken. Voor conventionele DNS op poort 53 antwoordt het endpoint via UDP en TCP, dus beide protocollen moeten zijn toegestaan en beide moeten een stateful inspectie in het midden doorstaan.

Controleer daarna de DNS-weergave apart. Een private hosted zone is alleen zichtbaar voor de VPC's waarmee hij is gekoppeld, of via een bewuste deelregeling. Een bereikbaar endpoint maakt op zichzelf niet elke private zone oplosbaar in zijn resolutiecontext.

Een uitgaand endpoint dient de tegenovergestelde richting en beantwoordt geen query die van je laptop binnenkomt.

Controleer vanaf beide kanten

Query vanaf de client tegen de forwarder, en daarna vanaf de forwarder tegen het endpoint. Faalt de client terwijl de forwarder slaagt, dan zit de kloof tussen die twee.

Falen beide, kijk dan naar het beveiligingsbeleid op het endpoint en naar het bronadres dat het werkelijk ziet. Een forwarder achter NAT presenteert het NAT-adres in plaats van het VPN-adres van de laptop, en dat verschil alleen is genoeg om de query te laten vallen. Slagen beide, maar faalt de toepassing nog steeds, dan gebruikt de toepassing mogelijk een andere resolver dan degene die je hebt getest.

Houd de openbare en private namespaces bewust gescheiden. Split DNS is beleid dat je configureert, geen bijeffect van één lookup die toevallig gegevens teruggeeft.

Wat ik niet zou doen

Ik zou geen NAT-regel toevoegen die één lookup liet werken en dat een ontwerp noemen.

Ik zou niet elke externe client naar het plus-twee-adres wijzen omdat één test ooit een record teruggaf. En ik zou het beveiligingsbeleid van het endpoint niet verbreden naar de hele VPN-pool wanneer één forwarder toegang nodig heeft. Draait de organisatie al een goedgekeurde forwarder binnen de VPC, lees dat ontwerp eerst, want het tweede endpoint dat je toevoegt is degene die niemand documenteert.