DNS pri AWS Client VPN: uporabite resolver VPC, ne podomrežja

Endpoint je v 10.0.8.0/24, zato mora biti resolver 10.0.8.2. To je razmišljanje, ki ga slišim najpogosteje, in je dvakrat napačno. Route 53 Resolver odgovarja na glavnem območju IPv4 VPC plus dve, kar je za VPC 10.0.0.0/16 naslov 10.0.0.2, ne glede na to, katero podomrežje uporablja endpoint. Druga napaka je tišja: vnos pravilnega naslova v endpoint ne pomeni, da ga bo operacijski sistem odjemalca kdaj vprašal. Obe napaki dajeta enak simptom: razreševanje imen deluje pri nekaterih odjemalcih in ne uspe pri drugih.

Mit se začne pri povezavi podomrežja

Povezava se nanaša na to, kje so elastični omrežni vmesniki za odjemalske povezave, ne na to, kateri naslov resolverja obstaja. Podomrežja endpointa dajejo odjemalcem naslov znotraj VPC in nobeno od njih ne nosi svojega resolverja.

Ko ločite ti dve ideji, aritmetika ni več skrivnostna, odpravljanje težav pa se preseli k odjemalcu, kjer se večina teh primerov v resnici konča.

Izračunajte naslov iz glavnega območja VPC

Vzemite glavni IPv4 CIDR VPC in omrežnemu naslovu dodajte dve. 10.0.0.0/16 da 10.0.0.2, 172.31.0.0/16 da 172.31.0.2, VPC s sekundarnim območjem pa obdrži resolver na glavnem. Podomrežje 10.0.8.0/24 v tem VPC ga ne premakne. Zapišite naslov poleg ID VPC, preden se dotaknete endpointa, ker je število lastnost VPC in ne povezave.

VPC odgovarja tudi na link-local naslovu 169.254.169.253. Ta naslov je dosegljiv znotraj VPC, ni pa splošen usmerjen cilj za prenosnik na drugem koncu tunela.

Torej obstajata dva veljavna naslova resolverja in noben od njiju ni podomrežje plus dve.

Kaj nastavitev endpointa naredi in česa ne

Endpoint Client VPN ima polja strežnika DNS in kjer konzola ponuja možnost resolverja VPC, vpiše isto idejo. Njihova nastavitev spremeni, kaj storitev preda odjemalcem ob vzpostavitvi povezave. Ne spremeni tega, kaj neupravljani odjemalec OpenVPN naredi s to vrednostjo, ker jo mora še vedno uporabiti v operacijskem sistemu. Iz te vrzeli prihaja «deluje na mojem Macu, ne pa na Linux stroju».

V Linuxu integracija resolverja pripada upravitelju povezav, ne uporabniku. Ročno urejanje /etc/resolv.conf dokaže, da naslov deluje za eno sejo in nato ob ponovni povezavi izgine — zato se toliko popravljenih primerov vrne naslednje jutro.

Po povezavi preverite aktivni resolver pri odjemalcu, ne strani s konfiguracijo endpointa.

Split tunneling lahko premaga pravilen resolver

Pri split tunelingu se uporabljajo le poti, potisnjene v tunel. Če naslov resolverja ni pokrit s potjo, poizvedba zapusti lokalni vmesnik in odgovori vaš domači usmerjevalnik. Naslov v endpointu je še vedno pravilen in iskanje še vedno ne uspe. Dodajte pot za resolver in poskusite znova.

Prekrivajoča se lokalna območja dajo enak rezultat na bolj neprijeten način: poizvedba dobi odgovor, le od napačnega strežnika.

Ne odpirajte varnostnih skupin za naslov Amazon DNS

Ko iskanja potečejo, je nagon dodati pravilo, ki dovoli UDP 53 na naslov resolverja. AWS dokumentira, da varnostne skupine in omrežni ACL ne filtrirajo prometa Amazon DNS tako, kot filtrirajo promet do lastne instance DNS. Odpiranje teh pravil ne spremeni ničesar za resolver VPC in brez razloga širi mejo. Resolver, ki ga upravljate sami, je drug primer in res potrebuje svoja pravila.

Če se v vaši zasnovi pojavljata oba, preverite, na katerega odjemalec dejansko kaže, preden uredite katero koli pravilo.

Preverite pot in nato izmerite nekaj drugega

Razrešite javno ime, razrešite zasebno ime, registrirano v zasebnem gostovanem območju, povezanem z VPC, in med njima preberite aktivni resolver odjemalca. To zaporedje loči «naslov resolverja je napačen» od «območje ni povezano» in od «odjemalec je nastavitev ignoriral». Vsak ima drugačno popravo in noben ni težava s prepustnostjo.

Uspešno iskanje ne pove ničesar o trajni hitrosti prenosa, zato pri poročanju ti dve pogovora držite ločeno.