GVC Acquiring IP پر رکا ہوا ہے: یہ پاس ورڈ کا مسئلہ نہیں

Global VPN Client Acquiring IP پر رکتا ہے، اور پہلا ردِعمل پاس ورڈ دوبارہ لکھنا یا کلائنٹ کو دوبارہ نصب کرنا ہوتا ہے۔ دونوں میں سے کوئی بھی اُس مرحلے کو نہیں چھوتا جو ناکام ہوا۔ تصدیق کلائنٹ کے پتہ مانگنے سے پہلے ہی مکمل ہو چکی تھی، اس لیے اُس سطر پر آپ کو روکنے والی چیز اسناد نہیں ہیں۔ آپ کو وہاں روکنے والی چیز ادھورا DHCP تبادلہ ہے، اور یہ تین مختلف جگہوں پر رک سکتا ہے۔

تصدیق اور پتہ تفویض الگ الگ مراحل ہیں

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

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

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

لیز دراصل کہاں سے آتی ہے

دو ماڈل عام ہیں۔ فائر وال خود VPN کلائنٹس کے لیے DHCP دائرہ چلا سکتا ہے، یا درخواست اندرونی نیٹ ورک کے بیرونی DHCP سرور کو بھیج سکتا ہے۔ ماڈل ہی طے کرتا ہے کہ کون سے لاگز اہم ہیں اور کس سے رابطہ کرنا ہے۔

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

کچھ بھی جانچنے سے پہلے لکھیں کہ آپ کی تعیناتی کون سا ماڈل استعمال کرتی ہے۔ آن لائن متضاد مشوروں میں سے نصف دوسرے کو فرض کرتی ہے۔

ٹنل قائم ہو اور پھر بھی لیز گر سکتی ہے

قائم شدہ کنٹرول کنکشن ثابت کرتا ہے کہ مذاکرات کامیاب ہوئے، یہ نہیں کہ ٹنل کا ڈیٹا دونوں سمتوں میں گزرتا ہے۔ DHCP تبادلے کو ڈیٹا راستہ عبور کرنے کے لیے درخواست اور جواب چاہیے، اور وہیں انکرپشن ترتیبات، VPN زون کی پالیسی اور MTU مسائل رہتے ہیں۔

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

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

لیز کا راستہ ترتیب سے چلیں

اڈاپٹر سے شروع کریں اور باہر کی طرف جائیں، تاکہ ہر قدم صرف ایک وجہ سے ناکام ہو سکے:

> Get-NetAdapter | Where-Object Name -like "*GVC*"
> ipconfig /all | findstr /i /c:"GVC" /c:"IPv4" /c:"DHCP"
> Test-NetConnection 10.60.0.1 -Port 443

169.254.x.x جیسا پتہ یعنی اڈاپٹر موجود ہے اور اسے کوئی جواب نہیں ملا، جو لیز کے منبع یا ڈیٹا راستے کی طرف اشارہ کرتا ہے۔ VPN رینج میں درست پتہ مگر غلط DNS اندراجات ایک اور خرابی ہے: لیز کام کر گئی اور پالیسی نے ادھوری ترتیبات دیں۔ جو اڈاپٹر کبھی ظاہر نہ ہو اس کا مطلب ہے کہ کلائنٹ اسے بنانے تک نہیں پہنچا۔

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

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