দুটি IPsec পার্টনারের মধ্যে থাকা রাউটারের কি IPsec দরকার?

একটি ল্যাব অনুশীলন যা বলে “দুই সাইটের মধ্যে IPsec কনফিগার করুন” দুটি আলাদা কাজ লুকায়। দুটি প্রান্তই টানেল শেষ করে: তারা দর-কষাকষি করে, প্রমাণ করে, এনক্রিপ্ট ও ডিক্রিপ্ট করে। মাঝের যেকোনো রাউটার এমন প্যাকেট এগিয়ে পাঠায় যাদের বাইরের হেডার প্রান্তগুলোর, এবং এটি টানেলের অস্তিত্ব না জেনেই করে।

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

ফরোয়ার্ডিং মানে সমাপ্তি নয়

টানেল মোডে বাইরের IP হেডার টানেল শেষ করে এমন ডিভাইসগুলোকে ঠিকানা করা হয়। মাঝের রাউটার গন্তব্য খুঁজে এগিয়ে পাঠায়, অন্য যেকোনো প্যাকেটের মতোই, আর যে পেলোড এটি বহন করে তা তার কাছে অস্বচ্ছ।

এই অস্বচ্ছতা ইচ্ছাকৃত। রাউটারের কাছে সঙ্গীর গোপনীয়তা থাকে না, এটি কোনো দর-কষাকষি চালায় না এবং নীতি ডেটাবেসের প্রয়োজন হয় না। এর দরকার দূর প্রান্তের দিকে একটি পথ এবং প্যাকেট এগিয়ে পাঠানোর অনুমতি।

দুটোকে গুলিয়ে ফেললে বাস্তব ভুল হয়: ট্রানজিট ফায়ারওয়ালকে “IPsec অনুমতি দাও” বলা যখন আসল প্রয়োজন নির্দিষ্ট ঠিকানার মধ্যে প্রোটোকল 50 অনুমতি দেওয়া, অথবা মাঝের ডিভাইস পরিদর্শনের জন্য ডিক্রিপ্ট করবে আশা করা যখন এর কোনো চাবি নেই।

মাঝের ডিভাইসকে তবুও কী ঠিক করতে হবে

ফরোয়ার্ডিংয়ের নিজস্ব চাহিদা আছে। পথগুলোকে দুটি বাইরের প্রান্তেই পৌঁছাতে হবে, এবং পথের প্রতিটি নীতিকে অনুমান করা পোর্ট নম্বরের বদলে প্রকৃত বাইরের ট্রাফিক অনুমতি দিতে হবে। TCP 443-এর বিরুদ্ধে লেখা নিয়ম, কারণ কেউ TLS ধরে নিয়েছে, প্রোটোকল 50-এর সঙ্গে মিলবে না।

মূল ESP হলো IP প্রোটোকল 50। এটি TCP 50 নয় এবং UDP 50 নয়, আর non-TCP ট্রাফিক আটকানো নিয়ম এটি ফেলে দেবে। যদি নকশা UDP এনক্যাপসুলেশন ব্যবহার করে, দৃশ্যমান পরিবহন এনক্যাপসুলেশন পোর্টে বদলে যায়, এবং নীতিকে বেছে নেওয়া নকশার সঙ্গে মিলতে হবে।

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

সিমুলেটর কেন প্রশ্ন বদলায়

সিমুলেটর ছোট বৈশিষ্ট্য-তালিকার রাউটার নয়; এটি একটি মডেল যার নথিভুক্ত উপসেট এবং নির্দিষ্ট ডিভাইসকে কী করতে কনফিগার করা যায় সে সম্পর্কে নিজস্ব নিয়ম আছে। Cisco-র Packet Tracer সাধারণ প্রশ্নাবলি স্পষ্ট বলে যে ডিভাইস ও প্রোটোকল সরলীকৃত মডেল।

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

অনুপস্থিত কমান্ড আপনার কনফিগারেশনের ভুল নয়, মডেলের সীমা হতে পারে। বিদ্যমান কমান্ড প্রতিটি উৎপাদন আচরণ পুনরুৎপাদন না করেই সিনট্যাক্স গ্রহণ করতে পারে। যেকোনো দিকে সিদ্ধান্তে পৌঁছানোর আগে ইনস্টল করা সংস্করণের ডিভাইস সহায়তা দেখুন।

ল্যাবের জন্য উত্তীর্ণতার শর্ত লেখা

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

IPsec পাঠের জন্য দর-কষাকষির অবস্থা এবং LAN থেকে LAN পর্যন্ত একটি সুরক্ষিত প্রবাহ যোগ করুন। সিমুলেটর নিরাপত্তা সংযুক্তি দেখালে সেগুলো লিপিবদ্ধ করুন। না দেখালে টানেল যাচাই হয়েছে বোঝানোর বদলে প্রতিবেদনে তা বলুন।

সিমুলেটরের সংস্করণ, নির্বাচিত ডিভাইস এবং শেখার উদ্দেশ্য টোপোলজি ফাইলের সঙ্গে রাখুন। এই রেকর্ডই অন্যকে অনুশীলন পুনরুৎপাদন করতে এবং কোন অংশ মডেল করা হয়েছে বুঝতে দেয়।

উৎপাদন কনফিগারেশনের নিজস্ব প্ল্যাটফর্ম প্রমাণ দরকার। সবুজ সিমুলেট করা প্যাকেট একটি শিক্ষণ ফল, আপনি যে হার্ডওয়্যার মোতায়েন করবেন তার সামঞ্জস্যের বিবৃতি নয়।