আপনি সেটিংসে একটি IKEv2 কনফিগারেশন যোগ করছেন, আর দুটি ফিল্ড এমন টেক্সট চাইছে যা কেউ আপনাকে দেয়নি: Remote ID এবং Local ID। এর কোনোটিই আপনার ব্যবহারকারীর নাম নয়, কোনোটিই Server ফিল্ডের দ্বিতীয় কপি নয়। Remote ID হলো সেই পরিচয় যা গেটওয়েকে আপনার iPhone-এর কাছে প্রমাণ করতে হয়; Local ID হলো সেই পরিচয় যা আপনার iPhone গেটওয়ের কাছে দাবি করে। এর যেকোনোটি ভুল হলে সার্ভার উত্তর দেওয়ার পরেই টানেল মরে যায়, তাই ব্যর্থতাটি পাসওয়ার্ডের সমস্যার মতো দেখায়, কিন্তু তা নয়।

iOS-এ ফিল্ডগুলো কোথায় থাকে

সেটিংস > সাধারণ > VPN ও ডিভাইস ম্যানেজমেন্ট > VPN খুলে একটি IKEv2 কনফিগারেশন যোগ করুন। প্রমাণীকরণের অধীনে আপনি ব্যবহারকারীর নাম বা সার্টিফিকেট বেছে নেন, তারপরেই Remote ID এবং Local ID ফ্রি-টেক্সট বাক্স হিসেবে দেখা যায়। এগুলো শনাক্তকারী, ঠিকানা নয়: iOS এগুলো IKE_AUTH বিনিময়ে বহন করে, যেখানে IKEv2 ইনিশিয়েটরের পরিচয়কে IDi এবং রেসপন্ডারের পরিচয়কে IDr বলে।

সেভ করার পর iOS কনফিগারেশনটি একটি সারিতে ভাঁজ করে এবং মানগুলো দেখানো বন্ধ করে। ফিল্ডগুলো খালি বলে সিদ্ধান্তে আসার আগে তথ্য বোতামে চাপ দিন বা প্রোফাইলটি আবার খুলুন। MDM থেকে পাঠানো কনফিগারেশন সেগুলোকে সম্পূর্ণ ধূসর করে দিতে পারে, যা বদলে দেয় কে সমস্যাটি ঠিক করতে পারবে।

Remote ID হলো গেটওয়ের নাম

এটি সেই মান যা সার্ভারকে প্রমাণ করতে হবে বলে আপনার iPhone আশা করে। সার্টিফিকেট প্রমাণীকরণে এটি সার্ভার সার্টিফিকেটের নামের সঙ্গে তুলনা করা হয়, সাধারণত subject বা subjectAltName এন্ট্রি। সার্টিফিকেটটি vpn.example.com-এর জন্য ইস্যু করা হলে সেই হোস্টনামই Remote ID, এমনকি আপনি বেয়ার IP ঠিকানায় বক্সটিতে পৌঁছালেও।

এই অমিলটাই চিরাচরিত ব্যর্থতা: প্যাকেট আসে, সার্ভার উত্তর দেয়, তবু সংযোগটি ভেঙে পড়ে, কারণ সার্টিফিকেটের পরিচয় প্রোফাইল যে দাবি করেছিল তার সঙ্গে মেলে না। Server ফিল্ডকে কাঁচা IP-তে দেখানো সাহায্য করে না, এবং অনেক গেটওয়েতে সার্ভার এমন পরিচয়ে সাড়া দেওয়াই বন্ধ করে দেয় যা সে মেলাতে পারে না।

গেটওয়েরও মিলে যাওয়া সেটিং আছে। strongSwan সার্ভার নিজের পরিচয় leftid দিয়ে পাঠায় এবং ক্লায়েন্টের পরিচয় rightid দিয়ে সীমিত করতে পারে; দুই পক্ষ স্ট্রিং নিয়ে একমত না হলে IKE_AUTH উভয় দিকেই ব্যর্থ হয়। ব্রাউজার বার থেকে URL নকল করার বদলে অপারেটরকে জিজ্ঞাসা করুন সার্টিফিকেটটি কোন পরিচয়ের জন্য ইস্যু হয়েছিল।

Apple তার IKEv2 সেটিংস রেফারেন্সে পেলোড কী-গুলোকে RemoteIdentifier এবং LocalIdentifier নামে নথিভুক্ত করে। দুটোই সাধারণ স্ট্রিং, তাই বড়-ছোট অক্ষর আর শেষের স্পেস গুরুত্বপূর্ণ হতে পারে।

Local ID হলো আপনার iPhone যা দাবি করে

ব্যবহারকারীর নাম প্রমাণীকরণে EAP ব্যবহারকারীর নাম ও পাসওয়ার্ড যাচাই করে, আর Local ID হলো আলাদা একটি IKE পরিচয় যা কিছু গেটওয়ে প্রয়োগ করে। একটি গেটওয়ে দাবি করতে পারে Local ID ব্যবহারকারীর নামের সমান হবে, ইমেইল ঠিকানা হবে, অথবা তার সংযোগ নীতির কোনো এন্ট্রির সঙ্গে মিলবে; অন্যরা এটি উপেক্ষা করে। অপারেটর বললে তবেই এটি খালি রাখা নিরাপদ।

সার্টিফিকেট প্রমাণীকরণে Local ID সেই পরিচয়ের সঙ্গে মিলতে হবে যা গেটওয়ে ওই ক্লায়েন্ট সার্টিফিকেটের জন্য গ্রহণ করে, প্রায়ই সার্টিফিকেটের common name বা ডিভাইস রেকর্ডে ম্যাপ করা কোনো মান। সহকর্মীর প্রোফাইল কপি করলে তাঁর পরিচয়ও কপি হয়। সবচেয়ে ভালো ক্ষেত্রে গেটওয়ে ভুল ডিভাইস লগ করে, সবচেয়ে খারাপ ক্ষেত্রে প্রতি-ডিভাইস নীতি আপনাকে প্রত্যাখ্যান করে।

ফাঁদ হলো ধরে নেওয়া যে খালি মানে কোনো পরিচয় নেই। শুধু অসম্পূর্ণ দেখায় বলে খালি ফিল্ডে আপনার ইমেইল ঠিকানা ভরবেন না। অভীষ্ট মানটি নিশ্চিত করুন এবং যেমন দেওয়া হয়েছে ঠিক তেমনভাবে লিখুন।

সেভ করার আগে পাঁচ মিনিটের যাচাই

এগুলো ক্রমানুসারে শেষ করুন; যে ধাপটি প্রথমে ব্যর্থ হয় সেটিই ঠিক করতে হবে।

  1. অপারেটরের কাছে তিনটি স্ট্রিং নিন: সার্ভার সার্টিফিকেটের নাম, প্রত্যাশিত Local ID এবং প্রমাণীকরণ পদ্ধতি।
  2. প্রমাণীকরণ পদ্ধতি মিলান। Remote ID ও Local ID ব্যবহারকারীর নাম ও পাসওয়ার্ডের বিকল্প নয়, আর সার্টিফিকেট প্রোফাইল পাসওয়ার্ড গ্রহণ করবে না।
  3. মানগুলো ঠিকঠাক লিখুন, বড়-ছোট অক্ষরসহ, শেষে কোনো স্পেস ছাড়া।
  4. সার্টিফিকেট যাচাই চালু রাখুন। সতর্কবার্তা চুপ করাতে অসম্পর্কিত রুট সার্টিফিকেট ইনস্টল করলে নামের অমিল লুকায়, ঠিক হয় না।
  5. অফিসের Wi-Fi-তে নয়, মোবাইল ডেটায় পরীক্ষা করুন, যাতে ক্যাপটিভ পোর্টাল বা স্প্লিট DNS পরিচয়ের সমস্যা বলে জাহির না হয়।
FieldWhat belongs thereWhat a wrong value looks like
Remote IDThe DNS name in the gateway certificateServer answers, then the tunnel drops with a certificate or identity error
Local IDThe identity the gateway policy expects for youIKE_AUTH or user authentication fails after the server responds
ServerA reachable hostname or IPTimeout with no identity exchange at all

সারণিটি উপর থেকে পড়ুন। Server সারিতে টাইমআউট মানে পরিচয়ের ফিল্ডগুলো কখনো পরীক্ষাই হয়নি, তাই সেখানেই থামুন। সার্ভার উত্তর দেওয়ার পরেই যে ত্রুটি দেখা যায় তা প্রায় সবসময়ই Remote ID বা Local ID-এর অমিল।

ভুল ফিল্ডে ইশারা করা ত্রুটি

"User authentication failed"-এর মতো বার্তা ক্রেডেনশিয়াল বা EAP নিয়ে, Remote ID নিয়ে নয়। সার্টিফিকেট সতর্কবার্তা সার্টিফিকেটের নাম নিয়ে, আর সেখানেই Remote ID ও Server ফিল্ড মেলে। "The VPN server did not respond" সাধারণত বোঝায় UDP 500 ও 4500 কখনো সম্পূর্ণ হয়নি, বা NAT ট্রাভার্সাল ব্যর্থ হয়েছে, এবং কোনো পরিচয়ই তুলনা করা হয়নি।

গেটওয়ের দিকে পরিচয়ের ব্যর্থতা অন্যভাবে দেখায়: IKE_AUTH চলাকালে পিয়ার প্রত্যাখ্যাত হয়, অথবা লগে ক্লায়েন্টের পাঠানো ID লেখা থাকে এবং বলা হয় এটি কোনো সংযোগের সঙ্গে মেলে না। ওই লগ লাইনটিই বিতর্ক দ্রুত মেটানোর দ্রুততম উপায়, কারণ এটি ফোনের পাঠানো হুবহু স্ট্রিং দেখায়।

পাসওয়ার্ড রিসেট করলে প্রত্যাশিত সার্ভার পরিচয় ঠিক হবে না, আর Remote ID বদলালে ভুল পাসওয়ার্ড ঠিক হবে না। আগে ধাপটি আলাদা করুন, তারপর সেই ধাপের ফিল্ড সম্পাদনা করুন।

যখন প্রোফাইলটি ম্যানেজড

ফিল্ডগুলো ধূসর হলে কনফিগারেশন MDM থেকে এসেছে এবং ফোনটি ঠিক করার জায়গা নয়। VPN পেলোডই শনাক্তকারীগুলো বহন করে, তাই সঠিক পরিবর্তন ম্যানেজমেন্ট সার্ভারের প্রোফাইলে, তারপর ডিভাইসে তা পুনরায় ইনস্টল করা।

সেটিংস > সাধারণ > VPN ও ডিভাইস ম্যানেজমেন্টে দেখুন প্রোফাইলটি ম্যানেজড কি না এবং কে সাইন করেছে। আপনি এটি সরাতে না পারলে শনাক্তকারীগুলো লোকালভাবে সম্পাদনা করতে পারবেন না, আর দ্বিতীয় লোকাল প্রোফাইল বানালে কেবল পরস্পরবিরোধী কনফিগারেশন তৈরি হয়।

সেটিংস বন্ধ করার আগে আপনি যে তিনটি স্ট্রিং লিখেছেন এবং সেগুলো কোথা থেকে এসেছে তা টুকে রাখুন। পরেরবার টানেল ব্যর্থ হলে গেটওয়ে লগের প্রাপ্ত ID-র সঙ্গে ওই টীকা মিলিয়ে দেখুন: ভিন্ন হলে আপনি পাসওয়ার্ড নয়, ফিল্ডটির দিকে তাকিয়ে আছেন।

সম্পর্কিত নিবন্ধ