DNS by AWS Client VPN: brûk de VPC-resolver, net it subnet
De resolver foar in AWS Client VPN-einpunt is it primêre VPC-berik plus twa, net elk subnet plus twa. Stel it yn, rûte it, kontrolearje dan de klient.
It einpunt sit yn 10.0.8.0/24, dus moat de resolver 10.0.8.2 wêze. Dat is de redenearring dy’t ik it meast hear, en it is twa kear ferkeard. Route 53 Resolver antwurdet op it primêre IPv4-berik fan de VPC plus twa, wat foar in VPC fan 10.0.0.0/16 10.0.0.2 is, hokker subnet it einpunt ek brûkt. De twadde flater is stiller: it goede adres yn it einpunt sette betsjut net dat it bestjoeringssysteem fan de klient der ea wat oan freget. Beide flaters jouwe itselde symptoom: nammeoplossing wurket by guon klienten en mislearret by oaren.
De myte begjint by de subnet-assosjaasje
Assosjaasje giet oer wêr’t de elastyske netwurkynterfaces foar klientferbiningen wenje, net oer hokker resolveradres bestiet. De subnets fan it einpunt jouwe klienten in adres binnen de VPC, en elk dêrfan draacht gjin eigen resolver.
Sadree’t jo dy twa ideeën skiede, is de rekkenkunde net mear mysterieus en ferhuzet it probleemoplossen nei de klient, dêr’t de measte fan dizze gefallen echt einigje.
Berekkenje it adres út it primêre VPC-berik
Nim it primêre IPv4-CIDR fan de VPC en foegje twa ta oan it netwurkadres. 10.0.0.0/16 jout 10.0.0.2, 172.31.0.0/16 jout 172.31.0.2, en in VPC mei in sekundêr berik hâldt de resolver op it primêre. In subnet fan 10.0.8.0/24 binnen dy VPC ferpleatst him net. Skriuw it adres njonken de VPC-ID foardat jo it einpunt oanreitsje, want it getal is in eigenskip fan de VPC en net fan de ferbining.
De VPC antwurdet ek op it link-local adres 169.254.169.253. Dat adres is fan binnen de VPC berikber, mar it is gjin algemien rûte bestimming foar in laptop oan de oare kant fan in tunnel.
Der binne dus twa jildige resolveradressen, en net ien fan beide is it subnet plus twa.
Wat de einpunt-ynstelling docht en wat net
It Client VPN-einpunt hat DNS-tsjinnerfjilden, en wêr’t de konsole in VPC-resolveropsje biedt follet dy itselde idee yn. Se ynstelle feroaret wat de tsjinst by it opbouwen fan de ferbining oan klienten jout. It feroaret net wat in net-beheard OpenVPN-klient mei dy wearde docht, want de klient moat it noch altyd op it bestjoeringssysteem tapasse. Ut dy kleau komt «it wurket op myn Mac mar net op de Linux-doaze».
Op Linux is de resolveryntegraasje eigendom fan de ferbiningsbehearder en net fan de brûker. /etc/resolv.conf mei de hân bewurkje bewiist dat it adres foar ien sesje wurket en dan ferdwynt by werferbinen — dêrom komme safolle reparearre gefallen de folgjende moarns werom.
Kontrolearje de aktive resolver op de klient nei it ferbinen, net de konfiguraasjeside fan it einpunt.
Split tunneling kin in korrekte resolver ferslaan
Mei split tunneling wurde allinnich rûtes brûkt dy’t yn de tunnel skood wurde. As it resolveradres net troch in rûte dekt wurdt, ferlit de query de lokale interface en antwurdet jo thúsrouter. It adres yn it einpunt is noch altyd korrekt en it opfreegjen mislearret noch altyd. Foegje de rûte foar de resolver ta en test dan opnij.
Oerlaapjende lokale berikken jouwe itselde resultaat op in ferfelender manier: de query wurdt beantwurde, mar troch de ferkearde tsjinner.
Meitsje gjin befeiligingsgroepen iepen foar it Amazon DNS-adres
De ympuls by it ferrinnen fan opfregingen is in regel ta te foegjen dy’t UDP 53 nei it resolveradres tastiet. AWS dokumintearret dat befeiligingsgroepen en netwurk-ACL’s Amazon DNS-ferkear net filterje sa’t se ferkear nei in eigen DNS-eksimplaar filterje. It iepenjen fan dy regels feroaret neat foar de VPC-resolver en ferbredelet de grins sûnder reden. In resolver dy’t jo sels draaie is in oar gefal en hat wol eigen regels nedich.
As beide yn jo ûntwerp foarkomme, kontrolearje dan op hokker de klient echt rjochte is foardat jo in regel bewurkje.
Kontrolearje it paad, mjit dan wat oars
Los in iepenbiere namme op, los in partikuliere namme op dy’t registrearre is yn in partikuliere hoste sône ferbûn mei de VPC, en lês dertusken de aktive resolver fan de klient. Dy folchoarder skiedt «it resolveradres is ferkeard» fan «de sône is net ferbûn» en fan «de klient hat de ynstelling negearre». Elk hat in oare oplossing, en net ien is in trochfiertprobleem.
In slagge opfrege seit neat oer oanhâldende oerdrachtsnelheid, dus hâld dy beide petearen apart as jo weromrapportearje.