Azure P2S DNS ناکام ہوتا ہے جب resolver جڑے ہوئے VNet میں ہو

VM کو پنگ کریں اور وہ جواب دیتا ہے؛ اس کا نام پوچھیں اور کلائنٹ کہتا ہے کہ host نامعلوم ہے۔ جب resolver VPN گیٹ وے والے نیٹ ورک میں نہیں بلکہ جڑے ہوئے مجازی نیٹ ورک میں بیٹھا ہو، تو نتائج کا یہ جوڑا متوقع ہے، اور resolver کی کوئی بھی جانچ پڑتال اسے نہیں بدلتی۔ جو غائب ہے وہ روٹنگ معاہدہ ہے جسے peering بطور طے شدہ روکے رکھتا ہے۔ دو ٹوپولوجیاں کاغذ پر تقریباً یکساں دکھتی ہیں، اور کام کرنے اور ٹوٹنے کے درمیان فرق صحیح سمت میں رکھے گئے peering سوئچز کا ایک جوڑا ہے۔

تصور کریں ایک لیپ ٹاپ VNet2 میں گیٹ وے کی طرف ٹنل کر رہا ہے، جبکہ DNS فراہم کرنے والا domain controller VNet1 میں بیٹھا ہے۔

دو ٹوپولوجیاں، ایک فرق

resolver کو گیٹ وے کے اپنے مجازی نیٹ ورک کے اندر رکھیں اور ٹنل کے اوپر آتے ہی نام حل ہو جاتا ہے۔ اس تلاش میں کوئی peering ترتیب شامل نہیں ہوتی۔

اسی resolver کو peering کے پار لے جائیں اور کلائنٹ کو اب بھی VM سے جواب ملتا ہے جبکہ نام نامعلوم رہتا ہے۔ سرٹیفکیٹ، ٹنل اور کلائنٹ تبدیل نہیں ہوئے۔ صرف ایک چیز ہلی ہے کہ resolver کہاں رہتا ہے۔ peering نے اسے اس پتے تک راستہ دیا، گیٹ وے کو وہاں ٹریفک لے جانے کا اختیار نہیں۔

پہلو A: گیٹ وے کے مالک پر گیٹ وے کی ترسیل کی اجازت دیں

peering دو مجازی نیٹ ورک جوڑتی ہے، لیکن یہ جوڑ گیٹ وے سے آنے والی ٹریفک کے لیے منتقلی نہیں، اور point-to-site درخواست بالکل اسی طرح آتی ہے۔ اس لیے VNet2 میں گیٹ وے کو ڈیزائن کی اجازت تک تلاش VNet1 کے حوالے کرنے کا اختیار نہیں۔ اجازت گیٹ وے والے نیٹ ورک کی ملکیت والی peering پر ایک سوئچ ہے۔

VNet2 سے VNet1 کی طرف peering پر Allow gateway transit مقرر کریں۔ یہ خصوصیت گیٹ وے وسائل کی نہیں، peering آبجیکٹ کی ہے، اس لیے اسے peering بلیڈ میں پڑھا اور بدلا جاتا ہے۔ پورا پہلو A یہی ہے۔

پہلو B: ساتھی پر دور دراز گیٹ ویز استعمال کریں

دوسرا نصف آئینے کا عکس ہے: VNet1 سے VNet2 کی طرف واپسی peering پر Use remote gateways فعال کریں۔ وہی پرچم دونوں سروں پر، یا صرف ایک سرے پر کھولنے سے آدھا بنا راستہ اور اصل علامت اچھوتی رہتی ہے۔ صرف VPN گیٹ وے والا نیٹ ورک ترسیل کی اجازت دیتا ہے، اور ساتھی وہ فریق ہے جو اسے استعمال کرتا ہے۔

آخری بار کھولے گئے پورٹل بلیڈ پر بھروسہ کرنے کے بجائے دونوں نیٹ ورکس پر دونوں خصوصیات پڑھیں۔

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

جوڑے کو ساتھ ساتھ دیکھنا الٹی ترتیب پکڑنے کا تیز ترین طریقہ ہے۔ گیٹ وے کی طرف AllowGatewayTransit false بتانے والی peering پیکٹ کیپچر کے بغیر پوری ناکامی بیان کر دیتی ہے۔

کلائنٹ کو اب بھی کیا ملنا چاہیے

روٹنگ ضروری ہے اور کافی نہیں، کیونکہ point-to-site پروفائل کو کلائنٹ ایسا DNS پتہ بھی دینا ہوتا ہے جو ترسیل کام کرنے پر جواب دے۔ پلیٹ فارم resolver وہ پتہ نہیں: یہ مجازی نیٹ ورک سے منسلک Azure Private DNS زونز کا جواب دیتا ہے، لیکن آپ کے اپنے ڈائریکٹری سرورز پر میزبانی شدہ زون کے لیے کچھ نہیں، اور یہی تعیناتی اسی کو استعمال کرتی ہے۔ کلائنٹ کو وہاں اشارہ کریں اور عوامی نام خوشی سے حل ہو جائیں گے جبکہ اندرونی host نامعلوم رہے گا۔

کوئی اور چیز بدلنے سے پہلے منسلک لیپ ٹاپ سے resolver سے پوچھیں۔

nslookup dc01.corp.example 10.1.0.4

وقت کا خاتمہ کہتا ہے کہ راستہ اب بھی غائب ہے۔ مستند جواب مسئلہ واپس کلائنٹ کی طرف دھکیلتا ہے، عام طور پر ایسا لاحقہ جو کبھی شامل نہیں ہوتا، اس لیے مختصر نام عوامی resolver تک سفر کرتے ہیں جو انہیں خوشی سے ناکام کرتا ہے۔

سائٹ سے سائٹ کی طرف وہی معاہدہ موازنہ کریں

ان میں سے کچھ بھی خاص طور پر لیپ ٹاپ کا نہیں۔ کلائنٹ کی جگہ سائٹ سے سائٹ کی شاخ رکھیں اور دو طرفہ شرط واپس آ جاتی ہے: شاخ سیدھا گیٹ وے نیٹ ورک میں آتی ہے، اور دو نیٹ ورک کے فاصلے پر سروس اب بھی peering کے پیچھے ہے۔

ترسیل دونوں peering پر دی جانی چاہیے، اور جو سوئچ یہ دیتا ہے وہ کلائنٹ کی قسم پر نہیں، peering پر رہتا ہے۔

گیٹ وے کو الزام دینے سے پہلے

Windows ہر اڈاپٹر کے لیے resolver کی فہرست رکھتا ہے، اس لیے گیٹ وے کو الزام دینے سے پہلے تصدیق کریں کہ ٹنل انٹرفیس کو حقیقت میں کیا ملا۔

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

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

راستہ قائم رہے گا یا نہیں، یہ دو چھوٹی شرطیں طے کرتی ہیں: پتے کی جگہیں ایک دوسرے پر نہیں چڑھ سکتیں، اور resolver کے سب نیٹ پر نیٹ ورک سیکیورٹی گروپ کو کلائنٹ پول قبول کرنا ہوگا، جو صرف ایک اور ماخذ رینج ہے۔ VM کی طرف سے مؤثر راستے کی جانچ اور کلائنٹ سے ایک براہ راست سوال کے ساتھ اسے ثابت کریں، تاکہ زون مسئلہ، لاحقہ مسئلہ یا فلٹر کبھی غائب ترسیل نہ سمجھا جائے۔