AWS Client VPN DNS: naudokite VPC resolverį, o ne potinklį

Endpointas yra 10.0.8.0/24, todėl resolveris turi būti 10.0.8.2. Tai dažniausiai girdimas samprotavimas, ir jis klaidingas du kartus. Route 53 Resolver atsako pagrindiniame VPC IPv4 diapazone plius du, kuris VPC 10.0.0.0/16 atveju yra 10.0.0.2, nesvarbu, kurį potinklį naudoja endpointas. Antroji klaida tylesnė: teisingo adreso įrašymas endpointe nereiškia, kad kliento operacinė sistema kada nors jo ko nors klaus. Abi klaidos duoda tą patį simptomą: vardų skyrimas veikia vieniems klientams, o kitiems nepavyksta.

Mitas prasideda nuo potinklio susiejimo

Susiejimas susijęs su tuo, kur gyvena elastingos tinklo sąsajos klientų jungtims, o ne su tuo, koks resolverio adresas egzistuoja. Endpointo potinkliai suteikia klientams adresą VPC viduje, ir kiekvienas jų neturi savo resolverio.

Atskyrus šias dvi idėjas, aritmetika nustoja būti paslaptinga, o trikčių šalinimas persikelia į klientą, kur dauguma šių atvejų iš tikrųjų pasibaigia.

Apskaičiuokite adresą iš pagrindinio VPC diapazono

Paimkite pagrindinį VPC IPv4 CIDR ir pridėkite du prie tinklo adreso. 10.0.0.0/16 duoda 10.0.0.2, 172.31.0.0/16 duoda 172.31.0.2, o VPC su antriniu diapazonu palieka resolverį pagrindiniame. Potinklis 10.0.8.0/24 tame VPC jo neperkelia. Užsirašykite adresą šalia VPC ID prieš liesdami endpointą, nes skaičius yra VPC savybė, o ne jungties.

VPC taip pat atsako link-local adresu 169.254.169.253. Šis adresas pasiekiamas VPC viduje, bet tai nėra bendras maršrutizuojamas tikslas nešiojamajam kompiuteriui kitame tunelio gale.

Taigi yra du galiojantys resolverio adresai, ir nė vienas jų nėra potinklis plius du.

Ką daro endpointo nustatymas, o ko ne

Client VPN endpointas turi DNS serverio laukus, o kur konsolė siūlo VPC resolverio parinktį, ji įrašo tą pačią idėją. Jų nustatymas keičia tai, ką paslauga perduoda klientams jungiantis. Tai nekeičia to, ką nevaldomas OpenVPN klientas daro su ta reikšme, nes klientas vis tiek turi ją pritaikyti operacinei sistemai. Iš šio tarpo kyla «veikia mano Mac, bet ne Linux kompiuteryje».

Linux sistemoje resolverio integracija priklauso ryšių tvarkyklei, o ne naudotojui. Rankinis /etc/resolv.conf redagavimas įrodo, kad adresas veikia vienai sesijai, o tada dingsta prisijungus iš naujo — todėl tiek daug sutvarkytų atvejų grįžta kitą rytą.

Prisijungę patikrinkite aktyvų resolverį kliente, o ne endpointo konfigūracijos puslapį.

Split tunneling gali nugalėti teisingą resolverį

Naudojant split tunneling naudojami tik į tunelį įstumti maršrutai. Jei resolverio adreso nepadengia joks maršrutas, užklausa išeina per vietinę sąsają ir atsako namų maršrutizatorius. Adresas endpointe vis dar teisingas, o paieška vis dar nepavyksta. Pridėkite maršrutą resolveriui ir bandykite dar kartą.

Persidengiantys vietiniai diapazonai duoda tą patį rezultatą nemaloniau: užklausa sulaukia atsakymo, tik iš netinkamo serverio.

Neatidarykite security groups Amazon DNS adresui

Kai paieškos baigiasi laikas, instinktas yra pridėti taisyklę, leidžiančią UDP 53 į resolverio adresą. AWS dokumentuoja, kad security groups ir tinklo ACL nefiltruoja Amazon DNS srauto taip, kaip filtruoja srautą į savo DNS egzempliorių. Šių taisyklių atidarymas nieko nekeičia VPC resolveriui ir be priežasties praplečia ribą. Pačiam valdomas resolveris yra kitas atvejis ir tikrai jam reikia savų taisyklių.

Jei jūsų dizaine yra abu, prieš redaguodami bet kurią taisyklę patikrinkite, į kurį klientas iš tikrųjų nukreiptas.

Patikrinkite kelią, tada matuokite ką nors kita

Išspręskite viešą vardą, išspręskite privatų vardą, įregistruotą privačioje prieglobos zonoje, susietoje su VPC, ir tarp jų perskaitykite aktyvų kliento resolverį. Ši seka atskiria «resolverio adresas neteisingas» nuo «zona nesusieta» ir nuo «klientas nepaisė nustatymo». Kiekvienas turi skirtingą pataisymą, ir nė vienas nėra pralaidumo problema.

Sėkminga paieška nieko nesako apie ilgalaikį perdavimo greitį, todėl ataskaitoje laikykite šiuos du pokalbius atskirai.