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

Endepunktet ligg i 10.0.8.0/24, så resolveren må vere 10.0.8.2. Det er resonnementet eg høyrer oftast, og det er feil to gonger. Route 53 Resolver svarar på det primære IPv4-området til VPC-en pluss to, som for ein VPC på 10.0.0.0/16 er 10.0.0.2, uansett kva subnett endepunktet brukar. Den andre feilen er stillare: å setje rett adresse i endepunktet tyder ikkje at operativsystemet til klienten nokon gong spør det om noko. Begge feila gjev same symptomet: namneoppslag virkar for nokre klientar og feilar for andre.

Myten byrjar ved subnett-tilknytinga

Tilknytinga handlar om kvar dei elastiske nettverksgrensesnitta for klienttilkoplingar bur, ikkje om kva resolveradresse som finst. Subnetta til endepunktet gjev klientane ei adresse inne i VPC-en, og dei ber ikkje kvar sin resolver.

Når du skil dei to ideane, sluttar aritmetikken å vere mystisk, og feilsøkinga flyttar til klienten, der dei fleste av desse sakene faktisk endar.

Rekn ut adressa frå det primære VPC-området

Tak det primære IPv4-CIDR-en til VPC-en og legg til to på nettverksadressa. 10.0.0.0/16 gjev 10.0.0.2, 172.31.0.0/16 gjev 172.31.0.2, og ein VPC med eit sekundært område held resolveren på det primære. Eit subnett på 10.0.8.0/24 inne i den VPC-en flyttar han ikkje. Skriv adressa ved sida av VPC-ID-en før du rører endepunktet, fordi talet er ein eigenskap ved VPC-en og ikkje ved tilkoplinga.

VPC-en svarar òg på link-local-adressa 169.254.169.253. Den adressa er nåbar innanfrå VPC-en, men ho er ikkje eit vanleg rutta mål for ein berbar PC i den andre enden av ein tunnel.

Så det finst to gyldige resolveradresser, og ingen av dei er subnettet pluss to.

Kva endepunktinnstillinga gjer og ikkje gjer

Client VPN-endepunktet har DNS-serverfelt, og der konsollen tilbyr eit VPC-resolver-alternativ fyller han inn same idé. Å setje dei endrar kva tenesta gjev klientane under oppkoplinga. Det endrar ikkje kva ein ikkje-administrert OpenVPN-klient gjer med verdien, fordi klienten framleis må bruke han på operativsystemet. Det gapet er der «det virkar på Macen min, men ikkje på Linux-boksen» kjem frå.

På Linux er resolverintegrasjonen eigd av tilkoplingshandsamaren og ikkje av brukaren. Å redigere /etc/resolv.conf for hand provar at adressa virkar for éi økt, og så forsvinn ho ved gjenoppkopling — difor kjem så mange retta saker tilbake neste morgon.

Sjekk den aktive resolveren på klienten etter tilkopling, ikkje konfigurasjonssida til endepunktet.

Split tunneling kan slå ut ein korrekt resolver

Med split tunneling vert berre ruter som er dytta inn i tunnelen brukte. Viss resolveradressa ikkje er dekt av ei rute, forlèt spørjinga det lokale grensesnittet og heimerutaren din svarar. Adressa i endepunktet er framleis rett, og oppslaget feilar framleis. Legg til ruta for resolveren, og test på nytt.

Overlappande lokale område gjev same resultat på ein meir irriterande måte: spørjinga vert svara, berre av feil tenar.

Ikkje opne sikkerheitsgrupper for Amazon DNS-adressa

Instinktet når oppslag går ut på tid, er å leggje til ei regel som tillèt UDP 53 til resolveradressa. AWS dokumenterer at sikkerheitsgrupper og nettverks-ACL-ar ikkje filtrerer Amazon DNS-trafikk slik dei filtrerer trafikk til ein eigen DNS-instans. Å opne desse reglane endrar ingenting for VPC-resolveren og utvidar grensa utan grunn. Ein resolver du driv sjølv er ei anna sak og treng faktisk sine eigne reglar.

Viss begge finst i designet ditt, sjekk kva klienten faktisk peikar på før du redigerer noka regel.

Stadfest ruta, og mål så noko anna

Slå opp eit offentleg namn, slå opp eit privat namn som er registrert i ei privat hosta sone knytt til VPC-en, og les den aktive resolveren til klienten mellom dei to. Den rekkjefølgja skil «resolveradressa er feil» frå «sona er ikkje knytt til» og frå «klienten ignorerte innstillinga». Kvar har si eiga retting, og ingen av dei er eit gjennomstrøymingsproblem.

Eit vellukka oppslag seier ingenting om varig overføringsfart, så hald dei to samtalene frå kvarandre når du rapporterer.