DNS na AWS Client VPN: koristite VPC resolver, ne podmrežu

Endpoint se nalazi u 10.0.8.0/24, pa resolver mora biti 10.0.8.2. To je rezonovanje koje najčešće čujem i pogrešno je dvaput. Route 53 Resolver odgovara na primarnom IPv4 rasponu VPC-a plus dva, što je za VPC 10.0.0.0/16 adresa 10.0.0.2, bez obzira na to koju podmrežu endpoint koristi. Druga greška je tiša: stavljanje ispravne adrese u endpoint ne znači da će je operativni sistem klijenta ikada pitati bilo šta. Obe greške daju isti simptom: razrešavanje imena radi kod nekih klijenata, a kod drugih ne.

Mit počinje kod asocijacije podmreže

Asocijacija se odnosi na to gde žive elastični mrežni interfejsi za klientske veze, a ne na to koja adresa resolvera postoji. Podmreže endpointa daju klijentima adresu unutar VPC-a i nijedna od njih ne nosi sopstveni resolver.

Kada razdvojite te dve ideje, aritmetika prestaje da bude misteriozna, a otklanjanje problema prelazi na klijenta, gde većina ovih slučajeva zaista završi.

Izračunajte adresu iz primarnog VPC raspona

Uzmite primarni IPv4 CIDR VPC-a i dodajte dva na mrežnu adresu. 10.0.0.0/16 daje 10.0.0.2, 172.31.0.0/16 daje 172.31.0.2, a VPC sa sekundarnim rasponom zadržava resolver na primarnom. Podmreža 10.0.8.0/24 unutar tog VPC-a to ne pomera. Zapišite adresu pored ID-a VPC-a pre nego što dirnete endpoint, jer je broj svojstvo VPC-a, a ne veze.

VPC odgovara i na link-local adresi 169.254.169.253. Ta adresa je dostupna unutar VPC-a, ali nije opšta rutirana destinacija za laptop na drugoj strani tunela.

Dakle, postoje dve važeće adrese resolvera i nijedna od njih nije podmreža plus dva.

Šta postavka endpointa radi, a šta ne

Endpoint Client VPN ima polja za DNS server, a gde konzola nudi opciju VPC resolvera, ona popunjava istu ideju. Njihovo postavljanje menja ono što servis predaje klijentima tokom uspostave veze. To ne menja ono što neupravljani OpenVPN klijent radi s tom vrednošću, jer klijent je još mora primeniti na operativni sistem. Iz tog jaza dolazi «radi na mom Macu, ali ne na Linux mašini».

Na Linuxu integracijom resolvera upravlja menadžer veza, a ne korisnik. Ručno uređivanje /etc/resolv.conf dokazuje da adresa radi za jednu sesiju, a zatim nestaje pri ponovnom povezivanju — zato se toliko popravljenih slučajeva vraća sledećeg jutra.

Proverite aktivni resolver na klijentu nakon povezivanja, a ne stranicu konfiguracije endpointa.

Split tunneling može da pobedi ispravan resolver

Uz split tunneling koriste se samo rute gurnute u tunel. Ako adresa resolvera nije pokrivena rutom, upit izlazi kroz lokalni interfejs i na njega odgovara vaš kućni ruter. Adresa u endpointu je i dalje ispravna, a pretraga i dalje ne uspeva. Dodajte rutu za resolver, pa testirajte ponovo.

Preklapajući lokalni rasponi daju isti rezultat na gori način: upit dobije odgovor, samo od pogrešnog servera.

Ne otvarajte sigurnosne grupe za adresu Amazon DNS

Instinkt kada pretrage isteknu je dodati pravilo koje dopušta UDP 53 na adresu resolvera. AWS dokumentuje da sigurnosne grupe i mrežni ACL-ovi ne filtriraju Amazon DNS saobraćaj onako kako filtriraju saobraćaj prema sopstvenoj DNS instanci. Otvaranje tih pravila ne menja ništa za VPC resolver i širi granicu bez razloga. Resolver koji sami vodite je drugi slučaj i zaista mu trebaju sopstvena pravila.

Ako se oba pojavljuju u vašem dizajnu, proverite na koje je klijent zaista usmeren pre nego što uredite bilo koje pravilo.

Proverite put, pa izmerite nešto drugo

Razrešite javno ime, razrešite privatno ime registrovano u privatnoj hostovanoj zoni povezanoj s VPC-om i pročitajte aktivni resolver klijenta između to dvoje. Taj sled odvaja «adresa resolvera je pogrešna» od «zona nije povezana» i od «klijent je ignorisao postavku». Svaki ima drugačije rešenje i nijedan nije problem propusnosti.

Uspešna pretraga ne govori ništa o trajnoj brzini prenosa, zato držite ta dva razgovora odvojeno kada izveštavate.