DNS ĉe AWS Client VPN: uzu la VPC-resolvilon, ne la subreton
La resolvilo por AWS Client VPN-endpunkto estas la ĉefa VPC-gamo plus du, ne ĉiu subreto plus du. Agordu ĝin, voju ĝin, poste kontrolu la klienton.
La endpunkto estas en 10.0.8.0/24, do la resolvilo devas esti 10.0.8.2. Tiu estas la rezonado, kiun mi plej ofte aŭdas, kaj ĝi malĝustas duoble. Route 53 Resolver respondas sur la ĉefa IPv4-gamo de la VPC plus du, kio por VPC 10.0.0.0/16 estas 10.0.0.2, sendepende de tio, kiun subreton la endpunkto uzas. La dua eraro estas pli silenta: meti la ĝustan adreson en la endpunkton ne signifas, ke la operaciumo de la kliento iam demandos ĝin pri io. Ambaŭ eraroj donas la saman simptomon: nomresolucio funkcias por iuj klientoj kaj malsukcesas por aliaj.
La mito komenciĝas ĉe la subreta asociiĝo
Asociiĝo temas pri tio, kie loĝas la elastaj retinterfacoj por klientaj konektoj, ne pri tio, kiu resolvila adreso ekzistas. La subretoj de la endpunkto donas al klientoj adreson ene de la VPC, kaj ili ne portas ĉiu sian propran resolvilon.
Iam vi apartigos tiujn du ideojn, la aritmetiko ĉesos esti mistera, kaj la problemserĉado transiros al la kliento, kie plej multaj el tiuj kazoj fakte finiĝas.
Kalkulu la adreson el la ĉefa VPC-gamo
Prenu la ĉefan IPv4-CIDR de la VPC kaj aldonu du al la reta adreso. 10.0.0.0/16 donas 10.0.0.2, 172.31.0.0/16 donas 172.31.0.2, kaj VPC kun dua gamo tenas la resolvilon sur la ĉefa. Subreto 10.0.8.0/24 ene de tiu VPC ne movas ĝin. Skribu la adreson apud la VPC-ID antaŭ ol tuŝi la endpunkton, ĉar la nombro estas eco de la VPC kaj ne de la konekto.
La VPC ankaŭ respondas sur la link-local adreso 169.254.169.253. Tiu adreso atingeblas de ene de la VPC, sed ĝi ne estas ĝenerala vojigita celo por tekokomputilo ĉe la alia fino de tunelo.
Do ekzistas du validaj resolvilaj adresoj, kaj neniu el ili estas la subreto plus du.
Kion la agordo de la endpunkto faras kaj kion ne
La Client VPN-endpunkto havas DNS-servilajn kampojn, kaj kie la konzolo proponas VPC-resolvilan opcion ĝi plenigas la saman ideon. Agordi ilin ŝanĝas tion, kion la servo transdonas al klientoj dum konekta starigo. Ĝi ne ŝanĝas tion, kion neadministrata OpenVPN-kliento faras kun tiu valoro, ĉar la kliento ankoraŭ devas apliki ĝin al la operaciumo. El tiu breĉo venas «ĝi funkcias sur mia Mac sed ne sur la Linux-maŝino».
En Linux la resolvila integriĝo apartenas al la konekta administrilo kaj ne al la uzanto. Redakti /etc/resolv.conf permane pruvas, ke la adreso funkcias por unu sesio kaj poste malaperas ĉe rekonekto — tial tiom multaj riparitaj kazoj revenas la sekvan matenon.
Kontrolu la aktivan resolvilon sur la kliento post konekto, ne la agordan paĝon de la endpunkto.
Split-tunneling povas venki ĝustan resolvilon
Ĉe split-tunneling nur la vojoj puŝitaj en la tunelon estas uzataj. Se la resolvila adreso ne estas kovrita per vojo, la peto eliras tra la loka interfaco kaj respondas via hejma enkursigilo. La adreso en la endpunkto restas ĝusta kaj la serĉo restas malsukcesa. Aldonu la vojon por la resolvilo, poste testu denove.
Interkovrantaj lokaj gamoj donas la saman rezulton pli malagrable: la peto estas respondata, nur de la malĝusta servilo.
Ne malfermu sekurecgrupojn por la adreso de Amazon DNS
La instinkto kiam serĉoj tempas for estas aldoni regulon permesantan UDP 53 al la resolvila adreso. AWS dokumentas, ke sekurecgrupoj kaj retaj ACL ne filtras Amazon DNS-trafikon tiel, kiel ili filtras trafikon al propra DNS-institucio. Malfermi tiujn regulojn ŝanĝas nenion por la VPC-resolvilo kaj larĝigas la limon sen kaŭzo. Resolvilo, kiun vi mem funkciigas, estas alia kazo kaj ja bezonas proprajn regulojn.
Se ambaŭ aperas en via dezajno, kontrolu, al kiu la kliento vere direktiĝas, antaŭ ol redakti ajnan regulon.
Kontrolu la vojon, poste mezuru ion alian
Resolvu publikan nomon, resolvu privatan nomon registritan en privata gastigata zono asociita kun la VPC, kaj legu la aktivan resolvilon de la kliento inter la du. Tiu sinsekvo apartigas «la resolvila adreso malĝustas» de «la zono ne asociiĝis» kaj de «la kliento ignoris la agordon». Ĉiu havas alian riparon, kaj neniu el ili estas trafluoproblemo.
Sukcesa serĉo diras nenion pri daŭra transiga rapido, do tenu tiujn du konversaciojn apartaj kiam vi raportas.