strongSwan ESP-in-UDP: যখন সনাক্ত করার মতো কোনো NAT নেই

NAT সনাক্তকরণ একটি প্রশ্নের উত্তর দেয়: যাত্রাপথে ঠিকানা বা পোর্ট বদলেছে কি? এটি উত্তর দেয় না যে কোনো ফায়ারওয়াল IP প্রোটোকল 50 অনুমোদন করে কি না। কোনো রূপান্তর ছাড়া সাইট গেটওয়েও এমন নীতির পিছনে থাকতে পারে যা native ESP বাদ দেয়, এবং সেই প্রয়োজনীয়তা সনাক্ত না করে কনফিগার করতে হয়। প্রক্রিয়াটি ESP-in-UDP, এবং এটি এমন একটি সিদ্ধান্ত, যা নিজে থেকে আসা বিকল্প নয়।

সনাক্তকরণ ঠিকানার ওপর পাটিগণিত, ফায়ারওয়াল প্রোব নয়

IKEv2 NAT-সনাক্তকরণ পেলোড বহন করে যাতে উৎস ও গন্তব্য ঠিকানা এবং পোর্টের হ্যাশ থাকে। প্রতিটি পক্ষ যা পেয়েছে তার সঙ্গে স্থানীয়ভাবে যা দেখে তা তুলনা করে, এবং অমিল হলে বোঝে যে কিছু প্যাকেটটি রূপান্তর করেছে। সেই বিনিময়ে কিছুই পরীক্ষা করে না যে মাঝখানের কোনো রাউটার প্রোটোকল 50 ফরোয়ার্ড করে কি না।

ব্যবহারিক পরিণামটি সোজা করে বলা দরকার। যে টানেল native ESP-এর সঙ্গে কাজ করত, সেটি নিজে থেকে নতুন কঠোর ফায়ারওয়াল আবিষ্কার করবে না, এবং IKE সফল হতে থাকলেও তার পরের চেষ্টা ডেটা পর্যায়ে ব্যর্থ হবে। আপনি প্রতিষ্ঠিত IKE নিরাপত্তা অ্যাসোসিয়েশন দেখবেন এবং কোনো সুরক্ষিত ট্রাফিক থাকবে না, যা তারের ওপর ক্যাপচার না করা পর্যন্ত রাউটিং ত্রুটি মনে হয়।

তাই এনক্যাপসুলেশন হলো আপনি যে সংযোগ কনফিগার করেন তার একটি বৈশিষ্ট্য, নেটওয়ার্কের আচরণ থেকে পক্ষগুলোর দরকষাকষির ফল নয়।

encap কীভাবে বিনিময় বদলায়

যে আধুনিক strongSwan স্থাপনা swanctl.conf এর মাধ্যমে পরিচালিত হয়, সেখানে সংযোগে encap = yes সেট করলে NAT-সনাক্তকরণ বিনিময়ে প্রভাব পড়ে যাতে উভয় পক্ষ ESP-এর জন্য UDP এনক্যাপসুলেশন ব্যবহার করে। সুরক্ষিত প্যাকেটগুলো তখন UDP-এর ভেতরে, সাধারণত পোর্ট 4500-এ চলাচল করে, এবং দুই প্রান্তকে এই ব্যবস্থায় একমত হতে হয়।

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

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

strongSwan-এর NAT-traversal গাইড এই আচরণ বর্ণনা করে, MOBIKE ব্যবহারের সময় পোর্ট ফ্লোটিংয়ের মিথস্ক্রিয়াসহ।

আপনার ব্যাকএন্ডের নিজস্ব সেটিং ব্যবহার করুন

strongSwan-এর দুটি কনফিগারেশন ব্যাকএন্ড আছে, এবং কী দুটির মধ্যে আলাদা। একটি swanctl.conf সংযোগ encap নেয়, আর পুরোনো ipsec.conf সংযোগ নেয় forceencaps। এক ব্যাকএন্ডের কীওয়ার্ড অন্যটিতে ফেলে দিলে এমন কনফিগারেশন তৈরি হয় যা নিঃশব্দে লোড হয় এবং কিছুই বদলায় না, যা ত্রুটির চেয়েও খারাপ।

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

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

মোড়ানো ডেটা যাচাই করুন, শুধু পোর্ট নয়

সুরক্ষিত ট্রাফিক চলার সময় গেটওয়েতে ক্যাপচার করুন, তারপর তা strongSwan-এর নিজস্ব দৃশ্যের সঙ্গে তুলনা করুন:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

native ESP দেখায় IP প্রোটোকল 50-এর মতো এবং UDP-এর সঙ্গে মেলে না। মোড়ানো ESP দেখায় 4500-এ UDP ডেটাগ্রাম হিসেবে যার পেলোড IKE নয়। ওই একই পোর্টে IKE ট্রাফিক এনক্যাপসুলেশনের প্রমাণ নয়, কারণ MOBIKE IKE-কে সেখানে সরাতে পারে যখন ডেটা পথ native থাকে, তাই পোর্ট নম্বর নয়, পেলোড পড়ুন।

পাথ MTU-ও মনে রাখুন। মোড়ক অতিরিক্ত ওভারহেড যোগ করে, এবং যে পথ native ESP বহন করত সেখানে প্যাকেট বড় হলে সমন্বয় লাগতে পারে। প্রয়োজনীয় ICMP হ্যান্ডলিং ইতিমধ্যে নকশার অংশ হওয়া উচিত; এনক্যাপসুলেশন সেই নির্ভরতা সরায় না।

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