Android VPN سے Cisco IOS تک: پہلے حاصل کرنے والا معاہدہ
Cisco IOS گیٹ وے کے لیے Android کلائنٹ نصب کرنے سے پہلے پروٹوکول، تصدیق، شناخت اور روٹنگ جمع کریں۔ اس مرحلے کے لیے رہنما۔
فون کو Cisco گیٹ وے تک پہنچنا ہے۔ کسی نے پہلے ہی بتا دیا ہے کہ کون سا کلائنٹ نصب کرنا ہے۔ یہ عمل کا غلط سرا ہے، اور اسی لیے ایک گھنٹے تک اسناد دوبارہ ٹائپ کرنے کے بعد ٹنل ناکام ہوتا ہے۔
سب سے پہلے آپ کو کنکشن معاہدہ چاہیے: پروٹوکول، تصدیق، شناخت، اعتماد کا مواد، پتوں کی تقسیم اور روٹنگ، جو گیٹ وے چلانے والا لکھے۔
یہ تحریری شکل میں مل جائے تو کلائنٹ کا انتخاب محض تلاش بن جاتا ہے۔ نظر انداز کریں تو ہر ناکامی غلط پاس ورڈ جیسی لگتی ہے۔
کچھ بھی نصب کرنے سے پہلے معلومات جمع کریں
گیٹ وے کے مالک کو فہرست بھیجیں اور جواب طلب کریں، مصنوعات کا نام نہیں۔ نو نکات ریموٹ رسائی پروفائل کو مکمل طور پر ڈھانپتے ہیں:
- گیٹ وے کا ہوسٹ نام یا پتہ جس پر کلائنٹ کال کرے، اور آیا باہر سے قابل رسائی ہے۔
- پروٹوکول اور ورژن: IKEv2، IPsec کی کوئی اور نسل، یا TLS پر مبنی خدمت۔
- وہ ہم منصب شناخت جس کی گیٹ وے توقع کرتا ہے، اور وہ خود بدلے میں کیا پیش کرتا ہے۔
- اعتماد کا مواد: کون سی CA گیٹ وے کے سرٹیفکیٹ پر دستخط کرتی ہے، یا پہلے سے مشترک کلید استعمال ہوتی ہے۔
- صارف کی تصدیق: سرٹیفکیٹ، EAP صارف نام اور پاس ورڈ، یا پہلے سے مشترک کلید۔
- وہ پتہ پول جس میں کلائنٹ اترتا ہے، ماسک اور گیٹ وے کے ساتھ۔
- ٹنل کے اندر استعمال ہونے والے DNS سرورز، اور کیا کلائنٹ کو انہیں قبول کرنا ہے۔
- اجازت شدہ منزل کے سابقے، اور کیا ان سے باہر کی ٹریفک روکنی ہے۔
- معاونت یافتہ کلائنٹ ورژن اور فون کے آپریٹنگ سسٹم کے ورژن، نیز کوئی اندراج کی شرط۔
ان میں سے دو نکات سب سے زیادہ قابل گریز ناکامیوں کا سبب بنتے ہیں۔ اعتماد کے مواد کے بغیر آپ گیٹ وے کی تصدیق نہیں کر سکتے، اس لیے درست کلائنٹ بھی خراب دکھتا ہے۔ اجازت شدہ سابقوں کے بغیر آپ روٹنگ کی پابندی کو خدمت کے مسئلے سے الگ نہیں کر سکتے۔
فروش کا نام پروٹوکول نہیں ہے
Cisco IOS اور IOS XE ریموٹ رسائی کے کئی انتظامات پیش کرتے ہیں، اور وہ ایک ہی وائر فارمیٹ مشترک نہیں رکھتے۔ FlexVPN طرز کی پروفائل کے ساتھ IKEv2 پرانی IKEv1 ترتیب جیسی خدمت نہیں ہے، اور TLS پر مبنی کلائنٹ خدمت پھر ایک اور مصنوعات ہے، اکثر اسی ماحول میں کسی دوسرے پلیٹ فارم پر۔
اس لیے جس کلائنٹ کے نام میں راؤٹر فروش کا ذکر ہے وہ کچھ ثابت نہیں کرتا۔ یہ ان خدمات میں سے ایک کو اچھی طرح نافذ کر سکتا ہے اور باقی کوئی نہیں۔ پوچھیں کون سی خدمت ترتیب دی گئی ہے، پھر دیکھیں کہ کلائنٹ کی دستاویزات اس خدمت کو معاونت یافتہ بتاتی ہیں یا نہیں۔
Cisco کی اپنی IKEv2 دستاویزات تجویز، پالیسی، پروفائل اور کلید کے حلقے کو الگ اشیاء کے طور پر تقسیم کرتی ہیں۔ یہ ڈھانچہ تب مفید ہے جب آپ کوئی ترتیب پڑھتے ہیں جو کوئی آپ کو چپکا دیتا ہے: یہ بتاتا ہے کہ کون سی شے دور کے فون کے لیے اہم ترتیبات رکھتی ہے، بجائے اس کے کہ پوری فائل کو ایک ڈھیر سمجھا جائے۔
Android کا اندرونی اسٹیک کیا ڈھانپتا ہے
Android پلیٹ فارم کی IKEv2/IPsec پروفائل Ikev2VpnProfile کے ذریعے فراہم کرتا ہے، پہلے سے مشترک کلید، RSA سرٹیفکیٹ اور EAP صارف نام و پاس ورڈ کے لیے الگ تصدیق کی اقسام کے ساتھ۔ Ikev2VpnProfile حوالہ اس بات کا مستند ماخذ ہے کہ بلڈر کیا قبول کرتا ہے، جس میں گیٹ وے کا ہوسٹ نام اور اسے تصدیق کرنے کے لیے استعمال ہونے والا سرور روٹ CA شامل ہے۔
وہ API صلاحیت کا بیان ہے، مطابقت کا وعدہ نہیں۔ یہ کہتا ہے کہ پلیٹ فارم ان تصدیق کی اقسام کے ساتھ IKEv2 کر سکتا ہے۔ یہ نہیں کہتا کہ کوئی مخصوص OEM سیٹنگز اسکرین ہر فیلڈ دکھاتی ہے، یا کسی دوسری مصنوعات سے برآمد شدہ پروفائل فائل درآمد ہوگی۔
اس کا مطلب یہ بھی ہے کہ اگر گیٹ وے ایسی خدمت چلا رہا ہو جو پلیٹ فارم نافذ نہیں کرتا تو اندرونی اسٹیک آپ کو نہیں بچائے گا۔ اس صورت میں آپریٹر کی معاونت یافتہ فروش کلائنٹ درکار ہے، آپریٹر کی دستاویزات کے مطابق نصب اور ترتیب دیا گیا، نہ کہ ایسے پروٹوکول پر بنایا گیا کوئی حل جو فون بولتا نہیں۔
معاہدہ جس ترتیب سے لکھا گیا ہے اسی ترتیب سے جانچیں
ایک وقت میں ایک پرت کی تصدیق کریں اور پہلی ناکامی پر رک جائیں، کیونکہ جب تک پہلے والے کامیاب نہ ہوں بعد کے امتحان بے معنی ہیں۔
اعتماد۔ اگر کلائنٹ گیٹ وے کا سرٹیفکیٹ مسترد کر دے تو باقی کچھ اہم نہیں۔ تصدیق کریں کہ آپ کو دی گئی CA گیٹ وے کے پیش کردہ سرٹیفکیٹ پر دستخط کرتی ہے، اور آپ نے جس ہوسٹ نام کو کال کیا وہ اس میں موجود ہے۔ تصدیق کو آن رکھیں؛ اسے بند کرنا شناخت کے مسئلے کو روکنے کے خطرے میں بدل دیتا ہے۔
تصدیق۔ مسترد شدہ اسناد اور غیر مطابق تجویز مختلف غلطیاں مگر ایک جیسی دکھنے والی ناکامیاں دیتے ہیں۔ گیٹ وے کا لاگ فیصلہ کن ہے: صارف کے بارے میں کچھ کہنے سے پہلے یہ بتائے گا کہ تجویز قابل قبول تھی یا نہیں۔
پتہ اور DNS۔ تصدیق کریں کہ فون نے دستاویزی پول سے پتہ حاصل کیا، پھر ایک داخلی نام حل کریں۔ پتے کے ساتھ مگر ریزولور کے بغیر اٹھنے والا ٹنل جڑا ہوا دکھتا ہے اور ایسا برتاؤ کرتا ہے جیسے کچھ کام نہ کر رہا ہو۔
رسائی۔ ایک اجازت شدہ منزل کو پتے سے، پھر نام سے جانچیں۔ پتہ چلے اور نام نہ چلے تو آپ پھر DNS پر ہیں۔ دونوں نہ چلیں تو کلائنٹ کو چھونے سے پہلے جانچے جانے والے سابقے کا اجازت شدہ فہرست سے موازنہ کریں۔
ناکامی کے انداز اور رول بیک
| Symptom | Contract item to re-check |
|---|---|
| Profile rejected at import | Protocol or client release unsupported for that service |
| No proposal chosen | IKE version or encryption proposal mismatch |
| Certificate error, correct credentials | Trust material or peer identity |
| Tunnel up, no address | Address pool or authorization on the gateway |
| Tunnel up, names fail | DNS servers or split-tunnel DNS behaviour |
کچھ بھی بدلنے سے پہلے پچھلی کارآمد پروفائل برآمد شدہ اور دستاویزی رکھیں، CA کا عرفی نام اور پتہ پول بھی شامل۔ پھر رول بیک کا مطلب معلوم پروفائل بحال کرنا ہے، خلل کے دوران یادداشت سے اسے دوبارہ بنانا نہیں۔
جب یہ چلے، تو پروفائل کے پاس نو جمع شدہ جوابات لکھ لیں۔ اگلا فون، اگلی OS تازہ کاری اور اگلی گیٹ وے تبدیلی سب دستاویز سے موازنہ بن جاتے ہیں، ایک اور دوپہر کے اندازے کی بجائے۔