Android IKEv2 বিশ্বাস ত্রুটি: রুট নয়, মধ্যবর্তী CA পাঠান
ফোন গেটওয়ে প্রত্যাখ্যান করে কারণ প্রাপ্ত চেইন তাড়াতাড়ি থেমে যায়। সিদ্ধান্ত নিন: মধ্যবর্তী পাঠান, পরিচয় ঠিক করুন বা কী ধরন বদলান।
ফোন সংযোগ করতে অস্বীকার করে এবং No trusted RSA public key found for vpn.example.net ছাপে, অথচ একই গেটওয়ে সার্টিফিকেট একই নেটওয়ার্কে ল্যাপটপ থেকে কাজ করে। সার্টিফিকেট পুনরায় ইস্যু করা লোভনীয় পদক্ষেপ। তার আগে তিনটি ব্যর্থতার কোনটি আপনার আছে নির্ণয় করুন, কারণ তাদের একটিই সার্টিফিকেটের বিষয়বস্তু নিয়ে।
একটি বার্তার পেছনে তিনটি ব্যর্থতা
Android গেটওয়ে সার্টিফিকেট থেকে VPN প্রোফাইলে নির্বাচিত CA পর্যন্ত একটি চেইন গড়ে, তারপর সার্ভারের নাম প্রোফাইলের সঙ্গে মেলায়। বিজ্ঞপ্তি ফলাফল জানায়, ধাপ নয়। বিশ্বাস ব্যর্থতা মানে বিনিময়ে দেওয়া সার্টিফিকেট দিয়ে চেইন সম্পূর্ণ হয়নি; পরিচয় ব্যর্থতা মানে চেইন বৈধ কিন্তু নাম মেলেনি; অ্যালগরিদম ব্যর্থতা মানে ডিভাইস বা প্রোফাইল কী ধরন বা স্বাক্ষর গ্রহণ করে না।
| What you see | What it points to | First move |
|---|---|---|
| Chain stops after the leaf in the daemon log | intermediate not loaded or not sent | load the intermediate as CA material |
| Chain validates, name differs from the profile | identity mismatch | fix the profile name or the certificate SAN |
| Chain validates, handshake still fails | key or signature not accepted | compare key type against the device |
পরপর মেরামত চেষ্টার বদলে প্রমাণ দিয়ে সিদ্ধান্ত নিন। ডিমনে লগ স্তর 2-এ একবার চেষ্টাই বলে দেয় আপনি কোন সারিতে, এবং কখনও ভুল না হওয়া সার্টিফিকেট পুনরায় ইস্যুর চেয়ে কম খরচ।
আগে সিদ্ধান্ত নিন: পুরো চেইন এসেছে কি?
strongSwan ওই সংযোগের জন্য সাজানো সার্টিফিকেট পাঠায়, আর মধ্যবর্তী সার্টিফিকেট আলাদা প্রত্যয়ন। ডিমন সেগুলি পেলোডে রাখার আগে CA সার্টিফিকেট হিসেবে লোড করতে হয়, তাই যে বিন্যাসে সার্ভার সার্টিফিকেট মধ্যবর্তী দ্বারা স্বাক্ষরিত, রুট বিশ্বাসের নোঙর, আর মধ্যবর্তী কেবল CA-র বিল্ড ডিরেক্টরিতে থাকে, তা ঠিক এই ব্যর্থতাই দেয়: তারে কেবল পাতা, আর ফোনে চেইন তাড়াতাড়ি শেষ।
ডিমন কী রাখে দেখুন swanctl স্থাপনায় swanctl --list-certs, বা পুরনো স্টার্টারে ipsec listcerts। মধ্যবর্তীটি রুটের উপরে CA সার্টিফিকেট হিসেবে দেখা উচিত। না থাকলে কোনো ক্লায়েন্ট অপশনই সাহায্য করবে না; থাকলে পরের প্রশ্নে যান।
তারপর দেখুন সেটি পাঠানো হবে কি না। swanctl.conf রেফারেন্স send_cert নথিভুক্ত করে, যার ডিফল্ট ifasked কেবল সহকর্মী চাইলে সার্টিফিকেট পাঠায়, আর always সর্বদা পাঠায়। পুরনো সমতুল্য ipsec.conf-এ leftsendcert=always। এই সেটিং পাঠানো নিয়ন্ত্রণ করে, প্রাপ্যতা নয়, তাই ডিমন কখনও না লোড করা মধ্যবর্তীর ক্ষতিপূরণ করতে পারে না।
চেইন ছোট হলে ডিমন যেখানে খোঁজে সেখানে মধ্যবর্তী লোড করুন
মধ্যবর্তীটি পাতার পাশে নয়, CA ডিরেক্টরিতে রাখুন: ipsec.conf বিন্যাসে /etc/ipsec.d/cacerts, swanctl-এ /etc/swanctl/x509ca, বা আপনার প্যাকেজ যে পথ বদলায়। কনফিগারেশন পুনরায় লোড করে সার্টিফিকেট আবার তালিকাভুক্ত করুন। কিছু সংস্করণ পাতার ফাইলের ভিতরে চেইন থাকা বান্ডলও পাঠায়, কিন্তু CA ডিরেক্টরি সংস্করণ ও প্যাকেজের মধ্যে বহনযোগ্য ব্যবস্থা।
ক্লায়েন্টের দিক থেকেও যাচাই করুন। ফোন কেবল বিনিময়ে যা গেছে তা দেখে, তাই স্তর 2-এর ডিমন লগ পাঠানো সার্টিফিকেটে মধ্যবর্তীটি দেখাবে। লগ দেখালেও ফোন ব্যর্থ হলে আপনি তালিকার অন্য সারিতে, আর CA ফাইল বদলালে ফলাফল বদলাবে না।
চেইন সম্পূর্ণ হলে সার্টিফিকেট সম্পাদনা বন্ধ করুন
পরিচয় ব্যর্থতা VPN প্রোফাইলের নাম ও সার্টিফিকেটের নামের অমিল। Android আপনার সেট করা সার্ভার পরিচয়কে যাচাই করা সার্টিফিকেটের সঙ্গে মেলায়, তাই প্রোফাইল ঠিকানায় ইশারা করলে অথচ সার্টিফিকেট হোস্টনাম বলে, বা প্রোফাইল এমন হোস্টনাম বলে যা সার্টিফিকেট ঢাকে না, তবে সফল চেইন যাচাইয়ের পরেও ব্যর্থ হয়। ভুল দিকটি ঠিক করুন এবং এক বদলালে অন্যটিও মিলিয়ে রাখুন।
অ্যালগরিদম ব্যর্থতা বৈধ চেইন ও মেলা নামে দেখা দেয়। Android সংস্করণে গ্রহণযোগ্য কী ধরন ও স্বাক্ষর স্কিম আলাদা, আর প্রোফাইলের ধরনই অপশনগুলি সীমিত করে। গেটওয়ে পুরনো বা অস্বাভাবিক সংমিশ্রণ ব্যবহার করলে সার্টিফিকেট নষ্ট ধরে নেওয়ার আগে ডিভাইস যা সমর্থন করে তার সঙ্গে মেলান। ডিমন লগ দেখাবে হ্যান্ডশেক বিশ্বাসের ক্ষেত্রের চেয়ে এগিয়েছে, যা সংকেত যে চেইন আর সমস্যা নয়।
ফোনে মধ্যবর্তীটিকে ব্যবহারকারী রুট হিসেবে ইনস্টল করবেন না
অনুপস্থিত মধ্যবর্তীটিকে ফোনে ব্যবহারকারী সার্টিফিকেট হিসেবে ইনস্টল করলে সতর্কতা মিলিয়ে যায় এবং ব্যবহারকারী-ইনস্টল করা রুট গ্রহণ করে এমন প্রতিটি অ্যাপের জন্য ফোনের বিশ্বাস মডেল বদলে যায়। এটি পরের ক্লায়েন্টে আঘাত করা সরবরাহ ত্রুটিও লুকায়, আর গেটওয়ে ভবিষ্যতের প্রতিটি ডিভাইসে অসম্পূর্ণ চেইন পাঠাতে থাকে। স্থায়ী সমাধান সার্ভারে, একবার, সব ক্লায়েন্টের জন্য।
পরিবর্তন রেকর্ডে তিনটি সিদ্ধান্ত আলাদা রাখুন: কোন সার্টিফিকেট পাঠানো হলো, কোন পরিচয় মেলানো হলো এবং কোন অ্যালগরিদমে সম্মতি হলো। সর্বদা সম্পূর্ণ চেইন পাঠানো গেটওয়ে, সার্টিফিকেটের সঠিক নাম দেওয়া প্রোফাইল এবং ফ্লিট যে কী ধরন সমর্থন করে — এই তিনটি ছোট তথ্যই পুরো ব্যর্থতা।