vpnc بمقابلہ Check Point یا Nortel: یہ کیوں رکتا ہے

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

پروفائل کا کوئی اور خانہ ترمیم کرنے سے پہلے مصنوعات کی شناخت کریں۔

ناکامی غلط اسناد جیسی دکھتی ہے

vpnc UDP 500 پر IKE بھیج کر شروع ہوتا ہے اور اگر NAT ٹراورسل پیش کیا جائے تو UDP 4500 پر بھی۔ جو گیٹ وے IPsec کی بجائے SSL ختم کرتا ہے وہ دونوں میں سے کسی کا جواب نہیں دیتا، اس لیے کلائنٹ دوبارہ کوشش کرتا ہے اور آخر میں عام خرابی کے ساتھ ہار مان لیتا ہے۔ اگر وہی اکاؤنٹ چھوٹی مددگار ایپ لوڈ کرنے والے براؤزر پورٹل سے کام کرتا ہے، تو یہ مضبوط اشارہ ہے کہ سرنگ SSL پر مبنی ہے اور کلائنٹ غلط سوال پوچھ رہا ہے۔

یہاں ناکام کوشش صارف کے اکاؤنٹ کے بارے میں کچھ نہیں کہتی، کیونکہ گیٹ وے کے سامنے کبھی کوئی اسناد پیش نہیں کی گئیں۔

جانچیں کہ گیٹ وے کون سا پروٹوکول پیش کرتا ہے

دو منٹ کی جانچ IPsec ساتھی کو SSL پورٹل سے الگ کرتی ہے۔ انہیں اسی نیٹ ورک سے چلائیں جو کلائنٹ استعمال کرے گا، اور پڑھیں کہ کون سی پورٹیں جواب دیتی ہیں، نہ کہ کون سی کسی دستاویز میں درج ہیں۔ نتیجہ رکھیں، کیونکہ وہی پورٹیں طے کرتی ہیں کہ گیٹ وے کے مالک کو کون سا کلائنٹ سپورٹ کرنا چاہیے۔ گیٹ وے کے پاس والے ہوسٹ سے نہیں، کلائنٹ نیٹ ورک سے جانچ کریں۔

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

لاگ ان صفحے پر ری ڈائریکٹ کے ساتھ کھلی 443 اور 500 و 4500 پر خاموشی SSL VPN کی طرف اشارہ کرتی ہے۔ 443 پر فراہم کردہ سرٹیفکیٹ کے ساتھ 500 اور 4500 کھلی ہوں تو یہ ایسے IPsec گیٹ وے کی نشاندہی کرتا ہے جو ویب فرنٹ اینڈ بھی چلاتا ہے، اور vpnc اسی صورت کے لیے بنایا گیا تھا۔

Check Point کا SSL Network Extender اور Nortel کا Aventail کلائنٹ دونوں دوسری قسم میں آتے ہیں، اور ان میں سے کوئی بھی IKEv1 گروپ راز قبول نہیں کرتا۔

vpnc پروفائل کیا ظاہر کر سکتا ہے اور کیا نہیں

اندر سے vpnc گروپ کی پیشگی مشترکہ کلید کے خلاف IKEv1 چلاتا ہے، پھر XAuth کے ذریعے انفرادی صارف کی اسناد بھیجتا ہے۔ اس کی کنفیگریشن فائل میں سب کچھ اسی تبادلے کا ہے: گیٹ وے، گروپ کا نام، گروپ راز، صارف نام اور صارف پاس ورڈ۔ یہ خانے ایک ہی پروٹوکول بیان کرتے ہیں، اور ان کا کوئی امتزاج کلائنٹ کو دوسرا بولنے پر مجبور نہیں کر سکتا۔

اسی لیے سائفر فہرست وسیع کرنا یا سرٹیفکیٹ جانچ بند کرنا اس قسم کی ناکامی کبھی درست نہیں کرتا۔ وہ تبدیلیاں ایسے مذاکرات کو کمزور کرتی ہیں جنہیں گیٹ وے سن نہیں رہا۔

گیٹ وے سے میل کھانے والا کلائنٹ منتخب کرنا

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

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

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