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

Endpoint se nalazi u 10.0.8.0/24, pa resolver mora biti 10.0.8.2. To je rezoniranje 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 je pogreška tiša: stavljanje ispravne adrese u endpoint ne znači da će je operativni sustav klijenta ikada pitati bilo što. Obje pogreške daju isti simptom: razrješavanje imena radi kod nekih klijenata, a kod drugih ne.

Mit počinje kod asocijacije podmreže

Asocijacija se odnosi na to gdje žive elastična mrežna sučelja za klijentske veze, a ne na to koja adresa resolvera postoji. Podmreže endpointa daju klijentima adresu unutar VPC-a i nijedna od njih ne nosi vlastiti resolver.

Kad razdvojite te dvije ideje, aritmetika prestaje biti tajanstvena, a otklanjanje problema prelazi na klijenta, gdje 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 pomiče. Zapišite adresu uz ID VPC-a prije nego dirnete endpoint, jer je broj svojstvo VPC-a, a ne veze.

VPC odgovara i na link-local adresi 169.254.169.253. Ta je adresa dostupna unutar VPC-a, ali nije opća usmjerena destinacija za prijenosno računalo na drugoj strani tunela.

Dakle postoje dvije valjane adrese resolvera i nijedna od njih nije podmreža plus dva.

Što postavka endpointa radi, a što ne

Endpoint Client VPN ima polja DNS poslužitelja, a gdje konzola nudi opciju VPC resolvera, popunjava istu ideju. Njihovo postavljanje mijenja ono što servis predaje klijentima tijekom uspostave veze. To ne mijenja ono što neupravljani OpenVPN klijent radi s tom vrijednošću, jer je klijent još mora primijeniti na operativni sustav. Iz tog jaza dolazi «radi na mom Macu, ali ne na Linux stroju».

Na Linuxu integracijom resolvera upravlja upravitelj 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 sljedećeg jutra.

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

Split tunneling može pobijediti ispravan resolver

Uz split tunneling koriste se samo rute gurnute u tunel. Ako adresa resolvera nije pokrivena rutom, upit izlazi kroz lokalno sučelje i na njega odgovara vaš kućni usmjerivač. Adresa u endpointu i dalje je ispravna, a pretraga i dalje ne uspijeva. Dodajte rutu za resolver, pa testirajte ponovno.

Preklapajući lokalni rasponi daju isti rezultat na gorlji način: upit dobije odgovor, samo od pogrešnog poslužitelja.

Ne otvarajte sigurnosne grupe za adresu Amazon DNS

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

Ako se oba pojavljuju u vašem dizajnu, provjerite na koje je klijent zaista usmjeren prije nego uredite bilo koje pravilo.

Provjerite put, pa izmjerite nešto drugo

Razriješite javno ime, razriješite privatno ime registrirano u privatnoj hostanoj zoni povezanoj s VPC-om i pročitajte aktivni resolver klijenta između to dvoje. Taj slijed odvaja «adresa resolvera je pogrešna» od «zona nije povezana» i od «klijent je ignorirao postavku». Svaki ima drugačije rješenje i nijedan nije problem propusnosti.

Uspješna pretraga ne govori ništa o trajnoj brzini prijenosa, zato držite ta dva razgovora odvojeno kad izvještavate.