نجی اینڈ پوائنٹ، وہی سرور نام: Azure SQL کنکشن اسٹرنگز

Private Link بدلتا ہے کہ کنکشن کہاں پہنچتا ہے، یہ نہیں کہ کنکشن کا نام کیا ہے۔ Azure SQL Database کے لیے یہی فرق پورا ڈیزائن ہے: منطقی سرور اپنا نام رکھتا ہے، اور نجی اینڈ پوائنٹ ایک نیٹ ورک اندراج دیتا ہے جس میں نام حل ہوتا ہے۔ نام کو IP پتے سے بدلنا وہ واحد تبدیلی ہے جو TLS، اسناد اور اوزار ایک ساتھ توڑتی ہے۔ دو کنکشن اسٹرنگز یکساں دکھ سکتی ہیں اور بالکل مختلف برتاؤ کر سکتی ہیں۔

orders-db.database.windows.net رکھیں اور کلائنٹ کو اس کے لیے نجی جواب دیں۔

نام اور پتے کے کام مختلف ہیں

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

Azure SQL کے لیے Microsoft کی رہنمائی کلائنٹس سے عام سرور نام مانگتی ہے۔ براہِ راست IP، اور اسی طرح privatelink سابقے والا نام، قابلِ تبادلہ لاگ اِن ہدف نہیں ہے۔ IP قبول کرنے والے اوزار اسے قبول کریں گے اور پھر TLS پر یا تصدیق پر ناکام ہوں گے، جو اصل غلطی چھپاتا ہے۔ وہ ناکامیاں اسناد کے مسائل کی طرح پڑھی جاتی ہیں جب تک آپ خرابی میں ہوسٹ نام نہ دیکھیں۔

نجی زون واقعی کیا بدلتا ہے

نجی DNS زون privatelink نام کی جگہ کے اندر سرور کے لیے ایک پتہ درج کرتا ہے، اور زون اس ورچوئل نیٹ ورک سے منسلک ہے جسے اسے استعمال کرنا چاہیے۔ حل ہونا حرکت کرتا ہے؛ کنکشن اسٹرنگ نہیں۔ نیچے دی گئی شکل ایک مثال ہے، عوامی زون میں چپکانے والا اندراج نہیں۔

Application name:        orders-db.database.windows.net
Private DNS zone:        privatelink.database.windows.net
Resolved private entry:  the approved private endpoint address

اس اندراج اور اس کے زون لنک کو مالک اور جائزے کی تاریخ کے ساتھ بنیادی ڈھانچے کے طور پر برقرار رکھیں۔

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

Azure سے باہر کے کلائنٹس کو اس زون تک راستہ چاہیے

VPN کلائنٹ Azure کے حل کنندہ سے باہر بیٹھتا ہے، اس لیے نجی زون ہائبرڈ راستے سے قابلِ رسائی ہونا چاہیے۔ Azure DNS فارورڈر یا Azure DNS Private Resolver اس نیٹ ورک سے آنے والی استفسارات کی خدمت کر سکتا ہے۔ Microsoft کی رہنمائی یہ ہے کہ متعلقہ عوامی سروس زون کو اس ترتیب سے فارورڈ کریں، بجائے یہ فرض کرنے کہ کلائنٹ براہِ راست privatelink نام پوچھتے ہیں۔ جو کلائنٹ نجی جواب حل نہیں کر سکتے وہ بغیر شکایت عوامی جواب پر واپس آ جاتے ہیں۔

فارورڈنگ کا دائرہ جان بوجھ کر رکھیں، کیونکہ زیرِ استعمال عوامی زون کو بدلنا وہ نام توڑتا ہے جو متبادل میں نہیں ہیں۔

شناخت کو مستقل رکھنے والے ترتیب میں مہیا کریں

اقدامات کے الگ مالک ہیں: اینڈ پوائنٹ بنائیں اور منظور کریں، VPN راستہ دیں، نجی DNS یکجا کریں، پھر کلائنٹ کو اس کے عام سرور نام کے ساتھ تشکیل دیں۔ راستے سے پہلے DNS کرنے سے وقتی حدیں بنتی ہیں جو DNS ناکامیوں جیسی لگتی ہیں۔ کلائنٹ کو آخر میں کرنے سے ایک وقت میں ایک متغیر حرکت میں رہتا ہے۔ ہر قدم کا قابلِ مشاہدہ نتیجہ ہے، اس لیے کسی کو اندازے سے جانچنا نہیں پڑتا۔

منسلک VPN آئیکن خود سے نجی منزل نہیں چنتا۔

نجی اینڈ پوائنٹ کیا بند نہیں کرتا

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

یہ بھی جانچیں کہ سرور کون سی کنکشن پالیسی استعمال کرتا ہے۔

Redirect ابتدائی گیٹ وے کنکشن کے بعد کلائنٹ کو نوڈ کے پورٹ پر بھیجتا ہے، جو بدلتا ہے کہ کلائنٹ نیٹ ورک کو کیا اجازت دینی چاہیے۔ Proxy ٹریفک گیٹ وے پر رکھتا ہے۔ ایک پورٹ پر کامیاب TCP مصافحہ پورا لاگ اِن ورک فلو نہیں ہے۔

یہ Azure SQL Database ہے، SQL Managed Instance نہیں، جس کا اپنا کنیکٹیویٹی ماڈل ہے اور کوئی مساوی نجی اینڈ پوائنٹ کہانی نہیں۔ دونوں صورتوں میں تین چیزیں الگ لیبل رکھیں: نام، نیٹ ورک اندراج اور اسناد۔ کنکشن کہاں سفر کرتا ہے یہ بدلنا کبھی نہیں بدلنا چاہیے کہ کلائنٹ کس سروس سے بات کر رہا ہے۔