DNS bij AWS Client VPN: gebruik de VPC-resolver, niet het subnet

Het endpoint staat in 10.0.8.0/24, dus de resolver moet 10.0.8.2 zijn. Dat is de redenering die ik het vaakst hoor, en hij is twee keer fout. Route 53 Resolver antwoordt op het primaire IPv4-bereik van de VPC plus twee, wat voor een VPC van 10.0.0.0/16 10.0.0.2 is, ongeacht welk subnet het endpoint gebruikt. De tweede fout is stiller: het juiste adres in het endpoint zetten betekent niet dat het besturingssysteem van de client er ooit iets aan vraagt. Beide fouten geven hetzelfde symptoom: naamresolutie werkt voor sommige clients en faalt voor andere.

De mythe begint bij de subnet-koppeling

Koppeling gaat over waar de elastische netwerkinterfaces voor clientverbindingen leven, niet over welk resolveradres bestaat. De subnetten van het endpoint geven clients een adres binnen de VPC, en ze dragen niet elk hun eigen resolver.

Zodra je die twee ideeën scheidt, is de rekenkunde niet langer mysterieus en verhuist het probleem oplossen naar de client, waar de meeste van deze gevallen echt eindigen.

Bereken het adres uit het primaire VPC-bereik

Neem de primaire IPv4-CIDR van de VPC en tel twee op bij het netwerkadres. 10.0.0.0/16 geeft 10.0.0.2, 172.31.0.0/16 geeft 172.31.0.2, en een VPC met een secundair bereik houdt de resolver op het primaire. Een subnet van 10.0.8.0/24 binnen die VPC verschuift hem niet. Schrijf het adres naast de VPC-ID voordat je het endpoint aanraakt, want het getal is een eigenschap van de VPC en niet van de verbinding.

De VPC antwoordt ook op het link-local adres 169.254.169.253. Dat adres is bereikbaar van binnen de VPC, maar het is geen algemeen gerouteerde bestemming voor een laptop aan de andere kant van een tunnel.

Er zijn dus twee geldige resolveradressen, en geen van beide is het subnet plus twee.

Wat de endpoint-instelling doet en wat niet

Het Client VPN-endpoint heeft DNS-servervelden, en waar de console een VPC-resolver-optie biedt, vult die hetzelfde idee in. Ze instellen verandert wat de dienst aan clients geeft tijdens het opzetten van de verbinding. Het verandert niet wat een niet-beheerde OpenVPN-client met die waarde doet, want de client moet hem nog steeds op het besturingssysteem toepassen. Uit die kloof komt «het werkt op mijn Mac maar niet op de Linux-doos».

Op Linux is de resolverintegratie eigendom van de verbindingsbeheerder en niet van de gebruiker. /etc/resolv.conf met de hand bewerken bewijst dat het adres voor één sessie werkt en daarna verdwijnt bij opnieuw verbinden — daarom komen zoveel opgeloste gevallen de volgende ochtend terug.

Controleer de actieve resolver op de client na het verbinden, niet de configuratiepagina van het endpoint.

Split tunneling kan een correcte resolver verslaan

Met split tunneling worden alleen routes gebruikt die de tunnel in worden geduwd. Als het resolveradres niet door een route wordt gedekt, verlaat de query de lokale interface en antwoordt je thuisrouter. Het adres in het endpoint is nog steeds correct en de opzoeking faalt nog steeds. Voeg de route voor de resolver toe en test opnieuw.

Overlappende lokale bereiken geven hetzelfde resultaat op een vervelender manier: de query wordt beantwoord, maar door de verkeerde server.

Open geen security groups voor het Amazon DNS-adres

Het instinct bij time-outs is een regel toevoegen die UDP 53 naar het resolveradres toestaat. AWS documenteert dat security groups en netwerk-ACL’s Amazon DNS-verkeer niet filteren zoals ze verkeer naar een eigen DNS-instantie filteren. Die regels openen verandert niets voor de VPC-resolver en verbreedt de grens zonder reden. Een resolver die je zelf draait is een ander geval en heeft wel zijn eigen regels nodig.

Als beide in je ontwerp voorkomen, controleer dan waar de client echt naar wijst voordat je een regel aanpast.

Controleer het pad en meet dan iets anders

Los een openbare naam op, los een privénaam op die is geregistreerd in een private hosted zone die aan de VPC is gekoppeld, en lees daartussen de actieve resolver van de client. Die volgorde scheidt «het resolveradres is fout» van «de zone is niet gekoppeld» en van «de client heeft de instelling genegeerd». Elk heeft een andere oplossing, en geen ervan is een doorvoerprobleem.

Een geslaagde opzoeking zegt niets over duurzame overdrachtssnelheid, dus houd die twee gesprekken gescheiden wanneer je rapporteert.