strongSwan send_cert: IKE সার্টিফিকেট কখন পাঠানো হয়

গেটওয়ে সার্টিফিকেট-সম্পর্কিত প্রমাণীকরণ ব্যর্থতা লগ করে, এবং প্রথম প্রতিক্রিয়া হলো গ্রাহকে আরেকটি CA যোগ করা। এটি ধরে নেয় যে সার্টিফিকেটটি পৌঁছেছে এবং প্রত্যাখ্যাত হয়েছে। অন্য সম্ভাবনা হলো এটি কখনো পাঠানো হয়নি, এবং তা প্রেরকের সংযোগ নীতি ঠিক করে। বিশ্বাস বদলানোর আগে নির্ধারণ করুন দুটির মধ্যে কোনটি ঘটেছে।

send_cert আসলে কী নিয়ন্ত্রণ করে

সার্টিফিকেট দিয়ে প্রমাণীকরণের জন্য প্রয়োজন peer-এর প্রান্তিক সত্তার সার্টিফিকেট IKE বিনিময় বা পূর্বপ্রস্তুতির মাধ্যমে অন্য পক্ষের কাছে পৌঁছানো। swanctl-এ সংযোগ সেটিং send_cert নির্ধারণ করে এই প্রান্তবিন্দু তার সার্টিফিকেট পেলোড অন্তর্ভুক্ত করে কি না: কখনো নয়, সর্বদা বা ifasked। ডিফল্ট ifasked এটি peer-এর সার্টিফিকেট অনুরোধের উত্তরে পাঠায়। সার্টিফিকেট চাওয়া আলাদা সেটিং, কারণ অন্য পক্ষের কাছে তার সার্টিফিকেট চাওয়া নিজেরটি অফার করার সমান নয়।

পুরনো ipsec.conf স্থাপনাগুলো leftsendcert এবং rightsendcert ব্যবহার করত, এবং এই নামগুলো স্থানীয় ও দূরবর্তী ভূমিকার সঙ্গে মেলে, সরাসরি swanctl-এর সঙ্গে নয়।

সংযোগ বদলানোর আগে একটি প্রচেষ্টা পড়ুন

একটি নিয়ন্ত্রিত প্রচেষ্টা থেকে নির্ণয় করুন, সার্টিফিকেট জড়িত এই সাধারণ ধারণা থেকে নয়। নীতি এবং সক্রিয় সংযুক্তি উভয়ই পরীক্ষা করা যায়।

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

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

গ্রাহকের বিশ্বাস আলাদা সিদ্ধান্ত

ডেলিভারি ও বিশ্বাস ভিন্ন বৈশিষ্ট্য, এবং একটির সমাধান অন্যটির সমাধান নয়। গ্রাহকের কাছে অভীষ্ট বিশ্বাস অ্যাঙ্কর থাকতে হবে, ব্যবহারযোগ্য চেইন পেতে হবে এবং প্রত্যাশিত peer পরিচয়ের সঙ্গে মিলতে হবে। নিজের মধ্যবর্তী সার্টিফিকেট ছাড়া আসা প্রান্তিক সত্তার সার্টিফিকেট কঠোর চেইন যাচাইয়ে তবুও ব্যর্থ হয়। বিপরীতভাবে, একটি CA ইনস্টল করা peer-কে তার সার্টিফিকেট পাঠাতে আদৌ বাধ্য করে না।

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

পরীক্ষা দেখায় কোন ইস্যুকারী সার্টিফিকেটে স্বাক্ষর করেছে এবং কখন তা শেষ হয়, আর গ্রাহকের অ্যাঙ্করকে তার সঙ্গে মিলতে হবে। স্থাপনার মালিকানাধীন ইস্যুকারী CA-তে বিশ্বাস করুন, চেইনের প্রতিটি মধ্যবর্তী সার্টিফিকেটে নয়, কারণ প্রতিটি মধ্যবর্তীকে রুটে উন্নীত করা বিশ্বাসকে এক peer-এর অনেক বাইরে বিস্তৃত করে। পরিচয় যাচাই সক্রিয় রাখুন, কারণ কেবল যাচাই বন্ধ করে সফল হওয়া সংযোগ কোনো সমাধান নয়। যেখানে চেইন অসম্পূর্ণ, সেখানে প্রস্তুতি ঠিক করুন, প্রেরকের নীতি নয়।

প্রমাণ ছাড়া প্রেরক বদলাবেন না

যখন লগ দেখায় সার্টিফিকেট কখনো পাঠানো হয়নি এবং গ্রাহক সত্যিই তা চেয়েছে, তখন send_cert কে always-এ সেট করা সেই সংযোগের জন্য ন্যায্য পরিবর্তন। এটি swanctl কনফিগারেশনে প্রয়োগ করুন, সংযোগগুলো পুনরায় লোড করুন এবং বিদ্যমান SA পুনর্ব্যবহার না করে নতুন সেশন প্রতিষ্ঠা করুন। নিশ্চিত করুন সার্টিফিকেট পেলোড এখন দেখা যাচ্ছে এবং গ্রাহক তা অভীষ্ট অ্যাঙ্করের বিপরীতে গ্রহণ করছে। যদি কিছু না বদলায়, ত্রুটি বিশ্বাসের দিকেই ছিল এবং প্রেরকের সেটিং কারণ ছিল না।

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