AWS Client VPN DNS: 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 rezonovanje koje najčešće čujem i pogrešno je dvaput. Route 53 Resolver odgovara na primarnom IPv4 opsegu 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: ispravna adresa u endpointu ne znači da će je operativni sistem klijenta ikada pitati bilo šta. Obje greš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čni mrežni interfejsi 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.

Kada razdvojite te dvije ideje, aritmetika prestaje biti misteriozna, a otklanjanje problema prelazi na klijenta, gdje većina ovih slučajeva zaista završi.

Izračunajte adresu iz primarnog VPC opsega

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 opsegom zadržava resolver na primarnom. Podmreža 10.0.8.0/24 unutar tog VPC-a to ne pomjera. Zapišite adresu pored ID-a 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 adresa je dostupna unutar VPC-a, ali nije opća rutirana destinacija za laptop na drugoj strani tunela.

Dakle, postoje dvije 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 gdje konzola nudi opciju VPC resolvera, ona popunjava istu ideju. Njihovo postavljanje mijenja ono što servis predaje klijentima tokom uspostave veze. To ne mijenja ono što neupravljani OpenVPN klijent radi s tom vrijednošću, jer klijent je još mora primijeniti 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 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 lokalni interfejs i na njega odgovara vaš kućni ruter. Adresa u endpointu je i dalje ispravna, a pretraga i dalje ne uspijeva. Dodajte rutu za resolver, pa testirajte ponovo.

Preklapajući lokalni opsezi 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 vlastitoj DNS instanci. Otvaranje tih pravila ne mijenja ništa za VPC resolver i širi granicu bez razloga. Resolver koji sami vodite je drugi 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 registrovano u privatnoj hostovanoj 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 ignorisao postavku». Svaki ima drugačije rješenje i nijedan nije problem propusnosti.

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