SQL Server بوٹ کے وقت موجود نہ ہونے والے VPN پتے سے بندھ جاتا ہے

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

کلائنٹ سے نہیں، سٹارٹ اپ لاگ سے شروع کریں

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

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixOrigin
Get-Content 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\LOG\ERRORLOG' -Tail 40

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

وہ بائنڈنگ ترتیب چلیں جو انجن واقعی اپناتا ہے

انجن اپنی سننے والے کی ترتیب پڑھتا ہے، پھر آپریٹنگ سسٹم سے بائنڈ کرنے کو کہتا ہے۔ اگر اس لمحے پتہ مقامی نہیں ہے، تو اس پتے کے لیے بائنڈنگ ناکام ہو جاتی ہے جبکہ انسٹینس کا باقی حصہ معمول کے مطابق جاری رہ سکتا ہے۔ اسی لیے دوسرے پروٹوکول یا دوسرے پتے اب بھی کام کر سکتے ہیں، اور اسی لیے „SQL Server ڈاؤن ہے“ غلط خلاصہ ہے۔ لاگ سے درست آخری نقطہ محفوظ رکھیں: پتہ، پورٹ اور پروٹوکول، کیونکہ درستی کا انحصار اس پر ہے کہ تینوں میں کون غلط ہے۔

اڈاپٹر ظاہر ہونے کے بعد سروس دوبارہ شروع کرنے سے سننے والا عام طور پر کامیاب ہو جاتا ہے، اور یہی جال ہے۔ یہ انحصار کو دور کرنے کی بجائے ثابت کرتا ہے، اور ہر بار سرنگ کے دوبارہ جڑنے پر ہر منسلک صارف کو کاٹ دیتا ہے۔

سننے والے کو ویسے پڑھیں جیسے انجن پڑھتا ہے

SQL Server Configuration Manager میں انسٹینس کی TCP/IP خصوصیات کھولیں اور انفرادی پتے تبدیل کرنے سے پہلے Listen All کی ترتیب پر توجہ دیں۔ جب Listen All Yes ہو تو ہر پتے کے Enabled اقدار نظر انداز ہو جاتے ہیں، اس لیے انہیں تبدیل کرنے سے سننے والا جو استعمال کرتا ہے اس میں کچھ نہیں بدلتا۔ ترتیب سے تین چیزیں نوٹ کریں: وہ پتہ جس کی خدمت کرنا چاہتے ہیں، پورٹ، اور یہ کہ سننے والے نے تمام پتے یا صرف ایک ڈھانپنا ہے۔ پھر معاون ری اسٹارٹ طریقہ کار سے تبدیلی لاگو کریں اور اگلا سٹارٹ اپ لاگ پڑھ کر تصدیق کریں کہ انجن نے وہی باندھا جو آپ نے مانگا تھا۔

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

کلائنٹ کو مستقل منزل دیں

کلائنٹ کو ضرورت نہیں کہ ڈیٹا بیس ہوسٹ پول کا پتہ پہنے۔ روٹ شدہ ڈیزائن تب کام کرتا ہے جب سرور اپنے مستقل نجی پتے پر سنتا ہے اور VPN گیٹ وے کلائنٹ کی ٹریفک اس کی طرف بھیج کر جواب واپس لاتا ہے۔

Test-NetConnection -ComputerName 10.80.0.15 -Port 1433
tracert -d 10.80.0.15

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

کلائنٹ کے استعمال کردہ آخری نقطے کی تصدیق کریں

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

sqlcmd -S tcp:10.80.0.15,1433 -Q "SELECT local_net_address, local_tcp_port FROM sys.dm_exec_connections WHERE session_id = @@SPID"

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