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

آپ واقعی جو انتباہ دیکھتے ہیں اسی سے شروع کریں

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

ان سب کے پیچھے وجوہات کی ایک مختصر فہرست ہے: خود دستخط شدہ گیٹ وے سرٹیفکیٹ، کوئی نجی CA جس پر اینڈ پوائنٹ بھروسا نہیں کرتا، یا کوئی ہوسٹ نام جو سرٹیفکیٹ کے subject alternative names میں موجود نہیں۔ ان تینوں میں سے کوئی بھی وہی مکالمہ پیدا کرتا ہے اور مختلف درستی مانگتا ہے۔

مکالمے کا جواب دینے سے پہلے سرٹیفکیٹ پڑھیں

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

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

جانیں کہ ہر جواب ٹرسٹ اسٹور میں کیا لکھتا ہے

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

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

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

جوابات اسی ترتیب سے لکھیں جس ترتیب سے کلائنٹ پوچھتا ہے

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

connect vpn2.example.net
y
n
GROUP
LOGIN
PASSWORD

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

ایسے استثنا ہٹائیں جو اپنے گیٹ وے سے زیادہ زندہ رہیں

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

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

متعلقہ مضامین