DNS sa AWS Client VPN: gamitin ang VPC resolver, hindi ang subnet

Ang endpoint ay nasa 10.0.8.0/24, kaya ang resolver ay dapat 10.0.8.2. Ito ang pinakamadalas kong marinig na pangangatwiran, at mali ito nang dalawang beses. Sumasagot ang Route 53 Resolver sa pangunahing saklaw ng IPv4 ng VPC dagdag dalawa, na para sa VPC na 10.0.0.0/16 ay 10.0.0.2, anuman ang subnet na gamitin ng endpoint. Ang pangalawang mali ay mas tahimik: ang paglalagay ng tamang address sa endpoint ay hindi nangangahulugang tatanungin ito ng operating system ng kliyente. Pareho ang sintomas ng dalawang mali: gumagana ang paglutas ng pangalan sa ilang kliyente at nabibigo sa iba.

Nagsisimula ang alamat sa pagkakaugnay ng subnet

Ang pagkakaugnay ay tungkol sa kung saan naroroon ang elastic network interfaces para sa mga koneksyon ng kliyente, hindi tungkol sa kung aling address ng resolver ang umiiral. Binibigyan ng mga subnet ng endpoint ang mga kliyente ng address sa loob ng VPC, at wala sa kanila ang may sariling resolver.

Kapag hinati mo ang dalawang ideya, hindi na mahiwaga ang aritmetika at lumilipat ang pag-troubleshoot sa kliyente, kung saan talaga nagtatapos ang karamihan sa mga kasong ito.

Kalkulahin ang address mula sa pangunahing saklaw ng VPC

Kunin ang pangunahing CIDR ng IPv4 ng VPC at magdagdag ng dalawa sa address ng network. Nagbibigay ang 10.0.0.0/16 ng 10.0.0.2, ang 172.31.0.0/16 ng 172.31.0.2, at ang VPC na may pangalawang saklaw ay nagpapanatili ng resolver sa pangunahin. Hindi ito ginagalaw ng subnet na 10.0.8.0/24 sa loob ng VPC na iyon. Isulat ang address sa tabi ng VPC ID bago hawakan ang endpoint, dahil ang numero ay katangian ng VPC at hindi ng koneksyon.

Sumasagot din ang VPC sa link-local address na 169.254.169.253. Naabot ang address na iyon mula sa loob ng VPC, ngunit hindi ito pangkalahatang niruruta na destinasyon para sa laptop sa kabilang dulo ng tunnel.

Kaya may dalawang valid na address ng resolver, at wala sa kanila ang subnet dagdag dalawa.

Ano ang ginagawa at hindi ginagawa ng setting ng endpoint

May mga field ng DNS server ang endpoint ng Client VPN, at kung saan nag-aalok ang console ng opsyon na VPC resolver pinupuno nito ang parehong ideya. Binabago ng pagtatakda sa kanila ang ibinibigay ng serbisyo sa mga kliyente habang nagtatatag ng koneksyon. Hindi nito binabago ang ginagawa ng hindi pinamamahalaang OpenVPN client sa halagang iyon, dahil kailangan pa rin itong ilapat ng kliyente sa operating system. Mula sa agwat na iyon nagmumula ang «gumagana sa Mac ko pero hindi sa Linux box».

Sa Linux pag-aari ng connection manager ang integrasyon ng resolver at hindi ng user. Ang manu-manong pag-edit ng /etc/resolv.conf ay nagpapatunay na gumagana ang address sa isang session at pagkatapos ay nawawala kapag muling kumonekta — kaya maraming naayos na kaso ang bumabalik sa susunod na umaga.

Suriin ang aktibong resolver sa kliyente pagkatapos kumonekta, hindi ang pahina ng configuration ng endpoint.

Maaaring talunin ng split tunneling ang tamang resolver

Sa split tunneling, tanging ang mga rutang itinulak sa tunnel ang ginagamit. Kung ang address ng resolver ay hindi sakop ng ruta, lumalabas ang query sa lokal na interface at ang router sa bahay ang sumasagot. Tama pa rin ang address sa endpoint at nabibigo pa rin ang paghahanap. Idagdag ang ruta para sa resolver, pagkatapos ay subukan muli.

Ang magkakapatong na lokal na saklaw ay nagbibigay ng parehong resulta sa mas nakakainis na paraan: sinasagot ang query, mula lamang sa maling server.

Huwag buksan ang security groups para sa address ng Amazon DNS

Ang instinct kapag nag-time out ang mga paghahanap ay magdagdag ng panuntunang nagpapahintulot ng UDP 53 patungo sa address ng resolver. Itinatala ng AWS na hindi sinasala ng security groups at network ACL ang trapik ng Amazon DNS tulad ng pagsala nila sa trapik patungo sa sariling DNS instance. Walang binabago ang pagbubukas ng mga panuntunang iyon para sa resolver ng VPC at pinalalawak nito ang hangganan nang walang dahilan. Ang resolver na ikaw mismo ang nagpapatakbo ay ibang kaso at talagang kailangan nito ng sariling mga panuntunan.

Kung pareho silang lumilitaw sa disenyo mo, suriin kung alin ang talagang tinutukoy ng kliyente bago i-edit ang anumang panuntunan.

I-verify ang landas, pagkatapos sukatin ang iba

Lutasin ang pampublikong pangalan, lutasin ang pribadong pangalan na nakarehistro sa pribadong naka-host na zone na nauugnay sa VPC, at basahin sa pagitan ng dalawa ang aktibong resolver ng kliyente. Hinihiwalay ng pagkakasunod-sunod na iyon ang «mali ang address ng resolver» mula sa «hindi nakaugnay ang zone» at sa «binabalewala ng kliyente ang setting». Bawat isa ay may ibang pagwawasto, at wala sa kanila ang problema sa throughput.

Walang sinasabi ang matagumpay na paghahanap tungkol sa tuluy-tuloy na bilis ng paglilipat, kaya paghiwalayin ang dalawang usapang iyon kapag nag-uulat.