Pribadong pangalan ng DNS o IP lang? Magpasya bago ito ibahagi

Dalawang tanong ang naghahalo kapag binuksan ang isang pribadong serbisyo sa malalayong gumagamit. Ang una ay kung anong pangalan ang dapat gamitin ng mga kliyente; ang pangalawa ay kung aling mga pinagmumulan ang dapat tanggapin ng serbisyo. Sagutin ang mga ito sa ganoong pagkakasunod-sunod, dahil ang tamang pangalan sa likod ng maling tuntunin ng pag-access ay nabibigo pa rin, at ang tamang tuntunin sa likod ng pangalang hindi nagre-resolve ay hindi kailanman nasusubukan.

Unang kundisyon: anong landas ng resolver ang mayroon ang mga kliyente?

Gumagana lamang ang pribadong pangalan kung masasagot ito ng resolver ng kliyente. Ibig sabihin, ang awtorisadong malayong kliyente ay dapat makarating sa isang server ng DNS na may hawak ng zone, sa pamamagitan man ng tunnel o ng resolver na pinapatakbo na ng organisasyon para sa malalayong gumagamit. Ang tunnel ay transportasyon, hindi direktoryo. Binibigyan nito ang kliyente ng landas patungo sa resolver, at hindi nito sinasabi kung aling zone ang tatanungin.

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

Hindi matututunan ng pampublikong resolver ang pribadong zone dahil lang nakakonekta ang laptop sa isang VPN.

Ang suffix ay karapat-dapat sa parehong pansin. Gumamit ng subdomain ng domain na kinokontrol ng organisasyon, upang manatiling malinaw ang pagmamay-ari at pagpaplano ng sertipiko. Iwasan ang .local: itinatali ng espesipikasyon ng multicast DNS ang suffix na iyon sa link-local na resolusyon, at hindi ginagaya ng niruruta na tunnel ang ganoong pag-uugali para sa iyo.

Ikalawang kundisyon: anong pinagmumulan ang tinatanggap ng serbisyo?

Ang mga tuntunin ng pagtanggap ay isinusulat laban sa mga address, kaya ang kapaki-pakinabang na tanong ay kung anong address ang nakikita ng serbisyo pagkatapos ng routing at pagsasalin. Para sa isang halimbawang serbisyo sa 10.20.30.40, ang mga kliyente sa opisina ay nagmumula sa 10.20.30.0/24 at ang malalayong kliyente ay nagmumula sa hiwalay na pool tulad ng 10.99.0.0/24.

Kung isinasalin ng gateway ang malayong pool, nakikita ng serbisyo ang tagasalin, at ang tuntuning isinulat para sa 10.99.0.0/24 ay hindi magtutugma.

Basahin ito mula sa panig ng serbisyo at hindi sa panig ng kliyente. Ang log ng tagapakinig o ang paghuli ng packet sa host ng serbisyo ay nagpapakita ng pinagmumulang aktuwal na dumating; ang sariling address ng kliyente ay hula lamang tungkol sa kung ano ang nakaligtas sa landas.

Ikatlong kundisyon: ang pangalan ba ay nakatali sa serbisyo o sa host?

Ang pangalang tumuturo sa address ng isang makina ay nagtatali sa bawat kliyente sa makinang iyon. Ang pangalang tumuturo sa isang load balancer o matatag na address ng serbisyo ay nakakaligtas sa pagpapalit ng host sa likod nito. Pumili nang sinasadya, dahil ang pagbabago nito mamaya ay nangangahulugan ng pagbabago ng mga bookmark ng bawat kliyente at ng paksa ng bawat sertipiko.

Para sa isang panloob na serbisyo, ang direktang record ay karaniwang angkop at mas madaling isipin.

Para sa anumang papalitan, itatayo muli o isasakala, ang matatag na front end ay sulit sa karagdagang configuration. Simple ang pagsubok: kung mapapalitan mo ang backend nang hindi sinasabi sa mga gumagamit, ang pangalan ay nakatali sa serbisyo; kung hindi mo kaya, ito ay nakatali sa host.

Subukan ang dalawang desisyon nang hiwalay

I-resolve muna, pagkatapos kumonekta. Ang pagsubok sa resolusyon na nagbabalik ng inaasahang address ay nagpapatunay ng landas ng pangalan at walang sinasabi tungkol sa pag-access. Ang pagsubok sa koneksyon ay nagpapatunay ng landas at tuntunin nang sabay, kaya patakbuhin lamang ito pagkatapos ng matagumpay na resolusyon.

curl -sv --max-time 5 https://files.corp.example/health

Pagkatapos ay subukan ang isang ipinagbabawal na pinagmumulan nang isang beses, at itala ang resulta.

Panatilihing hiwalay ang dalawang record sa iyong dokumentasyon: ang pangalan at ang zone nito, ang mga tinatanggap na pinagmumulan at ang may-ari ng tuntunin. Kapag nagbago ang isa, hindi kailangang magbago ang iba.

Kung saan karaniwang nagkakamali ang desisyon

Ang karaniwang pagkabigo ay isang serbisyong inilathala sa ilalim ng pangalang nagre-resolve lamang sa network ng opisina, kasama ang tuntunin ng pag-access na tumatanggap lamang sa saklaw ng opisina. Pagkatapos ay iniuulat ng malalayong gumagamit ang sirang serbisyo na sa katotohanan ay dalawang hiwalay na pagkalimot. Ang ikalawang karaniwang pagkabigo ay ang kabaligtaran: ang malawak na tuntunin ng pag-access na idinagdag upang alisin ang problema sa pangalan ay nag-iiwan sa serbisyo na maabot mula sa mga pinagmumulang walang sinumang naglayon. Pareho silang pagkalimot sa configuration, at mula sa upuan ng gumagamit ay magkamukha sila.

Walang alinman sa mga pagkakamali ang nakikita mula sa isang matagumpay na pagsubok. Iyon ang dahilan kung bakit ang dalawang desisyon ay karapat-dapat sa hiwalay na record at hiwalay na pagsubok, kahit na ang isang tao lang ang gumagawa ng pareho.

Isulat ang pareho bago magsimula ang serbisyo, dahil ang susunod na pagbabago ay mas madaling isipin. Maikli ang record: isang linya para sa pangalan at zone nito, isang linya para sa mga tinatanggap na pinagmumulan at ang may-ari ng tuntunin.