কেন tcpdump এক দিকেই কেবল IPsec প্লেইনটেক দেখায়

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

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

ক্যাপচার পয়েন্টই ঠিক করে আপনি কী দেখেন

সাধারণ ইন্টারফেসে একটি AF_PACKET সকেট ডিভাইস লেয়ারের কাছাকাছি থাকে। হোস্ট ছেড়ে যাওয়া প্যাকেট প্রথমে IPsec আউটপুট প্রসেসিংয়ের মধ্য দিয়ে যায়, যা একটি ভেতরের TCP সেগমেন্টকে ESP বা UDP-4500 ডেটাগ্রামে পরিণত করে, এবং কেবল তারপরই ওই লেয়ারে পৌঁছায়। আসা প্যাকেটগুলো তার থেকে আসার সময়ই, তখনো এনক্রিপ্টেড অবস্থায়, সকেটে কপি হয়, আর ডিক্রিপ্ট করা ফলাফল পরে দৃশ্যমান হয় যখন স্ট্যাক তা স্থানীয়ভাবে ডেলিভার করে বা ফরোয়ার্ড করে।

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

যে স্তর বোঝাচ্ছেন তার সঙ্গে ফিল্টার মেলান

tcp port 443-এর মতো একটি এক্সপ্রেশন একটি ভেতরের TCP সংযোগ নির্বাচন করে। বাইরের দিকে, সকেটকে জিজ্ঞাসা করার সময় ওই সংযোগ ইতিমধ্যেই ESP হয়ে গেছে, তাই ফিল্টারটি কিছুই মেলায় না। আপনি যদি সুরক্ষিত ট্র্যাফিক গুনতে চান, বরং বাইরের রূপে ফিল্টার করুন: কাঁচা ESP-এর জন্য প্রোটোকল 50, অথবা NAT ট্রাভার্সাল থাকলে UDP পোর্ট 4500। দুটি ফিল্টারই এমন প্যাকেট সংখ্যা দেয় যা দুই পিয়ারের মধ্যে তুলনা করা যায়, আর সাধারণত গোনার কারণও সেটাই। তাদের কোনোটিই বলে না ভেতরের অনুরোধের উত্তর দেওয়া হয়েছিল কি না।

UDP 4500-এর সংখ্যাকে ESP প্যাকেটের সংখ্যা হিসেবে ধরবেন না। IKE ওই পোর্টটি NAT-T কিপঅ্যালাইভ এবং এনক্যাপসুলেটেড বিনিময়ের জন্যও ব্যবহার করে, তাই সংখ্যাটিতে এমন ট্র্যাফিকও থাকে যা আপনি মাপতে চাওয়া ডেটা নয়। UDP 500-এ প্রাথমিক IKE বিনিময়ের জন্য আলাদা ফিল্টার দরকার, যদি প্রশ্নটি সেটাই হয়। নিয়ন্ত্রণ ট্র্যাফিকের সঙ্গে ডেটা মেশানো কোনো সংখ্যা যেকোনো ব্যান্ডউইথ অনুমানকেও অজানা পরিমাণে ভুল করে দেয়। আলাদা গণনা আলাদা প্রশ্নের উত্তর দেয়।

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

রূপান্তরের আগে দেখুন, পরে নয়

আপনার যদি বহির্গামী প্লেইনটেক দেখা দরকার হয়, পর্যবেক্ষণ বিন্দুটি আরও আগে, IPsec আউটপুট প্রসেসিংয়ের আগে সরিয়ে নিন। NFLOG আপনাকে একটি Netfilter হুক দেয় যেখানে একটি নিয়ম নির্বাচিত প্যাকেট ব্যবহারকারী-স্পেস সকেটে কপি করতে পারে, যা tcpdump পড়তে পারে। strongSwan-এর ট্র্যাফিক-ডাম্প গাইড ঠিক এই কারণেই এই পদ্ধতিটি নথিভুক্ত করে।

পলিসি ম্যাচ নিয়মটিকে কেবল সেই ট্র্যাফিকে সীমিত করে যা একটি টানেলে ঢোকার পথে আছে। -m policy --pol ipsec --dir out-ই নিয়মটিকে নির্দিষ্ট করে, বক্সের পাঠানো প্রতিটি প্যাকেট লগ করার বদলে। তারপর লগ গ্রুপটি সীমিত ক্যাপচার দিয়ে পড়ুন: ছোট স্ন্যাপশট সংখ্যা এবং একটি আকারসীমা ডায়াগনস্টিকটিকে ট্র্যাফিক আর্কাইভে পরিণত হতে দেয় না। সীমিত ক্যাপচার কোনো পর্যালোচকের কাছে হস্তান্তর করাও সহজ, অপ্রাসঙ্গিক পেলোড টেনে না নিয়ে। কত এসেছে তা দেখার পরে নয়, শুরু করার আগেই সংখ্যাটি ঠিক করুন।

iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'

প্রবাহের সঙ্গে মিলিয়ে হুকটি বেছে নিন। OUTPUT গেটওয়ে নিজে যে ট্র্যাফিক তৈরি করে তা কভার করে; একটি LAN ক্লায়েন্ট থেকে ট্রানজিট এর বদলে FORWARD চেইনের মধ্য দিয়ে যায়, আর OUTPUT-এ থাকা নিয়ম তা কখনো দেখবে না। উপরের ঠিকানা ও পোর্ট একটি অনুমোদিত পরীক্ষামূলক গন্তব্যের জন্য প্লেসহোল্ডার।

পর্যবেক্ষণ কী প্রমাণ করে

NFLOG একটি লগিং টার্গেট, গ্রহণের সিদ্ধান্ত নয়। সেখানে একটি প্যাকেট দেখা মানে এটি হুকে পৌঁছেছে এবং নিয়মের সঙ্গে মিলেছে। এর অর্থ এই নয় যে পরের ফিল্টার এটি অনুমোদন করেছে, ডিভাইসটি এটি পাঠিয়েছে, বা পিয়ার কিছু পেয়েছে।

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

আরেকটি ফাঁদ: এই প্রসঙ্গে «প্লেইনটেক» মানে IPsec এনক্রিপশন স্তরের বাইরে। ভেতরের একটি HTTPS সেশনও নিজের TLS রাখে। ডিক্যাপসুলেট করা প্যাকেট ক্যাপচার করলে অ্যাপ্লিকেশনের TLS ডিক্রিপ্ট হয় না, আর সেখানে পড়ার মতো HTTP দেখলে বোঝায় অ্যাপ্লিকেশনটি শুরু থেকেই HTTPS ব্যবহার করছিল না।

পরিষ্কার করুন এবং দুই প্রান্ত তুলনা করুন

পর্যবেক্ষণ শেষ হলে আপনি যে নিয়মটি ঢুকিয়েছিলেন ঠিক সেটিই, তার মালিক অনুযায়ী, সরিয়ে ফেলুন। লগিং নিয়ম রেখে দিলে প্রতিটি মেলা প্যাকেটে CPU খরচ হয় এবং নীরবে ডেটা ধরে রাখার সমস্যা তৈরি হয়। আপনার নয় এমন চেইন ফ্লাশ না করে -D দিয়ে নিয়মটি পুনরাবৃত্তি করে মুছুন।

iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5

যদি স্থাপনাটি ব্যবহারকারী-স্পেস IPsec, XFRM ইন্টারফেস বা হার্ডওয়্যার অফলোড ব্যবহার করে, পর্যবেক্ষণ বিন্দুগুলো সরে যায় এবং এই রেসিপিটি আদৌ প্রযোজ্য নাও হতে পারে। libipsec-এর সঙ্গে ভেতরের ট্র্যাফিক দেখার নথিভুক্ত জায়গা হলো TUN ডিভাইস। আগে পথটি চিহ্নিত করুন, তারপর প্রশ্নের উত্তর দেয় এমন বিন্দু বেছে নিন, এবং দুটি দিক কেবল তখনই আলাদা দেখাবে যখন আপনি রূপান্তরের ভুল দিকে তাকিয়ে আছেন।