কেন L2TP/IPsec-এর জন্য IPsec-এর পাশাপাশি UDP 1701 দরকার

যে ফায়ারওয়াল IKE ও ESP অনুমোদন করে কিন্তু UDP 1701 অনুমোদন করে না, সেগুলি L2TP সংযোগ এমনভাবে ভেঙে দেয় যা দেখতে শংসাপত্রের সমস্যার মতো লাগে। কারণ হল L2TP প্রথমটির ভিতরে চলা দ্বিতীয় প্রোটোকল। IPsec এই বিনিময় বহন ও প্রমাণীকরণ করে, আর L2TP UDP 1701-এর উপরে নিজের টানেল চালায়, যা স্থানীয় স্ট্যাককে এখনও পৌঁছে দিতে হয়। প্রতিটি হেডার কোথায় দেখা যায় তা জানলে বোঝা যায় কোন ডিভাইসের কোন নিয়ম দরকার।

দুই প্রোটোকল, দুই পোর্ট সেট

একটি L2TP/IPsec সংযোগ UDP 500-এ IKE, যেখানে অনুবাদ আছে সেখানে UDP 4500-এ NAT ট্রাভার্সাল, আর যেখানে নেই সেখানে IP প্রোটোকল 50 হিসেবে ESP ব্যবহার করে। L2TP নিজেই UDP 1701-এর উপর একটি টানেল প্রোটোকল, এবং IPsec প্রতিপক্ষকে প্রমাণীকরণ করার পরে এটি চলে। দুই অর্ধাংশ ভিন্নভাবে ব্যর্থ হয়, আর সেগুলি সম্পর্কে জানানো লগ লাইনগুলি ভিন্ন কম্পোনেন্ট থেকে আসে। কেবল প্রথম অর্ধাংশ ঢাকা নিয়মের সেট এমন সংযোগ তৈরি করে যা দরকষাকষি করে এবং পরে টানেল পর্যায়ে মরে যায়।

পোর্ট নম্বর পরিবহন প্রান্তবিন্দু বর্ণনা করে, আর ESP আদৌ কোনো পোর্ট নয়। এই কারণেই কেবল TCP ও UDP নিয়ম দেওয়া ফায়ারওয়াল ইন্টারফেস সম্পূর্ণ IPsec নীতি প্রকাশ করতে পারে না। প্রোটোকল 50-কে প্রোটোকল হিসেবে অনুমোদন করতে হবে, আর কেবল UDP উল্লেখ করা নিয়ম এর সঙ্গে কখনও মিলবে না।

মোড়কই পোর্টটির ব্যাখ্যা দেয়

তারের উপরে একটি L2TP/IPsec সংযোগ সাধারণত 500-এ IKE এবং 4500-এ আবদ্ধ ESP দেখায়। UDP 1701 হেডার সুরক্ষিত পেলোডের ভিতরে থাকে, তাই বাইরের ইন্টারফেসে ক্যাপচার এটি দেখায় না। স্থানীয় হোস্টকে এখনও সেই ডেটাগ্রাম L2TP ডেমনকে পৌঁছে দিতে হয়, আর পৌঁছানো হয় ডিক্যাপসুলেশনের পরে। তাই 1701 নিয়মটি এন্ডপয়েন্টের নিজের ফায়ারওয়ালে প্রযোজ্য, এমনকি কোনো মধ্যবর্তী ডিভাইস কখনও পোর্টটি না দেখলেও।

প্রক্রিয়াকরণের ক্রম বেশিরভাগ বিভ্রান্তির ব্যাখ্যা দেয়। যদি স্ট্যাক হোস্ট ফিল্টারের আগে IPsec নীতি প্রয়োগ করে, ডিক্যাপসুলেটেড L2TP প্যাকেট UDP 1701 হিসেবে মিলে যায়; যদি ক্রম উল্টো হয়, নিয়মের সেট বাইরের পোর্টগুলিই দেখে। উভয় আচরণই বাস্তবে আছে, তাই একই নিয়মের সেট এক প্ল্যাটফর্মে কাজ করছে আর অনটিতে ব্যর্থ হচ্ছে বলে মনে হয়।

ক্রম অনুযায়ী পথটি পরীক্ষা করুন

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

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

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

পোর্ট স্ক্যান যা দেখাতে পারে না

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

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