VPN પર Azure ખાનગી DNS: રિઝોલ્વર એન્ડપોઇન્ટ કે ફોરવર્ડર
બંને ડિઝાઇન ટનલ દ્વારા ખાનગી ઝોનનો જવાબ આપે છે. સંચાલિત ઇનબાઉન્ડ એન્ડપોઇન્ટની ફોરવર્ડર VM સાથે સરખામણી કરો, પછી બંને સ્થિતિમાં હોવો જોઈતો માર્ગ તપાસો.
ઓન-પ્રેમિસનું સર્વર ખાનગી સરનામા દ્વારા Azure VM સુધી પહોંચે છે અને તેમ છતાં તેનું ખાનગી હોસ્ટનામ રિઝોલ્વ કરી શકતું નથી, જે લોકોને તૂટેલી ટનલ શોધવા માટે મોકલે છે. ટનલ ઠીક છે. જે ખૂટે છે તે DNS સીમા છે: ઓન-પ્રેમિસની બાજુએ કોઈને ખબર નથી કે ચોક્કસ Azure ખાનગી ઝોનનો જવાબ VNet ની અંદરના રિઝોલ્વરે આપવો જોઈએ. બે ડિઝાઇન એ ખાલી જગ્યા ભરે છે, અને તે અલગ પડે છે તમે અંતે શું સંચાલિત કરો છો તેમાં, નહીં કે ક્વેરી કામ કરે છે કે નહીં તેમાં.
ટનલ ક્વેરી લઈ જાય છે, ઝોનનું જ્ઞાન નહીં
સાઇટ-ટુ-સાઇટ કનેક્શન પેકેટને બે નેટવર્ક વચ્ચે માર્ગ આપે છે. તે ઓન-પ્રેમિસ DNS સર્વરને કહેતું નથી કે કઈ નામાવલી Azure ની છે અથવા કયા સરનામાએ જવાબ આપવો જોઈએ, તેથી ક્વેરી ક્યાં તો ઇન્ટરનેટ પર જાય છે અને ખાલી પાછી આવે છે, અથવા સ્થાનિક રિઝોલ્વર ક્યારેય છોડતી નથી.
ઉપાયના બે અર્ધ છે જે સરળતાથી અલગ કરી શકાય. એક અર્ધ VNet ની અંદરનું રિઝોલ્વર છે જે ટનલ દ્વારા આવતી ક્વેરી સ્વીકારે છે. બીજું અર્ધ ઓન-પ્રેમિસ બાજુએ શરતી ફોરવર્ડર છે જે બરાબર એક નામાવલી તે રિઝોલ્વરને મોકલે છે. કોઈ પણ અર્ધ એકલું કામ કરતું નથી.
આખા વર્ણન માટે ધારો કે ઝોન cloud.corp.example છે, અને દરેક સરનામાને ઉદાહરણ તરીકે ગણો.
વિકલ્પ A: સંચાલિત ઇનબાઉન્ડ એન્ડપોઇન્ટ
Azure DNS Private Resolver એ ઇનબાઉન્ડ એન્ડપોઇન્ટ પ્રદાન કરે છે જે VNet ની બહારથી DNS ક્વેરી સ્વીકારે છે. તમે તેને સમર્પિત પ્રતિનિધિ સબનેટમાં તૈનાત કરો છો, ખાનગી ઝોનને તે VNet સાથે લિંક કરો છો અને સેવા જે ઇનબાઉન્ડ સરનામું સોંપે છે તે નોંધો છો.
પછી ઓન-પ્રેમિસ DNS સર્વર પર તમે ચોક્કસ નામાવલી માટે તે સરનામા તરફ શરતી ફોરવર્ડર બનાવો છો:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft ની હાઇબ્રિડ DNS પ્રક્રિયા ઝોન લિંક અને ફોરવર્ડર પગલું બંનેનું દસ્તાવેજીકરણ કરે છે. સંચાલિત માર્ગ તમને પેચ કરવા જેવું કોઈ DNS સોફ્ટવેર છોડતું નથી, અને એન્ડપોઇન્ટ સરનામું સંસાધનના આખા આયુષ્ય દરમિયાન સ્થિર રહે છે.
કિંમત એ છે કે હવે તમારી પાસે રિઝોલ્વર સંસાધન, તેનું સબનેટ પ્રતિનિધિત્વ અને તેનો ખર્ચ છે, જે ક્વેરીનું પ્રમાણ બહુ ઓછું હોય ત્યારે પણ વાસ્તવિક છે.
વિકલ્પ B: VNet ની અંદર ફોરવર્ડર VM
જૂની ડિઝાઇન VNet માં સામાન્ય VM પર DNS સોફ્ટવેર ચલાવે છે: Windows DNS, BIND અથવા dnsmasq, ખાનગી ઝોન સ્થાનિક રીતે હોસ્ટ થાય છે અથવા 168.63.129.16 પરના Azure રિઝોલ્વર પર ફોરવર્ડ થાય છે. ઓન-પ્રેમિસ શરતી ફોરવર્ડર તે VM ના ખાનગી સરનામા તરફ નિર્દેશ કરે છે.
આ વિકલ્પ જે ટીમો પહેલેથી DNS સર્વર ચલાવે છે તેમને પરિચિત છે, અને તે લોગિંગ કે સ્પ્લિટ-હોરાઇઝન જવાબો જેવી વધારાની લોજિક લઈ શકે છે. તે DNS સર્વરની દરેક કાર્યાત્મક જવાબદારી પણ વારસામાં લે છે: પેચિંગ, ઉપલબ્ધતા માટે બીજું ઇન્સ્ટન્સ, મોનિટરિંગ અને VM બદલાય તથા તેનું સરનામું બદલાય ત્યારે પુનર્નિર્માણનો માર્ગ.
સામાન્ય VNet હોસ્ટ DNS પ્રોક્સી નથી જ્યાં સુધી સેવા ઇન્સ્ટોલ ન થાય અને તે ક્લાયન્ટને જવાબ આપવાની પરવાનગી ન મળે, અને VM ક્લોન કરતી વખતે લોકો આ પગલું જ છોડી દે છે.
કઈ તમારા સંચાલનને અનુકૂળ છે
સરખામણી એ નથી કે કઈ ડિઝાઇન ઝડપી છે. તે એ છે કે તમે ખરેખર DNS સોફ્ટવેર ચલાવવા માંગો છો કે નહીં, અને ક્વેરીનું પ્રમાણ એવા સંચાલિત સંસાધનને ન્યાયી ઠેરવે છે કે નહીં જે એન્ડપોઇન્ટ અને ક્વેરી પ્રમાણે બિલ કરે છે.
| 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 |
કોઈ પણ પંક્તિ નિર્ણય લે, ઓન-પ્રેમિસ ફોરવર્ડર નિયમ એકસરખો દેખાય છે. આ ભાગ બંને ડિઝાઇનમાં હોવો જ જોઈએ, અને જ્યારે કોઈ જાણ કરે છે કે રિઝોલ્યુશન Azure ની અંદરથી કામ કરે છે પણ ઓફિસથી નહીં, ત્યારે આ ભાગ જ સૌથી વધુ ખૂટે છે.
માર્ગ ક્રમમાં તપાસો
ખાતરી કરો કે ઝોન રિઝોલ્વર ધરાવતા VNet સાથે લિંક થયેલી છે, અને ઓન-પ્રેમિસ ફોરવર્ડર પિતૃ ડોમેન નહીં પણ નામાવલીનું નામ આપે છે. corp.example માટેનું ફોરવર્ડર cloud.corp.example સાથે મેળ ખાશે નહીં જ્યાં સુધી રિઝોલ્વર પોતે પ્રતિનિધિત્વ ન કરે, અને આ અસંગતિ સ્વચ્છ નકારાત્મક જવાબ આપે છે જે ખૂટતા રેકોર્ડ જેવો દેખાય છે.
પછી તપાસો કે ક્વેરી એન્ડપોઇન્ટ સુધી પહોંચે છે: ઓન-પ્રેમિસ સ્રોતને રિઝોલ્વર સરનામા સુધીનો માર્ગ અને પરત માર્ગ જોઈએ, અને જ્યાં નીતિ પરવાનગી આપે ત્યાં UDP અને TCP બંને પોર્ટ 53 ખુલ્લા હોવા જોઈએ. NSG ખૂટતું ઝોન રેકોર્ડ આપી શકતું નથી, અને સાચી ઝોન ક્યારેય ન આવતી ક્વેરીનો જવાબ આપી શકતી નથી.
ડાયગ્નોસ કરતી વખતે માંગેલું FQDN પસંદ કરેલા રિઝોલ્વરની બાજુમાં રાખો, અને ટાઇમઆઉટને નકારાત્મક જવાબથી અલગ કરો. ટાઇમઆઉટ માર્ગ કે નીતિની સમસ્યા છે. નકારાત્મક જવાબનો અર્થ છે કે ક્વેરી પહોંચી અને નામાવલી મેળ ખાઈ નહીં. કામનો ક્રમ: ઝોન લિંક કરો, શરતી ફોરવર્ડર ઉમેરો, બંને દિશામાં પોર્ટ 53 ખોલો, ઓન-પ્રેમિસથી એક નામ ચકાસો, અને પછી જ એપ્લિકેશનની પોતાની અધિકૃતિ જુઓ.