IPsec-এর ভিতরে IPsec: বাইরের টনেলে কোন ঠিকানাগুলো থাকতে হবে

নেস্টেড IPsec নিয়ে ভাবা সহজ হয় যখন দুই স্তর ভিন্ন মেশিনে শেষ হয়। চারটি গেটওয়ে, দুটি টনেল, এবং একটি প্রশ্ন যা ঠিক করে ডিজাইনটি কাজ করবে কি না: ভেতরের টনেল প্যাকেট নিয়ে শেষ করার পরে বাইরের টনেল আসলে কী দেখে? এর উত্তর দিলে সিলেক্টর, রুট আর সমস্যা সমাধানের ক্রম নিজেই আসবে। ভুল করলে আপনি একটি টনেল ডিবাগ করতে এক দিন কাটাবেন যা কারিগরি দিক থেকে আপ।

চার-গেটওয়ে মডেল

বাইরের গেটওয়ে A ও B দুই সাইটের মধ্যে প্রথম টনেল তৈরি করে। A-এর পিছনে ট্রানজিট ঠিকানা 10.60.0.2 নিয়ে ভেতরের গেটওয়ে C, আর B-এর পিছনে ট্রানজিট ঠিকানা 10.70.0.2 নিয়ে ভেতরের গেটওয়ে D থাকে। অ্যাপ্লিকেশন নেটওয়ার্কগুলো C ও D-এর পিছনে থাকে, এবং উদাহরণের প্রতিটি ঠিকানা ইচ্ছাকৃতভাবে ওভারল্যাপ করে না।

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

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

প্রতিটি স্তর কেবল নিজের সুরক্ষা সরায়

C, D-এর জন্য একটি অ্যাপ্লিকেশন প্যাকেট এনক্রিপ্ট করে। ফলাফলটি C থেকে D ঠিকানায় থাকে, এবং সেটাই A পর্যন্ত পৌঁছায়। এর পরের সবকিছু ওই পুনর্লিখনের ওপর নির্ভর করে।

A এটিকে B-এর জন্য আবার এনক্রিপ্ট করে। B বাইরের স্তর ডিক্রিপ্ট করে, C থেকে D-তে যাওয়া প্যাকেট দেখে এবং সেটি এখনও এনক্রিপ্টেড অবস্থায় ফরওয়ার্ড করে। D ভেতরের সুরক্ষা সরিয়ে অ্যাপ্লিকেশন প্যাকেটটি পৌঁছে দেয়।

তাই A ও B ভেতরের প্রান্তবিন্দু ও তাদের মেটাডেটা দেখে, কিন্তু তারা সেই পক্ষ নয় যারা অ্যাপ্লিকেশন পেলোড ডিক্রিপ্ট করে। এটি ডিজাইনের বাস্তব বৈশিষ্ট্য, C, D বা অ্যাপ্লিকেশন হোস্টগুলো বিশ্বাসযোগ্য বলে দাবি নয়।

বাইরের সিলেক্টরগুলো ভেতরের গেটওয়ে নির্দেশ করে

এখানেই বেশিরভাগ নির্মাণ ব্যর্থ হয়। নীতি-ভিত্তিক বাইরের টনেলের জন্য, আপনি যে সিলেক্টরগুলো নিয়ে আলোচনা করেন তাতে A ও B যে ঠিকানাগুলো সত্যিই সামলায় সেগুলো থাকতে হবে: 10.60.0.2/32 এবং 10.70.0.2/32, সঠিক লোকাল ও রিমোট ক্রমে।

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

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

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

ফরওয়ার্ডিং এবং রিকার্সনের ফাঁদ

সিলেক্টর রাউটিংয়ের বিকল্প নয়। A ও B-কে C ও D-এর মধ্যে উভয় দিকে ট্রাফিক ফরওয়ার্ড করতে হবে, অর্থাৎ IP ফরওয়ার্ডিং চালু, টনেলের দিকে ইঙ্গিত করা রুট, এবং অপর প্রান্তে বিদ্যমান ফেরত পথ।

বাইরের টনেল XFRM ইন্টারফেস ব্যবহার করলে, রুট ইন্টারফেস নির্বাচন করে আর আলোচিত নীতিগুলো এখনও সীমাবদ্ধ করে এটি কী বহন করে। একটি ইন্টারফেস সুরক্ষিত পরিধি বাড়ায় না; এটি কেবল বদলে দেয় কার্নেল কীভাবে প্যাকেটটি তোলে।

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

স্তর যোগ করার আগে ট্রান্সলেশন দেখুন

অন্য কিছু টিউন করার আগে A ও B-তে যেকোনো সোর্স NAT দেখুন। যে নিয়ম IPsec নীতি প্রয়োগের আগে C-এর ঠিকানা পুনর্লিখন করে তা সম্মত সিলেক্টর ভাঙতে পারে, আর D অপর প্রান্তে কী পায় তাও বদলে দিতে পারে।

দুই স্তর থাকলেই বিস্তৃত মাস্কারেডিং নিরাপদ হয় না। এটি লুকায় দূর প্রান্ত কোন ঠিকানা দেখে, আর টনেল আপ থাকলেও অ্যাপ্লিকেশন না চললে ঠিক সেই তথ্যই আপনার দরকার।

যদি NAT নিয়ম সত্যিই দরকার হয়, তাহলে লিখে রাখুন প্রতিটি পক্ষ কোন ঠিকানার সঙ্গে কথা বলছে বলে মনে করে। ওই একটি লাইনই টনেল না ট্রান্সলেশন দোষী এই বিতর্কের বেশিরভাগ মেটায়। এক বছর পরে নিয়ম সরানোর সময় পরের ইঞ্জিনিয়ারকে কোথায় দেখতে হবে তাও বলে দেয়। পিং এসবের কিছুই করবে না।

fail-closed প্রমাণ করুন এবং MTU যাচাই করুন

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

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

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