Azure P2S VPN نجی اینڈ پوائنٹ کا نام حل نہیں کر سکتا

آپ point-to-site ٹنل جوڑتے ہیں، نجی پتے پر ping کرتے ہیں، ایپ کھولتے ہیں اور اس کے بجائے 403 یا سرٹیفکیٹ کی خرابی ملتی ہے۔ دونوں علامات DNS کی طرف اشارہ کرتی ہیں، لیکن یہ مختلف خرابیاں ہیں: ایک کا مطلب ہے کہ کلائنٹ نے عوامی پتہ حل کیا، دوسرے کا مطلب ہے کہ اس نے نجی پتہ حل کیا اور پھر ایسا نام پیش کیا جو سرٹیفکیٹ میں شامل نہیں۔ نیچے دی گئی جانچیں ترتیب سے کریں اور پہلی ناکامی پر رک جائیں، کیونکہ hosts اندراج یا کیش میں محفوظ جواب ہر اگلی جانچ کو غلط وجہ سے پاس کرا سکتا ہے۔ میں یہ ترتیب اپنے VPN پروفائلز کے ساتھ ایک متن فائل میں رکھتا ہوں، کیونکہ مرمت ٹنل میں کچھ نہیں بدلتی اور کلائنٹ جو جانتا ہے اس میں سب کچھ بدل دیتی ہے۔

کلائنٹ کو واقعی ملنے والے پتے سے شروع کریں

ایپ پر بھروسہ کرنے کے بجائے حل کنندہ سے براہ راست پوچھیں۔ Windows پر، nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net دکھاتا ہے کہ کلائنٹ کو کون سا منظر ملا۔ عوامی جواب کا مطلب ہے کہ آگے کچھ بھی اینڈ پوائنٹ تک نہیں پہنچے گا؛ اینڈ پوائنٹ کا نجی پتہ مطلب ہے کہ DNS مکمل ہو گیا اور اگلی جانچ خود کنکشن ہے۔

نجی اینڈ پوائنٹ سروس کا نام نہیں بدلتا۔ اکاؤنٹ یا ایپ اپنا معمول کا مکمل اہل نام رکھتا ہے، اور اینڈ پوائنٹ صرف وہ پتہ بدلتا ہے جس پر ورچوئل نیٹ ورک کے اندر کلائنٹس کے لیے یہ نام حل ہوتا ہے۔ اسی لیے وہی میزبان نام نیٹ ورک کی VM سے نجی طور پر اور ایسے لیپ ٹاپ سے عوامی طور پر حل ہوتا ہے جسے کبھی نجی منظر نہیں ملا۔

ٹنل سے پہلے زون، اس کا لنک اور ریکارڈ جانچیں

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

زون کے نام سروسز کے ہوتے ہیں، عام طور پر نجی لنکس کے نہیں۔ App Service عام طور پر privatelink.azurewebsites.net استعمال کرتا ہے، اسٹوریج اور SQL کے اپنے نام کی جگہیں ہیں، اور دوسری سروس کا زون ادھار لینے سے ایسا زون بنتا ہے جو موجود ہے مگر کوئی مفید جواب نہیں دیتا۔

کلائنٹ کو ایسا حل کنندہ دیں جس تک وہ واقعی پہنچ سکے

168.63.129.16 Azure ورچوئل مشینوں سے جواب دیتا ہے اور point-to-site ٹنل کے دوسری طرف کے لیپ ٹاپ کے لیے DNS سرور نہیں ہے۔ کلائنٹ کو ٹنل کے ذریعے قابل رسائی حل کنندہ چاہیے: Azure DNS Private Resolver کا اندرونی اینڈ پوائنٹ، ورچوئل نیٹ ورک کے اندر فارورڈر، یا VPN کلائنٹ پروفائل میں لے جانے والے DNS سرور اندراجات، تاکہ کلائنٹ ورچوئل نیٹ ورک سے براہ راست پوچھے۔

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

اگر آپ ترتیبات دھکیلنے کے بجائے فارورڈ کرتے ہیں، تو وہ نام کی جگہ فارورڈ کریں جو نجی زون کی ملکیت ہے، پورے azurewebsites.net کے بجائے privatelink.azurewebsites.net۔ جو مشروط فارورڈر پورا والدینی لاحقہ نگل جاتا ہے وہ سروس کی ہر تلاش Azure کو بھیجتا ہے، بشمول وہ جو مقامی رہنی چاہئیں۔

وہ نام استعمال کریں جس کے لیے سرٹیفکیٹ جاری ہوا

جب پتہ درست ہو تو دوسری خرابی سامنے آتی ہے۔ اسٹوریج اور App Service privatelink عرف شائع کرتے ہیں، اور وہ عرف لازماً سرٹیفکیٹ کا نام نہیں۔ privatelink.blob.core.windows.net کی طرف بھیجا گیا AzCopy اپ لوڈ توثیق میں ناکام رہا؛ وہی اپ لوڈ <account>.blob.core.windows.net/<container> کی طرف نجی پتے پر حل ہوا اور پاس ہو گیا، اس لیے یہ بغیر کسی بائی پاس کے نجی راستے پر رہا۔

یہ قاعدہ براؤزر میں اور App Service کے لیے بھی لاگو ہے: سرٹیفکیٹ کے محیط میزبان نام سے جڑیں اور DNS کو نجی پتہ فراہم کرنے دیں۔ توثیق سے بچنے کی طرف نہ جائیں، کیونکہ یہ نام رکھنے کی غلطی کو سیکیورٹی پسپائی میں بدل دیتا ہے۔ کامیاب ping راستہ ثابت کرتا ہے اور ہاتھ ملانے کے اندر کے نام کے بارے میں کچھ نہیں کہتا، اسی لیے یہ الگ جانچیں رہتی ہیں۔

ہر تہہ کو الگ کرنے والا چار قدمی ترتیب

1. تصدیق کریں کہ VPN کلائنٹ کے پاس point-to-site تالاب سے پتہ اور اینڈ پوائنٹ کے نجی پتے تک راستہ ہے۔
2. ایپ جو درست نام استعمال کرتی ہے اسے حل کریں اور جواب کا اینڈ پوائنٹ کے پتے سے موازنہ کریں۔
3. سروس پورٹ پر اینڈ پوائنٹ سے TCP کنکشن کھولیں، پھر اس کنکشن پر پیش کردہ سرٹیفکیٹ کا نام پڑھیں۔
4. ابھی اجازت جانچیں، کیونکہ کام کرنے والا راستہ اور درست سرٹیفکیٹ ابھی وسیلے تک رسائی نہیں دیتے۔

پتہ درست ہونے پر مسترد کنکشن DNS کی طرف نہیں بلکہ نیٹ ورک سیکیورٹی گروپ یا نجی اینڈ پوائنٹ کنکشن کی حالت کی طرف اشارہ کرتا ہے، اس لیے حل کنندہ کی ترتیبات دوبارہ بدلنے سے پہلے وہ جانچیں۔ TLS نام کا عدم مطابقت آپ کو URL کے میزبان نام اور سرٹیفکیٹ کے subject پر واپس بھیجتا ہے۔ حل کا نتیجہ، سرٹیفکیٹ کا نام اور درست URL اکٹھے رکھیں؛ یہ تین قدریں گیٹ وے کو چھوئے بغیر ان میں سے بیشتر صورتوں کی وضاحت کرتی ہیں۔

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

کلائنٹ بھی کیش کرتے ہیں۔ دس منٹ پہلے عوامی طور پر جواب دینے والا ریکارڈ زون درست کرنے کے بعد بھی جواب دیتا رہتا ہے، اس لیے دوبارہ جانچنے سے پہلے کیش خالی کریں۔ Windows پر، ipconfig /flushdns کلائنٹ کیش صاف کرتا ہے؛ نام حل کرنے کی پالیسی کے قواعد باقی رہتے ہیں، طے کرتے ہیں کہ کون سا لاحقہ کس سرور پر جائے گا، اور نام کی جگہ اس حل کنندہ کو بھیجتے رہ سکتے ہیں جو آپ نے ابھی بدلا۔

hosts اندراج کہاں ہونا چاہیے

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

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

مختصر ناموں کو تلاش کا لاحقہ درکار ہوتا ہے اور مکمل اہل ناموں کو نہیں، اس لیے پہلے مکمل اہل نام جانچیں، پھر فیصلہ کریں کہ ورک فلو کو کلائنٹ پروفائل کے ذریعے دھکیلا گیا لاحقہ درکار ہے یا نہیں۔ Microsoft اپنے نجی اینڈ پوائنٹ DNS رہنمائی میں ہر سروس کے لیے زون کے نام اور ریکارڈ کی شکلیں دستاویز کرتا ہے؛ دوسری سروس سے زون نقل کرنے کے بجائے اپنی سروس کا اندراج پڑھیں۔