AnyConnect کی «کنکشن سب سسٹم شروع نہیں ہو سکا» خرابی کو درست کرنا

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

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

کچھ بھی بدلنے سے پہلے وقت پڑھیں

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

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

مرحلہ 1: تصدیق کریں کہ ایجنٹ سروس چل رہی ہے

آپ جس ونڈو پر کلک کرتے ہیں وہ صرف سامنے کا حصہ ہے؛ کام Cisco AnyConnect Secure Mobility Agent سروس میں ہوتا ہے، جو vpnagent کے طور پر رجسٹر ہے۔ اگر وہ سروس بند یا غیر فعال ہو، تو GUI کے پاس بات کرنے کے لیے کوئی نہیں ہے اور یہ بالکل یہی شروعاتی ناکامی بتاتی ہے۔ بلند PowerShell پرامپٹ سے حالت اور اسٹارٹ اپ قسم چیک کریں:

Get-Service vpnagent | Select-Object Name, Status, StartType
sc.exe qc vpnagent
net start vpnagent

پہلے ہاتھ سے مقرر کردہ اسٹارٹ اپ قسم کا احترام کرنے والا انسٹالر ہی اس کے غیر فعال ہونے کی عام وجہ ہے، اس لیے صرف Start دبانے کے بجائے StartType چیک کریں۔ اگر سروس چند سیکنڈوں میں شروع ہو کر رک جائے تو Repair کلک کرنے سے پہلے System لاگ میں Service Control Manager کی اندراجات پڑھیں:

Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"} -MaxEvents 40

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

مرحلہ 2: HTTP اسٹیک کی بتائی ہوئی آف لائن حالت صاف کریں

کلائنٹ Windows HTTP اجزاء کے ذریعے اپنا پروفائل ڈاؤن لوڈ کرتا ہے اور پالیسی کا جائزہ لیتا ہے، اس لیے صارف کی انٹرنیٹ سیٹنگز میں مقرر کردہ آف لائن جھنڈا ہر براؤزر کے صفحات لوڈ کرنے کے باوجود شروعات توڑ سکتا ہے۔ قدر براہ راست چیک کریں:

Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" -Name GlobalUserOffline

قدر 1 کا مطلب ہے کہ WinINet اسٹیک کال کرنے والوں کو بتا رہا ہے کہ مشین کا کوئی کنکشن نہیں؛ یہ حالت عام طور پر Internet Explorer کے Work Offline مینو آئٹم یا آٹومیشن اسکرپٹ سے مقرر ہوتی ہے۔ اسے واپس 0 پر مقرر کریں، سائن آؤٹ کر کے دوبارہ سائن ان کریں، اور کچھ اور بدلنے سے پہلے کنکشن دوبارہ آزمائیں۔

اگر یہ مشین آپ کو ورثے میں ملی ہے اور آپ نہیں بتا سکتے کہ جھنڈا کیوں مقرر ہوا، تو اسے ٹکٹ میں لکھیں۔ مشین پر کچھ اور نے اسے جان بوجھ کر مقرر کیا ہو گا، اور یہ اگلی لاگ آن پر واپس آئے گا۔

مرحلہ 3: ورچوئل ایڈاپٹر کو Hyper-V یا ICS سے آزاد کریں

Windows کے دو کردار وہ حصے پکڑ سکتے ہیں جو کلائنٹ کو اپنا ایڈاپٹر بنانے کے لیے درکار ہوتے ہیں۔ Hyper-V پہلا ہے: ورچوئل سوئچ کی سروسز چلنے کے دوران ایڈاپٹر بنانا اس طرح ناکام ہو سکتا ہے جو اس خرابی کے طور پر ظاہر ہو۔ سروسز بند کرنا تشخیص ہے، حل نہیں:

Get-Service vmms, vmcompute | Stop-Service
Get-NetAdapter | Where-Object InterfaceDescription -like "*Hyper-V*"

اگر کلائنٹ ان سروسز کے بند ہونے پر جڑتا ہے تو تصادم کی تصدیق ہو جاتی ہے اور اب آپ جانتے ہیں کہ Hyper-V ہوسٹ کے مالک سے کیا بات کرنی ہے۔ بعد میں انہیں دوبارہ شروع کریں، الا یہ کہ مشین کو مزید ورچوئلائزیشن کی ضرورت نہ ہو۔

انٹرنیٹ کنکشن شیئرنگ دوسرا مالک ہے۔ اگر کوئی کنکشن شیئر ہو رہا ہے تو کلائنٹ ٹنل بنانے سے پہلے ہی ناکام ہو سکتا ہے۔ Get-Service SharedAccess سے تصدیق کریں اور اگر یہ چل رہا ہے اور خودکار پر مقرر ہے تو ایڈاپٹروں میں مشترکہ کنکشن تلاش کریں اور صرف اسی ایڈاپٹر پر شیئرنگ بند کریں۔

پہلے خارج کرنے کے قابل ایک سستا توضیح بھی ہے۔ جس مشین کے پاس کوئی کام کرتا انٹرنیٹ رسائی نہیں ہوتا وہ اکثر رسائی کی خرابی کے بجائے یہ پیغام دکھاتی ہے، اس لیے کلائنٹ کو قصوروار ٹھہرانے سے پہلے تصدیق کریں کہ Test-NetConnection گیٹ وے پتے اور کسی عوامی ہوسٹ کے لیے دونوں کامیاب ہیں۔

تصدیق کریں، پھر غیر ضروری چیز واپس کریں

تصدیق کا مطلب ٹرے میں موجود سبز ڈھال نہیں ہے۔ تصدیق کریں کہ ایڈاپٹر موجود ہے، پتہ رکھتا ہے اور ٹریفک گزرنے دیتا ہے: Get-NetAdapter -Name "Cisco AnyConnect*" اسے چلتی حالت میں دکھانا چاہیے، ipconfig /all مختص کردہ پتہ اور DNS سرورز دکھانے چاہئیں، اور اندرونی نام کے لیے حقیقی درخواست مقامی ریزولور کے بجائے ٹنل سے حل ہونی چاہیے۔

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

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