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 ڈیوائس ہے۔ پہلے راستہ پہچانیں، پھر وہ مقام چنیں جو سوال کا جواب دیتا ہے، اور توقع کریں کہ دونوں سمتیں صرف اس وقت مختلف دکھیں گی جب آپ تبدیلی کے غلط رخ کو دیکھ رہے ہوں۔