AWS Client VPN og DNS: bruk VPC-resolveren, ikke subnettet

Endepunktet ligger i 10.0.8.0/24, så resolveren må være 10.0.8.2. Det er resonnementet jeg hører oftest, og det er feil to ganger. Route 53 Resolver svarer på VPC-ens primære IPv4-område pluss to, som for en VPC på 10.0.0.0/16 er 10.0.0.2, uansett hvilket subnett endepunktet bruker. Den andre feilen er stillere: å sette riktig adresse i endepunktet betyr ikke at klientens operativsystem noen gang spør det om noe. Begge feilene gir samme symptom: navneoppslag virker for noen klienter og feiler for andre.

Myten starter ved subnett-tilknytningen

Tilknytningen handler om hvor de elastiske nettverksgrensesnittene for klienttilkoblinger bor, ikke om hvilken resolveradresse som finnes. Endepunktets subnett gir klientene en adresse inne i VPC-en, og de bærer ikke hver sin resolver.

Når du skiller de to ideene, slutter aritmetikken å være mystisk, og feilsøkingen flytter til klienten, der de fleste av disse sakene faktisk ender.

Regn ut adressen fra VPC-ens primære område

Ta VPC-ens primære IPv4-CIDR og legg til to på nettverksadressen. 10.0.0.0/16 gir 10.0.0.2, 172.31.0.0/16 gir 172.31.0.2, og en VPC med et sekundært område beholder resolveren på det primære. Et subnett på 10.0.8.0/24 inne i den VPC-en flytter den ikke. Skriv adressen ved siden av VPC-ID-en før du rører endepunktet, fordi tallet er en egenskap ved VPC-en og ikke ved tilkoblingen.

VPC-en svarer også på link-local-adressen 169.254.169.253. Den adressen er nåbar innenfra VPC-en, men den er ikke et vanlig rutet mål for en bærbar PC i den andre enden av en tunnel.

Så det finnes to gyldige resolveradresser, og ingen av dem er subnettet pluss to.

Hva endepunktinnstillingen gjør og ikke gjør

Client VPN-endepunktet har DNS-serverfelt, og der konsollen tilbyr et VPC-resolver-alternativ fyller den inn samme idé. Å sette dem endrer hva tjenesten gir klientene under oppkoblingen. Det endrer ikke hva en ikke-administrert OpenVPN-klient gjør med verdien, fordi klienten fortsatt må bruke den på operativsystemet. Det gapet er der «det virker på Macen min, men ikke på Linux-boksen» kommer fra.

På Linux eies resolverintegrasjonen av tilkoblingsbehandleren og ikke av brukeren. Å redigere /etc/resolv.conf for hånd beviser at adressen virker for én økt, og så forsvinner den ved gjenoppkobling — derfor kommer så mange fiksede saker tilbake neste morgen.

Sjekk den aktive resolveren på klienten etter tilkobling, ikke endepunktets konfigurasjonsside.

Split tunneling kan slå ut en korrekt resolver

Med split tunneling brukes bare ruter som dyttes inn i tunnelen. Hvis resolveradressen ikke dekkes av en rute, forlater spørringen det lokale grensesnittet og besvares av hjemmeruteren din. Adressen i endepunktet er fortsatt riktig, og oppslaget feiler fortsatt. Legg til ruten for resolveren, og test på nytt.

Overlappende lokale områder gir samme resultat på en mer irriterende måte: spørringen besvares, bare av feil server.

Ikke åpne sikkerhetsgrupper for Amazon DNS-adressen

Instinktet når oppslag timer ut, er å legge til en regel som tillater UDP 53 til resolveradressen. AWS dokumenterer at sikkerhetsgrupper og nettverks-ACL-er ikke filtrerer Amazon DNS-trafikk slik de filtrerer trafikk til en egen DNS-instans. Å åpne disse reglene endrer ingenting for VPC-resolveren og utvider grensen uten grunn. En resolver du driver selv er en annen sak og trenger faktisk sine egne regler.

Hvis begge finnes i designet ditt, sjekk hvilken klienten faktisk peker på før du redigerer noen regel.

Verifiser ruten, og mål så noe annet

Slå opp et offentlig navn, slå opp et privat navn som er registrert i en privat hostet sone knyttet til VPC-en, og les klientens aktive resolver mellom de to. Den rekkefølgen skiller «resolveradressen er feil» fra «sonen er ikke tilknyttet» og fra «klienten ignorerte innstillingen». Hver har sin egen retting, og ingen av dem er et gjennomstrømningsproblem.

Et vellykket oppslag sier ingenting om vedvarende overføringshastighet, så hold de to samtalene fra hverandre når du rapporterer.