iOS IKEv2 থেকে strongSwan: কোনো প্রস্তাব বাছা হয়নি, তালিকাটি ঠিক করুন

আইফোন টানেল তোলে, গেটওয়ে কিছুই উত্তর দেয় না, আর ফোনটি একটি সাধারণ ব্যর্থতা দেখায়। strongSwan-এর লগ আরও নির্দিষ্ট: কোনো প্রস্তাব বাছা হয়নি। এই বার্তার অর্থ হল গ্রহণযোগ্য সাইফার স্যুটের দুটি তালিকা কখনোই ওভারল্যাপ করেনি, তাই প্রমাণীকরণ শুরুর আগেই বিনিময় শেষ হয়েছে। এটি একটি মিলের সমস্যা, আর সমাধান হল তালিকা দুটিকে ছেদ করানো।

গেটওয়ে কোথায় তার নীতি ঘোষণা করে

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

যে ক্লায়েন্ট একটি প্রশস্ত তালিকা দেয় সে পিন করা গেটওয়েতে এখনও সংযোগ করতে পারে, যতক্ষণ দুই পাশে অন্তত একটি সমন্বয় উপস্থিত থাকে। যা হতে পারে না তা হল পিন করা সেটের বাইরে দরকষাকষি।

এই কারণেই অন্য একটি VPN অ্যাপ থেকে কপি করা প্রোফাইল কাজ করতে পারে যেখানে আপনারটি করে না: অন্য অ্যাপটি ভিন্ন তালিকা দিয়েছিল।

নামগুলো মিলতে হবে, উন্নত হতে হবে না

দুটি অনুবাদ মানুষকে ধরে যখন তারা strongSwan থেকে iOS-এ মান স্থানান্তর করে। IKE প্রস্তাবে SHA1 হিসেবে লেখা অখণ্ডতা অ্যালগরিদমটি তার সংক্ষিপ্ত রূপে ভ্রমণ করে, যাকে iOS .SHA96 বলে। modp1024 হিসেবে লেখা ডিফি-হেলম্যান গ্রুপটি হল group 2, যাকে iOS .group2 বলে। SHA-256 বা group 14 প্রতিস্থাপন করলে এমন গেটওয়ের সাথে দরকষাকষি হবে না যা শুধু পুরনো জোড়াটি গ্রহণ করে। ক্লায়েন্টকে একই অ্যালগরিদম বর্ণনা করতে হবে, আরও শক্তিশালী কিছু নয়।

NEVPNProtocolIKEv2-এ সেই মানগুলো স্পষ্টভাবে সেট করুন। ডিফল্ট মান আপনি যে প্রোফাইল প্রতিস্থাপন করছেন তার চেয়ে প্রশস্ত বা সংকীর্ণ হতে পারে, আর পার্থক্যটি কেবল তখনই দেখা যায় যখন হ্যান্ডশেক ব্যর্থ হয়।

চাইল্ড প্রস্তাব পরে এবং আরও নিঃশব্দে ব্যর্থ হয়

IKE-এর সাথে সাথে চাইল্ড সিকিউরিটি অ্যাসোসিয়েশনও কনফিগার করুন। যখন কেবল IKE প্যারামিটার মেলে, টানেল প্রমাণীকরণ পেরোয় এবং তারপর কোনো ট্রাফিক বহন করে না, যা প্রত্যাখ্যানের চেয়ে অনেক বেশি নিঃশব্দ ব্যর্থতা। একই ধাপে চাইল্ডের এনক্রিপশন, অখণ্ডতা, গ্রুপ ও লাইফটাইম সেট করুন। ক্লায়েন্টের লাইফটাইম গেটওয়ের মানে বা তার নিচে রাখুন, কারণ দীর্ঘতর কিছুর উপর জোর দিলে ভিন্ন কারণে একই প্রস্তাব-বাছা-হয়নি বার্তা আসে। সেখানকার অমিল লগে IKE অমিলের মতোই দেখায়।

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

পুরনো স্যুটটি কেবল যতদিন দরকার ততদিন রাখুন

SHA-1-কে 1024-বিট গ্রুপের সাথে পিন করা একটি সেতু, গন্তব্য নয়। দুটিই অপ্রচলিত, আর নতুন ক্লায়েন্ট সরাসরি প্রত্যাখ্যান করতে পারে, মানে আপনার দিকে কোনো পরিবর্তন ছাড়াই পরের ডিভাইসে প্রোফাইলটি ব্যর্থ হবে। পিনটিকে সাময়িক ধরুন এবং রেকর্ডে তা বলুন।

strongSwan যদি আপনার হয়, একটি আধুনিক প্রস্তাব যোগ করুন এবং পুরনো এন্ট্রি পুরনো ডিভাইসের জন্য থাকা অবস্থায় দুই প্রান্তকে উপরের দিকে দরকষাকষি করতে দিন। ডেমনটির স্ট্যাটাস আউটপুট পড়ে দেখুন প্রতিটি সংযোগ আসলে কোন স্যুট ব্যবহার করেছে। তারপর আধুনিক জোড়াটি নিশ্চিত হলে ক্লায়েন্টের দিকের পিনিং সরিয়ে ফেলুন। টানেল উঠে আসা যথেষ্ট প্রমাণ নয়, কারণ এটি সেই স্যুটেই উঠতে পারে যা আপনি বাদ দিতে চাইছিলেন। strongSwan IKEv2 ডকুমেন্টেশন প্রস্তাবের সিনট্যাক্স ও কঠোর মার্কার বর্ণনা করে।