DNS ya kibinafsi ya Azure kupitia VPN: mwisho wa resolver au forwarder
Miundo yote miwili hujibu maeneo ya kibinafsi kupitia handaki. Linganisha mwisho wa kuingia unaosimamiwa na VM ya forwarder, kisha kagua njia ambayo lazima iwepo katika hali zote mbili.
Seva iliyo kwenye eneo inafikia VM ya Azure kwa anwani ya kibinafsi na bado haiwezi kutatua jina lake la mwenyeji la kibinafsi, jambo linalowafanya watu watafute handaki iliyovunjika. Handaki ni sawa. Kinachokosekana ni mpaka wa DNS: hakuna kitu upande wa eneo linalojua kwamba eneo fulani la kibinafsi la Azure linapaswa kujibiwa na resolver ndani ya VNet. Miundo miwili huziba pengo hilo, na hutofautiana katika kile unachosimamia mwishoni, si katika kama maswali yanafanya kazi.
Handaki hubeba maswali, si ujuzi wa maeneo
Muunganisho wa tovuti-hadi-tovuti huwapa pakiti njia kati ya mitandao miwili. Hauiambii seva ya DNS ya eneo ni nafasi gani ya majina inayomilikiwa na Azure au anwani gani inapaswa kujibu, kwa hiyo swali ama huenda mtandaoni na kurudi tupu, ama haliishi kamwe kutoka kwa resolver ya eneo.
Suluhisho lina nusu mbili ambazo ni rahisi kutenganisha. Nusu moja ni resolver ndani ya VNet inayokubali maswali yanayokuja kupitia handaki. Nyingine ni forwarder yenye sharti upande wa eneo inayotuma nafasi moja kamili ya majina kwa resolver huyo. Hakuna nusu inayofanya kazi peke yake.
Chukulia kuwa eneo ni cloud.corp.example kwa sehemu iliyobaki ya maelezo haya, na chukua kila anwani kama mfano.
Chaguo A: mwisho wa kuingia unaosimamiwa
Azure DNS Private Resolver hutoa mwisho wa kuingia unaokubali maswali ya DNS kutoka nje ya VNet. Unaiweka katika subnet iliyokasimiwa maalum, unaunganisha eneo la kibinafsi na VNet hiyo, na unaandika anwani ya kuingia ambayo huduma inatoa.
Kisha kwenye seva ya DNS ya eneo unaunda forwarder yenye sharti kwa nafasi kamili ya majina kuelekea anwani hiyo:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Utaratibu wa DNS mseto wa Microsoft unaandika kiungo cha eneo na hatua ya forwarder. Njia inayosimamiwa haiachi programu yoyote ya DNS ya kurekebisha, na anwani ya mwisho inabaki thabiti katika maisha yote ya rasilimali.
Gharama ni kwamba sasa unamiliki rasilimali ya resolver, uwakilishaji wake wa subnet na gharama yake, ambayo ni ya kweli hata kama kiasi cha maswali ni kidogo sana.
Chaguo B: VM ya forwarder ndani ya VNet
Muundo wa zamani huendesha programu ya DNS kwenye VM ya kawaida ndani ya VNet: Windows DNS, BIND au dnsmasq, na eneo la kibinafsi ama linapangishwa ndani au linatumwa kwa resolver ya Azure kwenye 168.63.129.16. Forwarder yenye sharti ya eneo inaelekea anwani ya kibinafsi ya VM hiyo.
Chaguo hili linajulikana kwa timu ambazo tayari zinaendesha seva za DNS, na linaweza kubeba mantiki ya ziada kama ukataji kumbukumbu au majibu ya split-horizon. Pia hurithi kila jukumu la uendeshaji la seva ya DNS: urekebishaji, nakala ya pili kwa upatikanaji, ufuatiliaji na njia ya kujenga upya wakati VM inabadilishwa na anwani yake inabadilika.
Mwenyeji wa kawaida wa VNet si proksi ya DNS hadi huduma isakinishwe na ipewe ruhusa ya kujibu wateja hao, na hiyo ni hatua ambayo watu huiruka wanapofanya nakala ya VM.
Ipi inafaa shughuli zako
Ulinganisho si kuhusu muundo upi ni wa haraka. Ni kuhusu kama unataka kusimamia programu ya DNS kabisa, na kama kiasi cha maswali kinahesabia rasilimali inayosimamiwa inayotoza kwa mwisho na kwa swali.
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
Mstari wowote utakaoamua, kanuni ya forwarder ya eneo inaonekana sawa. Hii ni sehemu ambayo lazima iwepo katika miundo yote miwili, na ni sehemu ambayo mara nyingi hukosekana mtu anaporipoti kuwa utatuzi unafanya kazi kutoka ndani ya Azure lakini si kutoka ofisini.
Kagua njia kwa mpangilio
Hakikisha eneo limeunganishwa na VNet inayoshikilia resolver, na forwarder ya eneo inataja nafasi ya majina na si kikoa cha mzazi. Forwarder ya corp.example haitalingana na cloud.corp.example isipokuwa resolver yenyewe iwakilishe, na kutokulingana huko hutoa jibu hasi safi linaloonekana kama rekodi inayokosekana.
Kisha kagua kama swali linafika kwenye mwisho: chanzo cha eneo linahitaji njia kuelekea anwani ya resolver na njia ya kurudi, na bandari 53 kwa UDP na TCP inapaswa kuruhusiwa pale sera inaporuhusu. NSG haiwezi kutoa rekodi ya eneo inayokosekana, na eneo sahihi haliwezi kujibu swali ambalo halifiki kamwe.
Wakati wa kuchunguza, weka FQDN iliyoombwa karibu na resolver uliyochagua, na tenganisha muda wa kumalizika na jibu hasi. Muda wa kumalizika ni tatizo la njia au sera. Jibu hasi linamaanisha swali lilifika na nafasi ya majina haikulingana. Mpangilio wa kazi: unganisha eneo, ongeza forwarder yenye sharti, fungua bandari 53 pande zote mbili, jaribu jina moja kutoka eneo, na kisha tu angalia idhini ya programu yenyewe.