IKEv2 একটিমাত্র হ্যান্ডশেক নয়: আগে IKE SA, তারপর প্রমাণীকরণ, তারপর CHILD SA
গেটওয়ের উত্তর পৌঁছনীয়তা প্রমাণ করে, পরিচয় নয়। IKE_SA_INIT, IKE_AUTH এবং প্রথম CHILD SA অনুসরণ করুন, তারপর ট্র্যাফিক চলার আগে কী সত্য হতে হবে তা যাচাই করুন।
আপনি হয়তো ভাবতে পারেন যে IKEv2 সংযোগ একটি মাত্র বিনিময়, যা আপনার ট্র্যাফিক এনক্রিপ্ট হয়ে শেষ হয়। আসলে এটি কমপক্ষে দুটি, এবং প্রথমটি কাউকে প্রমাণীকরণ করে না। দুই পক্ষ নিয়ন্ত্রণ বার্তা দিয়ে শুরু করে, ক্রিপ্টোগ্রাফিক প্যারামিটারে একমত হয়, পরিচয় প্রমাণ করে এবং কেবল তারপর সেই অবস্থার বিষয়ে সম্মত হয় যা অ্যাপ্লিকেশন প্যাকেট বহন করে। এই ক্রমটিই সেই অমিল ব্যাখ্যা করে যা মানুষ নিয়মিত রিপোর্ট করে: গেটওয়ে উত্তর দেয়, ক্লায়েন্ট বলে সংযুক্ত, অথচ ব্যক্তিগত অ্যাপ্লিকেশন এখনও সময় শেষে থেমে যায়। প্রতিটি ধাপ আসলে কী করে এবং তার পরে কী সত্য হতে হবে, তা এখানে দেওয়া হলো।
ভ্রান্ত ধারণা: গেটওয়ে উত্তর দিলেই আপনি সংযুক্ত
প্রথম বার্তার উত্তর প্রমাণ করে যে প্রান্তবিন্দু পৌঁছনীয় এবং কথা বলতে ইচ্ছুক। এটি প্রমাণ করে না যে কোনো অ্যাকাউন্ট গৃহীত হয়েছে, কোনো সার্টিফিকেট শৃঙ্খল যাচাই হয়েছে, বা কোনো ডেটা নীতি ইনস্টল হয়েছে।
এই ব্যর্থতাগুলি পরে ঘটে এবং ভিন্ন উপসর্গ তৈরি করে। সার্টিফিকেট প্রত্যাখ্যান বা EAP ব্যর্থতা প্রথম বিনিময় ইতিমধ্যে সফল হওয়ার পরে আসে, তাই UDP 500-এ ping এবং সবুজ ক্লায়েন্ট আইকন এত কম বলে।
IKE_SA_INIT: প্যারামিটারে একমত, পরিচয়ে নয়
প্রথম বিনিময়টি IKE নিরাপত্তা সংস্থানের জন্য প্রস্তাব বহন করে: এনক্রিপশন ও অখণ্ডতা অ্যালগরিদম, একটি ছদ্ম-এলোমেলো ফাংশন এবং একটি Diffie-Hellman গ্রুপ। দুই পক্ষ nonce-ও বিনিময় করে, এবং প্রতিটি পক্ষ সেই মানগুলি থেকে তৈরি যৌথ গোপন থেকে IKE SA-এর জন্য কী উপাদান তৈরি করে। এই বিনিময়ে কিছুই প্রতিষ্ঠা করে না যে অন্য পক্ষ কে। এটি প্রতিষ্ঠা করে যে দুই পক্ষ একই কী গণনা করতে পারে এবং একটি প্রস্তাবে একমত। যে উত্তরদাতা কোনো প্রস্তাব পছন্দ করে না, সে এখানেই বিনিময় প্রত্যাখ্যান করে, তাই সংস্করণ বা অ্যালগরিদমের অমিল সার্ভার বন্ধ থাকার মতো দেখায়।
এই মুহূর্তে তৈরি IKE SA পরবর্তী সমস্ত ব্যবস্থাপনা বিনিময় রক্ষা করে। এটিই তার কাজ, এবং এটি আপনার প্যাকেট রক্ষা করার কাজ থেকে আলাদা।
IKE_AUTH: পরিচয় প্রমাণ করুন, তারপর প্রথম CHILD SA তৈরি করুন
দ্বিতীয় বিনিময় পরিচয় বহন করে। সার্টিফিকেটের ক্ষেত্রে প্রতিটি পক্ষ তার ব্যক্তিগত কী দিয়ে স্বাক্ষর করে এবং এমন একটি শৃঙ্খল উপস্থাপন করে যা অন্যপক্ষকে যাচাই করতে হয়; EAP-এর ক্ষেত্রে উত্তরদাতা নির্বাচিত পদ্ধতির মাধ্যমে সূচনাকারীকে চ্যালেঞ্জ করে। এখানেই ভুল সার্ভার নাম, মেয়াদোত্তীর্ণ সার্টিফিকেট বা প্রত্যাখ্যাত পাসওয়ার্ড শেষ পর্যন্ত প্রকাশ পায়।
স্বাভাবিক ক্ষেত্রে IKE_AUTH প্রথম CHILD SA-ও আলোচনা করে, তাই ডেটা সুরক্ষা একই রাউন্ড ট্রিপে সম্মত হয়। সূচনাকারী ট্র্যাফিক সিলেক্টর প্রস্তাব করে, উত্তরদাতা সেগুলি সংকুচিত বা প্রত্যাখ্যান করে, এবং ডেটা পথের কী IKE SA থেকে উদ্ভূত হয়। এর অর্থ একটি বিনিময় দুই খুব ভিন্ন জায়গায় ব্যর্থ হতে পারে: পরিচয় বা নীতি। সাধারণ হ্যান্ডশেক ব্যর্থতার বদলে notify পেলোড বা ত্রুটি পড়ুন, কারণ একটির সমাধান সার্টিফিকেট এবং অন্যটির সমাধান সাবনেট অমিল।
দুটি SA, দুটি কাজ
| Association | Protects | Lifetime behaviour |
|---|---|---|
| IKE SA | Management exchanges: rekeying, delete, configuration payloads | Rekeyed on its own schedule; the data path can survive the change |
| CHILD SA | Application traffic matching the traffic selectors | Rekeyed independently, often more frequently |
সেগুলি আলাদা রাখা দুইটি আচরণ ব্যাখ্যা করে যা বাগের মতো দেখায়। একটি টানেল প্রতিষ্ঠিত দেখাতে পারে যখন পটভূমিতে কী পুনর্নবীকরণ ব্যর্থ হচ্ছে, এবং ক্লায়েন্ট সংযোগ না হারিয়েই CHILD SA প্রতিস্থাপিত হতে পারে।
strongSwan-এ IKEv2 কনফিগারেশন রেফারেন্স এবং swanctl --list-sas উভয় স্তর দেখায়, আর ip xfrm state সাথে ip xfrm policy দেখায় কার্নেল আসলে কী ইনস্টল করেছে। এই দুই দৃশ্যের তুলনা করাই দ্রুততম উপায় দেখতে যে আলোচনা শেষ হয়েছে, নাকি কেবল শেষ দেখাচ্ছিল। যদি ডেমন এমন CHILD SA তালিকাভুক্ত করে যার জন্য কার্নেলে কোনো অবস্থা নেই, তবে ইনস্টল নিঃশব্দে ব্যর্থ হয়েছে। যদি কার্নেল এমন অবস্থা ধরে রাখে যা ডেমন জানে না, তবে আপনি আগের একটি প্রয়াসের অবশিষ্ট দেখছেন।
টানেল ওঠার পরে কী কী এখনও সত্য হতে হবে
ট্র্যাফিক সিলেক্টর নির্ধারণ করে কোন ঠিকানাগুলি আচ্ছাদিত। যদি ক্লায়েন্ট একটি সাবনেট প্রস্তাব করে আর সার্ভার অন্যটি প্রত্যাশা করে, CHILD SA ইনস্টল হয় কিন্তু দরকারি কিছু বহন করে না, এবং ত্রুটিটি আলোচনার সমস্যা নয়, রাউটিং সমস্যা হিসেবে দেখা যায়। তারপর স্থানীয় স্ট্যাককে সহযোগিতা করতে হবে: হোস্ট যেখানে রাউট করে সেখানে ফরওয়ার্ডিং সক্রিয়, টানেলের দিকে রুট, ডিক্যাপসুলেটেড প্যাকেট অনুমোদনকারী ফায়ারওয়াল নিয়ম, এবং ব্যক্তিগত নাম জড়িত থাকলে একটি অভ্যন্তরীণ রিজলভার। এগুলির প্রতিটি আলাদাভাবে ব্যর্থ হয় এবং IKE ডেমন পুনরায় চালু করে কোনোটিই ঠিক হয় না।
নির্ণয়ের সময় লগ দৃশ্যমান রাখুন: প্রাথমিক বিনিময়, তারপর পরিচয় যাচাই, তারপর যেখানে প্রযোজ্য সেখানে ব্যবহারকারী প্রমাণীকরণ, তারপর CHILD ইনস্টল, তারপর অ্যাপ্লিকেশন ট্র্যাফিক। যে ধাপে থামে সেটিই ঠিক করার ধাপ, এবং পরবর্তী রাউটিং ব্যর্থতা কখনও ইতিমধ্যে পাস করা পরিচয় যাচাই শিথিল করার কারণ নয়।