VPN پر Azure کا نجی DNS: resolver اینڈ پوائنٹ یا forwarder

مقامی نیٹ ورک کا سرور نجی پتے سے Azure VM تک پہنچتا ہے اور پھر بھی اس کا نجی ہوسٹ نام حل نہیں کر سکتا، جس کی وجہ سے لوگ ٹوٹی سرنگ ڈھونڈنے لگتے ہیں۔ سرنگ درست ہے۔ جو کمی ہے وہ DNS حد ہے: مقامی طرف کسی کو معلوم نہیں کہ کسی مخصوص Azure نجی زون کا جواب VNet کے اندر موجود resolver نے دینا ہے۔ دو ڈیزائن یہ خلا پر کرتے ہیں، اور وہ اس میں مختلف ہیں کہ آپ آخر میں کیا چلاتے ہیں، اس میں نہیں کہ سوالات کام کرتے ہیں یا نہیں۔

سرنگ سوالات لے جاتی ہے، زون کا علم نہیں

سائٹ ٹو سائٹ کنکشن پیکٹوں کو دو نیٹ ورک کے درمیان راستہ دیتا ہے۔ یہ مقامی DNS سرور کو نہیں بتاتا کہ کون سی نام کی جگہ Azure کی ہے یا کون سا پتہ جواب دے گا، اس لیے سوال یا تو انٹرنیٹ جاتا ہے اور خالی واپس آتا ہے، یا مقامی resolver سے کبھی نہیں نکلتا۔

حل کے دو نصف ہیں جنہیں آسانی سے الگ کیا جا سکتا ہے۔ ایک نصف VNet کے اندر resolver ہے جو سرنگ سے آنے والے سوالات قبول کرتا ہے۔ دوسرا نصف مقامی طرف مشروط forwarder ہے جو ٹھیک ایک نام کی جگہ اس resolver کو بھیجتا ہے۔ کوئی بھی نصف اکیلے کام نہیں کرتا۔

اس پوری وضاحت کے لیے فرض کریں کہ زون cloud.corp.example ہے، اور ہر پتے کو مثال سمجھیں۔

اختیار A: منظم اندرونی اینڈ پوائنٹ

Azure DNS Private Resolver ایک اندرونی اینڈ پوائنٹ دیتا ہے جو VNet کے باہر سے DNS سوالات قبول کرتا ہے۔ آپ اسے ایک مخصوص تفویض شدہ سب نیٹ میں تعینات کرتے ہیں، نجی زون کو اس VNet سے جوڑتے ہیں، اور وہ اندرونی پتہ نوٹ کرتے ہیں جو سروس دیتی ہے۔

پھر مقامی DNS سرور پر آپ ٹھیک نام کی جگہ کے لیے اس پتے کی طرف مشروط forwarder بناتے ہیں:

Namespace: cloud.corp.example
Forward to: 10.20.2.4

Microsoft کی ہائبرڈ DNS طریقہ کار زون لنک اور forwarder مرحلہ دونوں درج کرتی ہے۔ منظم راستہ پیچ کرنے کے لیے کوئی DNS سافٹ ویئر نہیں چھوڑتا، اور اینڈ پوائنٹ کا پتہ وسائل کی پوری عمر میں مستحکم رہتا ہے۔

قیمت یہ ہے کہ اب آپ کے پاس resolver وسیلہ، اس کی سب نیٹ تفویض اور اس کا خرچ ہے، جو سوالات کی مقدار بہت کم ہونے پر بھی حقیقی ہے۔

اختیار B: VNet کے اندر forwarder VM

پرانا ڈیزائن VNet میں ایک عام VM پر DNS سافٹ ویئر چلاتا ہے: Windows DNS، BIND یا dnsmasq، اور نجی زون یا تو مقامی طور پر میزبانی ہوتا ہے یا 168.63.129.16 پر Azure resolver کو بھیجا جاتا ہے۔ مقامی مشروط forwarder اس VM کے نجی پتے کی طرف اشارہ کرتا ہے۔

یہ اختیار ان ٹیموں کے لیے مانوس ہے جو پہلے ہی DNS سرور چلاتی ہیں، اور یہ لاگنگ یا split-horizon جوابات جیسی اضافی منطق لے جا سکتا ہے۔ یہ DNS سرور کی ہر عملی ذمہ داری بھی وراثت میں لیتا ہے: پیچنگ، دستیابی کے لیے دوسرا نمونہ، نگرانی، اور VM بدلنے اور اس کا پتہ بدلنے پر دوبارہ تعمیر کا راستہ۔

عام VNet ہوسٹ DNS پراکسی نہیں ہوتا جب تک سروس نصب نہ ہو اور ان کلائنٹس کو جواب دینے کی اجازت نہ ملے، اور VM کلون کرتے وقت لوگ یہی مرحلہ چھوڑ دیتے ہیں۔

کون آپ کے آپریشن کے لیے موزوں ہے

موازنہ اس بارے میں نہیں کہ کون سا ڈیزائن تیز ہے۔ یہ اس بارے میں ہے کہ آپ DNS سافٹ ویئر چلانا چاہتے ہیں یا نہیں، اور سوالات کی مقدار ایسے منظم وسیلے کو جائز قرار دیتی ہے یا نہیں جو اینڈ پوائنٹ اور سوال کے حساب سے بل کرتا ہے۔

کوئی بھی قطار فیصلہ کرے، مقامی forwarder قاعدہ ایک جیسا دکھتا ہے۔ یہی حصہ دونوں ڈیزائنوں میں ہونا چاہیے، اور یہی حصہ سب سے زیادہ غائب ہوتا ہے جب کوئی بتاتا ہے کہ حل Azure کے اندر سے کام کرتا ہے مگر دفتر سے نہیں۔

راستہ ترتیب سے جانچیں

تصدیق کریں کہ زون اس VNet سے منسلک ہے جس میں resolver ہے، اور مقامی forwarder والدین ڈومین نہیں بلکہ نام کی جگہ کا نام لیتا ہے۔ corp.example کے لیے forwarder cloud.corp.example سے نہیں ملے گا جب تک resolver خود تفویض نہ کرے، اور یہ عدم مطابقت ایک صاف منفی جواب دیتی ہے جو گمشدہ ریکارڈ جیسا لگتا ہے۔

پھر جانچیں کہ سوال اینڈ پوائنٹ تک پہنچتا ہے: مقامی ماخذ کو resolver پتے تک راستہ اور واپسی راستہ چاہیے، اور جہاں پالیسی اجازت دے وہاں UDP اور TCP دونوں کے لیے پورٹ 53 کھلا ہونا چاہیے۔ NSG گمشدہ زون ریکارڈ نہیں دے سکتا، اور درست زون کبھی نہ آنے والے سوال کا جواب نہیں دے سکتا۔

تشخیص کرتے وقت مانگا گیا FQDN منتخب resolver کے پاس رکھیں، اور ٹائم آؤٹ کو منفی جواب سے الگ کریں۔ ٹائم آؤٹ راستے یا پالیسی کا مسئلہ ہے۔ منفی جواب کا مطلب ہے کہ سوال پہنچا اور نام کی جگہ مطابقت نہیں رکھتی تھی۔ کام کی ترتیب: زون منسلک کریں، مشروط forwarder شامل کریں، دونوں سمتوں میں پورٹ 53 کھولیں، مقامی طرف سے ایک نام جانچیں، اور اس کے بعد ہی ایپلیکیشن کی اپنی اجازت دیکھیں۔