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 আপডেট এবং পরের গেটওয়ে পরিবর্তন—সবই তখন একটি নথির সাথে তুলনা হয়ে উঠবে, আরেক দুপুরের অনুমানের বদলে।