AWS Client VPN-DNS: brug VPC-resolveren, ikke undernettet
Resolveren for et AWS Client VPN-endpoint er VPC’ens primære område plus to, ikke hvert undernet plus to. Indstil den, rut den, og kontrollér derefter klienten.
Endpointet ligger i 10.0.8.0/24, så resolveren skal være 10.0.8.2. Det er den ræsonnering, jeg hører oftest, og den er forkert to gange. Route 53 Resolver svarer på VPC’ens primære IPv4-område plus to, som for en VPC på 10.0.0.0/16 er 10.0.0.2, uanset hvilket undernet endpointet bruger. Den anden fejl er mere stille: at sætte den rigtige adresse i endpointet betyder ikke, at klientens styresystem nogensinde spørger den om noget. Begge fejl giver samme symptom: navneopløsning virker for nogle klienter og fejler for andre.
Myten starter ved undernetsassocieringen
Associering handler om, hvor de elastiske netværksgrænseflader til klientforbindelser bor, ikke om hvilken resolveradresse der findes. Endpointets undernet giver klienterne en adresse inde i VPC’en, og de bærer ikke hver deres resolver.
Når du skiller de to idéer, holder aritmetikken op med at være mystisk, og fejlfindingen flytter til klienten, hvor de fleste af disse sager faktisk ender.
Beregn adressen ud fra VPC’ens primære område
Tag VPC’ens primære IPv4-CIDR og læg to til netværksadressen. 10.0.0.0/16 giver 10.0.0.2, 172.31.0.0/16 giver 172.31.0.2, og en VPC med et sekundært område beholder resolveren på det primære. Et undernet på 10.0.8.0/24 inde i den VPC flytter den ikke. Skriv adressen ved siden af VPC-ID’et, før du rører endpointet, fordi tallet er en egenskab ved VPC’en og ikke ved forbindelsen.
VPC’en svarer også på link-local-adressen 169.254.169.253. Den adresse er nåbar indefra VPC’en, men den er ikke en almindelig routet destination for en bærbar computer i den anden ende af en tunnel.
Der er altså to gyldige resolveradresser, og ingen af dem er undernettet plus to.
Hvad endpoint-indstillingen gør, og hvad den ikke gør
Client VPN-endpointet har DNS-serverfelter, og hvor konsollen tilbyder en VPC-resolver-mulighed, udfylder den samme idé. At sætte dem ændrer, hvad tjenesten giver klienterne under opkoblingen. Det ændrer ikke, hvad en ikke-administreret OpenVPN-klient gør med værdien, fordi klienten stadig skal anvende den på styresystemet. Det gab er, hvor «det virker på min Mac, men ikke på Linux-maskinen» kommer fra.
På Linux ejes resolverintegrationen af forbindelsesadministratoren snarere end af brugeren. Hvis du redigerer /etc/resolv.conf i hånden, beviser det, at adressen virker for én session, og så forsvinder den ved genopkobling — derfor kommer så mange rettede sager igen næste morgen.
Kontrollér den aktive resolver på klienten efter opkobling, ikke endpointets konfigurationsside.
Split tunneling kan slå en korrekt resolver ud
Med split tunneling bruges kun ruter, der skubbes ind i tunnelen. Hvis resolveradressen ikke er dækket af en rute, forlader forespørgslen det lokale interface og besvares af din hjemmerouter. Adressen i endpointet er stadig korrekt, og opslaget fejler stadig. Tilføj ruten for resolveren, og test igen.
Overlappende lokale områder giver samme resultat på en mere generende måde: forespørgslen besvares, bare af den forkerte server.
Åbn ikke sikkerhedsgrupper for Amazon DNS-adressen
Instinktet, når opslag timer ud, er at tilføje en regel, der tillader UDP 53 til resolveradressen. AWS dokumenterer, at sikkerhedsgrupper og netværks-ACL’er ikke filtrerer Amazon DNS-trafik, som de filtrerer trafik til en egen DNS-instans. At åbne de regler ændrer intet for VPC-resolveren og udvider grænsen uden grund. En resolver, du selv driver, er en anden sag og har faktisk brug for sine egne regler.
Hvis begge optræder i dit design, så kontrollér, hvilken klienten faktisk peger på, før du redigerer nogen regel.
Verificér ruten, og mål så noget andet
Slå et offentligt navn op, slå et privat navn op, der er registreret i en privat hostet zone knyttet til VPC’en, og læs klientens aktive resolver mellem de to. Den rækkefølge adskiller «resolveradressen er forkert» fra «zonen er ikke associeret» fra «klienten ignorerede indstillingen». Hver har sin egen rettelse, og ingen af dem er et gennemstrømningsproblem.
Et vellykket opslag siger intet om vedvarende overførselshastighed, så hold de to samtaler adskilt, når du rapporterer tilbage.