AH নাকি ESP? প্যাকেটকে কী রক্ষা করতে হবে তা দিয়েই সিদ্ধান্ত নিন

দুটি IPsec প্রস্তাব একই SHA-ভিত্তিক অখণ্ডতা অ্যালগরিদম উল্লেখ করেও ভিন্ন সুরক্ষা প্রোটোকল চাইতে পারে; AH ও ESP একটি প্রমাণীকরণ সেটিংয়ের দুই বানান নয়। আগে প্রোটোকল, তারপর তার অ্যালগরিদম, তারপর তার মোড পড়ুন, আর বেশিরভাগ অস্পষ্টতা মিলিয়ে যায়। AH প্যাকেট প্রমাণীকরণ করে, যার মধ্যে যাত্রাপথে অপরিবর্তিত থাকা IP হেডারের ফিল্ডও আছে; ESP তার ভেতরে যা ঢোকে তা প্রমাণীকরণ ও এনক্রিপ্ট করে এবং বাইরের হেডার অক্ষত রাখে। এই পার্থক্যই যেকোনো হ্যাশ নামের চেয়ে বেশি স্থাপন নির্ধারণ করে।

AH যা ঢাকে কিন্তু ESP ঢাকে না

AH অখণ্ডতা, ডেটা-উৎস প্রমাণীকরণ এবং নিজে নির্ধারিত পুনরায়-পাঠ প্রতিরোধ সেবা দেয়, কোনো গোপনীয়তা দেয় না। এর পরিধিতে উচ্চস্তরের ডেটা এবং IP হেডারের যে ফিল্ডগুলোকে তার নিয়ম অপরিবর্তনীয় ধরে সেগুলো থাকে, যা ESP ট্রান্সপোর্ট মোডে বাইরে রাখে। যদি প্রয়োজন বলে IP হেডার নিজেই প্রমাণীকরণ করতে হবে, তবে AH-ই সেই উত্তর দেয়।

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

NAT বাছাইকে একটাই বাধায় পরিণত করে

ঠিকানা অনুবাদ AH এইমাত্র প্রমাণীকৃত IP হেডারের উৎস বা গন্তব্য আবার লেখে, তাই অখণ্ডতা যাচাই দূরের প্রান্তে ব্যর্থ হয়, আর তা পাঠযোগ্য বার্তা নয়, প্রোটোকল ত্রুটি হিসেবে ব্যর্থ হয়। ESP বাইরের হেডার প্রমাণীকরণ করে না, তাই NAT ট্র্যাভার্সালসহ ESP কাজ করে, কিন্তু NAT-এর পিছনে AH করে না। দুই প্রান্ত সাধারণ রাউটারের পিছনে থাকা টানেলেই এটি প্রথম দেখা যায়। তাই প্রথম প্রশ্ন কোন প্রোটোকল শক্তিশালী নয়, বরং দুই প্রান্তের মধ্যে অনুবাদক আছে কি না।

থাকলে AH বাদ পড়ে, এবং আলোচনা ESP ও তার অ্যালগরিদম বাছাইয়ে যায়। এটি পছন্দ নয় বাধা, তাই এর জায়গা সিদ্ধান্তের শেষে নয়, শুরুতে।

মোড প্রশ্নটিকে গুণ করে

ট্রান্সপোর্ট মোডে ESP উচ্চস্তরের পেলোড রক্ষা করে ও IP হেডার অক্ষত রাখে; টানেল মোডে এটি ভেতরের পুরো প্যাকেট, ভেতরের IP হেডারসহ, মোড়ক করে রক্ষা করে। AH-এরও একই দুই মোড, তাই AH বা ESP আসলে যেকোনো অ্যালগরিদম বাছাইয়ের আগে চারটি সমন্বয়।

সংযুক্ত-মোড ESP অ্যালগরিদম এরপর দ্বিতীয় প্রোটোকল ছাড়াই অখণ্ডতা ঠিক করে। AES-GCM ও ChaCha20-Poly1305 এক নির্মাণেই প্রমাণীকরণ ও এনক্রিপশন করে, তাই উপরে AH যোগ করলে কিছুই পাওয়া যায় না, বরং আরেকটি হেডার ও আরেকটি দর-কষাকষি খরচ হয়। স্থাপত্য AH ও ESP একসঙ্গে অনুমোদন করে, আর বাস্তব প্রশ্ন হলো আপনার গেটওয়ে ও রিলিজ এই সমন্বয় সমর্থন করে কি না এবং পরে কেউ এটি রক্ষণাবেক্ষণ করতে পারবে কি না।

শুধু-AH-এর সৎ বিকল্প

শুধু-অখণ্ডতা ESP প্রকরণ অ্যালগরিদম রাখে এবং এনক্রিপশনের দাবি জালিয়াতি না করে ছেড়ে দেয়, আর NAT পার হয়। যদি পুরোনো নকশা গোপনীয়তা ছাড়া প্রমাণীকরণের জন্য AH ব্যবহার করে থাকে, তবে ওই প্রকরণই সরাসরি অনুবাদ, নোট লাগানো এনক্রিপ্টেড টানেল নয়।

প্রস্তাবে ESP দেখা এনক্রিপশনের প্রমাণও নয়। এনক্রিপশন অ্যালগরিদম পড়ুন: NULL এনক্রিপশন এন্ট্রি মানে শুধু অখণ্ডতা, আর সংযুক্ত-মোড এন্ট্রি মানে দুটোই।

তিনটি প্রশ্নে সিদ্ধান্ত নিন

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

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

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