DNS ng AWS Client VPN endpoint: bakit nabibigo ang pag-pin sa naresolbang IP

Noong nakaraang linggo, dig +short ay nagbigay sa iyo ng isang address para sa pangalan ng endpoint sa iyong AWS Client VPN profile, at kumonekta ang tunnel. Ngayong linggo, ang parehong profile ay nakatigil sa 'Connecting' sa iyong laptop habang ang hindi nagalaw na kopya ng katrabaho ay gumagana pa rin. Walang na-block at hindi nag-expire ang certificate. May pumalit sa hostname ng endpoint ng address na iyon, at hindi na tumutugon ang serbisyo doon. Ang na-export na pangalan ang bahaging ginawa upang makatagal sa pagbabagong iyon.

Ang pangalan sa iyong profile ay maaaring hindi ang pangalang tinatanong

Ang mga profile na na-export mula sa Client VPN ay kadalasang may remote-random-hostname. Kapag naka-on ang opsyong iyon, gumagawa ang client ng isang beses-gamitin na label, ikinakabit ito sa pangalan ng endpoint gamit ang tuldok, at niresolba ang pinagsamang pangalan. Sinasagot ng wildcard record sa zone ng endpoint ang anumang label, kaya niresolba pa rin ang gawa-gawang prefix at kaya nananatiling hindi nakikita ang trick kapag sinusubukan mong ulitin ang query nang manu-mano.

Kaya kapag ipinaste mo ang pangalan ng endpoint sa terminal at nakakuha ng sagot, niresolba mo ang ibang pangalan kaysa sa ginagamit ng client kapag kumokonekta. Ang pagkakaibang iyon ay hindi depektong dapat ayusin sa profile. Ang label ay muling ginagawa nang sadya: pinipigilan ng opsyong iyon ang mga cache na humawak ng lumang sagot, at hindi nito kailanman tinutukoy ang iyong makina o session.

Nakaranas ako ng kaso ng compatibility kung saan binabalewala ng client ang opsyong iyon nang tuluyan. Dokumentado ng AWS ang solusyon: panatilihin ang tunay na pangalan ng endpoint at maglagay ng random na string at tuldok sa harap, itinuturing itong pattern ng pagpapangalan at hindi halagang ipapaste. Makatuwirang ilapat ito sa lumang client; hindi makatuwiran na i-hardcode ang string na may prefix bilang endpoint.

Bakit hindi maaaring manatiling tama ang naka-save na sagot

Ang mga address ng endpoint ng Client VPN ay pinamamahalaan ng AWS at nagbabago sa paglipas ng panahon, na sinasabi nang malinaw ng dokumentasyon ng best practices. Ang nakuhang sagot ay snapshot ng isang resolusyon. Ang profile na nagha-hardcode nito ay nagiging profile na nakatutok sa isang host na na-decommission sa sandaling lumipat ang serbisyo, at bihirang magmukhang DNS ang pagpalya: makakakuha ka ng timeout sa koneksyon o natigil na handshake, kaya hinahabol ng mga tao ang routing at mga certificate.

Ang parehong sagot sa /etc/hosts ay nagmamana ng parehong pag-expire na may dagdag na problema. Ang hosts entry ay nakakaligtas sa mga reboot, muling pag-export at 'i-reinstall ang client' na pag-aayos, kaya bumabalik ang pagpalya tuwing gumagalaw ang address. May nakita akong isang nanatiling walang pinsala nang maraming linggo, pagkatapos ay pinatigil ang bawat makinang may dala nito habang normal na kumokonekta ang mga bagong install. Ang paghati na iyon, isang grupo ang nabibigo at isa pa ang maayos sa parehong account, ang pinakamurang palatandaan na makukuha mo.

Limitahan nang tama ang saklaw ng randomization. Nangyayari ito sa bawat pagtatangkang kumonekta. Ang naitatag na tunnel ay hindi muling niresolba ang endpoint nito, hindi nagpapalit ng server sa gitna ng session, at ang mga indibidwal na kahilingan ng application ay hindi bawat isa pumipili ng bagong VPN host. Ang susunod na pagtatangka lamang ang muling nagre-resolba, kaya ang session na gumagana buong hapon ay walang sinasabi tungkol sa bukas ng umaga.

Ano ang sinusuri ng serbisyo kapag umaangat ang tunnel

Inaatasan ng Client VPN na ang address na kinakabitan mo ay tumugma sa address na niresolba para sa DNS name ng endpoint. Ang isang pangangailangang iyon ay nagpapaliwanag ng ilang pagpalya na mukhang walang kaugnayan: custom DNS record na nakaturo sa ibang lugar, custom frontend na nagpapasa sa tunay na address ng endpoint, at profile na muling isinulat sa hilaw na address. Dokumentado ng AWS ang kumbinasyon ng custom record at forwarding bilang pagpalya sa mga bagong client na bigay ng AWS. Kitid ang pagsusuri; hindi ito hatol na bawal ang bawat alias.

Hindi rin ito pangkalahatang tuntunin tungkol sa mga protocol ng VPN. Ang numerikong remote ay ganap na wasto sa ordinaryong deployment ng OpenVPN, at marami ang gumagana nang ganoon. Ang paghihigpit ay nagmumula sa pinamamahalaang kaayusan, hindi sa protocol sa ilalim nito.

Na ginagawang maling repleks ang pagluluwag ng verification ng certificate. Kung nabibigo ang profile pagkatapos ng pagpapalit ng address, inililipat ng pag-off ng server verification ang error sa halip na ayusin ang resolusyon o ang pangangailangan ng pagtutugma ng address, at nag-iiwan ng client na magtitiwala sa kahit ano. Panatilihin ang na-export na CA, server verification at mga setting ng mutual authentication kung paano sila dumating.

Ang allowlist, egress at pribadong DNS ay tatlong magkahiwalay na problema

Ang firewall rule na dapat magpahintulot ng destinasyon bago kumonekta ang laptop ay tungkol sa panlabas na listener. Ibigay sa may-ari ng network ang pangalan ng endpoint, ang transport at ang naka-configure na port, pagkatapos ay itanong kung masusundan ng kanilang kontrol ang gawi ng DNS ng serbisyo. Ang rule na may hawak ng isang nakuhang address ay snapshot na may hindi nakasulat na pag-expire. Kung ang kontrol ay tumatanggap lamang ng hindi nagbabagong destinasyon, ayusin ang puwang na iyon bago ang rollout sa halip na tahimik na i-hardcode ang sagot.

Ang partner na nangangailangan ng fixed source address para sa mga kahilingang ginawa pagkatapos ng tunnel ay may ibang pangangailangan: egress. Ang nakikita ng isang website ay nakasalalay sa ruta ng application at sa patakaran ng split tunnel, hindi sa address na kinonektahan ng client. Maaaring hindi man lang mahawakan ng split-tunnel traffic ang AWS.

Ang pribadong DNS sa loob ng tunnel ay ikatlong suson. Ang resolver na ibinigay sa mga client ay sumasagot sa mga panloob na pangalan pagkatapos ng koneksyon; hindi nito maaaring i-resolba ang pampublikong endpoint bago umiral ang tunnel. Ang pagpalya sa resolusyon ng endpoint at ang pagpalya sa resolusyon ng panloob na application ay nangyayari sa magkaibang yugto, at ang paghahalo sa kanila ay magdadala sa iyo sa maling log.

Ang pamilya ng address ay kabilang sa parehong listahan. Ang sagot na IPv4 ay walang sinasabi tungkol sa pinapayagang landas ng IPv6 o dual-stack na endpoint, kaya ang snapshot na kinuha sa isang pamilya ay hindi ebidensya para sa isa pa.

Suriin ang koneksyon nang hindi nag-pin ng anuman

Magsimula sa profile kung paano ito na-export at basahin kung ano talaga ang hinihingi nito:

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

Pagkatapos ay ihambing ang tatlong bagay: ang pangalan ng endpoint na hawak ng profile, ang address na iniuulat ng client para sa bagong pagtatangka, at kung ano ang niresolba ng pangalan ngayon. Ang pangalang niresolba ay nagpapatunay lamang na sumasagot ang record; magkahiwalay ang transport at authentication, at hindi kailangang tumugon ang endpoint sa ping. Ang log ng client mismo ang tanging pinagmumulan para sa gitnang item, kaya kunin ito habang nagtatangka at hindi pagkatapos.

Ang address na sumasagot ngayon ay ebidensya tungkol sa ngayon; ang pangalan ang bagay na pinananatiling wasto ng serbisyo. Itala ang obserbasyon, ipadala ito sa may-ari ng endpoint, at hayaang nakaturo ang profile sa pangalan.

Dalawang ugali na dapat iwanan: pag-off ng mga pagsusuri ng certificate upang madaanan ang natigil na handshake, at pagtatambak ng mga label sa harap ng pangalan ng endpoint umaasa na may kakapit. Ang label ay niresolba sa pamamagitan ng wildcard record o nasa ibang lugar ang problema. Kung nabibigo pa rin ang wastong naka-configure na profile, ipadala ang eksaktong query at ang kaganapan ng koneksyon, hindi mas mahabang hostname.

Bago ito isara: dala pa rin ng profile ang na-export na pangalan ng endpoint, walang hosts file na nag-pin ng address, tumutugma ang remote sa log ng client sa kasalukuyang resolusyon, at pinapangalanan ng firewall rule ang endpoint at hindi ang address. Iyon din ang kalagayang ipapasa sa susunod na tao.