VPN روٹ یا فائر وال قاعدہ: پیکٹ کون گرا رہا ہے؟

ایک ہی پیکٹ پر دو آزاد فیصلے ہوتے ہیں، اور ان میں سے کوئی بھی درخواست کو خاموشی سے ختم کر سکتا ہے۔ روٹ تلاش ایک انٹرفیس اور اگلا ہاپ منتخب کرتی ہے، پھر پیکٹ فلٹر فیصلہ کرتا ہے کہ یہ امتزاج اجازت یافتہ ہے یا نہیں۔ ٹائم آؤٹ آپ کو بتاتا ہے کہ دونوں میں سے ایک نے انکار کیا، یہ نہیں کہ کس نے۔ مراحل کو ترتیب سے کریں اور مرمت عام طور پر اندازہ رہنا چھوڑ دیتی ہے۔

دو فیصلے، ایک پیکٹ، دو مالک

روٹ تلاش پہلے پالیسی قواعد سے مشورہ کرتی ہے، پھر اس جدول سے جس کی طرف وہ اشارہ کرتے ہیں، اور منزل سے مطابقت رکھنے والا سب سے مخصوص سابقہ منتخب کرتی ہے۔ جس کلائنٹ نے ٹنل روٹ انسٹال کیا ہے وہ اس فیصلے کا مالک ہے، اور فائر وال قاعدے میں کوئی چیز اس کا متبادل نہیں ہو سکتی۔ جب تلاش کسی غیر متوقع جگہ کی طرف اشارہ کرتی ہے، ہر اگلا مرحلہ غلط پیکٹ پر کام کرتا ہے۔

فلٹرنگ الگ ہے۔ Linux میزبان پر netfilter ہکس ٹریفک کو اس بنیاد پر تقسیم کرتے ہیں کہ پیکٹ کس کے لیے ہے: آؤٹ پٹ مشین چھوڑتا ہے، اِن پٹ اسی پر ختم ہوتا ہے، فارورڈ اس میں سے گزرتا ہے۔ جو گیٹ وے VPN کلائنٹس قبول کرتا ہے اور انہیں LAN کی طرف روٹ کرتا ہے اسے فارورڈ راستہ درکار ہوتا ہے، اور یہی وہ زنجیر ہے جسے زیادہ تر ڈیفالٹ ترتیبات خالی چھوڑ دیتی ہیں۔

ماخذ کا انتخاب اسی فیصلے کا حصہ ہے، اور یہیں زیادہ تر عدم مطابقت چھپی ہوتی ہے۔ کرنل باہر جانے والے انٹرفیس سے ماخذ پتہ منتخب کرتا ہے جب تک روٹ کوئی نہ بتائے، اس لیے LAN سب نیٹ کے لیے لکھا گیا فلٹر قاعدہ ٹنل پتے کے ساتھ نکلنے والے پیکٹ سے کبھی مطابقت نہیں رکھتا۔

پڑھیں کہ تلاش نے حقیقت میں کیا منتخب کیا

فیصلے کا اندازہ لگانے کے بجائے اسے چھاپیں۔ نیچے دیا گیا حکم اس روٹ کو حل کرتا ہے جو کرنل اس منزل کے لیے استعمال کرے گا، بشمول انٹرفیس اور وہ ماخذ جسے وہ منتخب کرے گا:

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

VPN کلائنٹس اکثر پالیسی قواعد کو مرکزی جدول سے نیچے ترجیحات پر انسٹال کرتے ہیں، اس لیے صاف مرکزی جدول بذات خود کچھ ثابت نہیں کرتا۔ قواعد کی ترجیحات کا ان جدولوں سے موازنہ کریں جنہیں وہ منتخب کرتے ہیں، اور دیکھیں کہ ٹنل روٹ ایک بار ہاتھ سے شامل کیے جانے کے بجائے دوبارہ جڑنے کے بعد بھی قائم رہتا ہے یا نہیں۔

پالیسی پر مبنی IPsec ایک تیسرا مطابقت مرحلہ شامل کرتا ہے جسے روٹنگ محیط نہیں کرتی، جیسا کہ strongSwan کے فارورڈنگ نوٹس ٹنل اور ٹرانسپورٹ ترتیبات کے لیے بیان کرتے ہیں۔ سیکیورٹی پالیسی ٹریفک کو سابقہ اور پروٹوکول کے مطابق منتخب کرتی ہے، جبکہ روٹ صرف یہ طے کرتا ہے کہ غیر محفوظ پیکٹ کہاں جائے گا۔ جو سب نیٹ روٹ ہوتا ہے مگر اس کا مطابق منتخب کنندہ نہیں ہوتا وہ یا غیر محفوظ رہتا ہے یا ترتیب کے مطابق پھینک دیا جاتا ہے، اور دونوں نتائج میں سے کوئی فائر وال مسئلے جیسا نہیں لگتا۔ پالیسی چھاپیں اور اس کے منتخب کنندگان کا ان سابقوں سے موازنہ کریں جنہیں ٹنل لے کر جائے گا آپ نے توقع کی تھی۔

فلٹرنگ ہک پر لاگو ہوتی ہے، روٹ پر نہیں

جو قاعدہ VPN سننے والے کو اجازت دیتا ہے وہ خود گیٹ وے سے مخاطب ٹریفک کے بارے میں قاعدہ ہے۔ یہ اس گیٹ وے کے پیچھے میزبانوں تک پہنچنے والے کلائنٹس کے بارے میں کچھ نہیں کہتا، کیونکہ فارورڈ شدہ ٹریفک ایک اور زنجیر سے گزرتا ہے۔ قواعد کے مجموعے کو ایک ہموار فہرست کے طور پر پڑھنا ہی وہ عام وجہ ہے کہ درست دکھنے والا قاعدہ کبھی فعال نہیں ہوتا۔

شمار کنندگان سوال جلد طے کر دیتے ہیں۔ صفر پیکٹ گنتی والے قاعدے تک کبھی نہیں پہنچا گیا، جو غلط زنجیر، غلط انٹرفیس یا پہلے کی پھینک کی طرف اشارہ کرتا ہے۔ پھینکنے کی پالیسی کے تحت بڑھتی گنتی والا قاعدہ وہی حد ہے جسے آپ تلاش کر رہے تھے، اور پیکٹ غلط روٹ ہونے کے بجائے پھینکا جا رہا ہے۔

کلائنٹ جو راستہ استعمال کرتا ہے اسی سے ایک پروب بھیجیں

خود گیٹ وے پر چلائے گئے ٹیسٹ گیٹ وے کے اپنے ماخذ پتے کے ساتھ آؤٹ پٹ اور اِن پٹ سے گزرتے ہیں۔ یہ کلائنٹ کی فارورڈ شدہ درخواست سے مختلف راستہ ہے، اس لیے کامیاب مقامی curl دکھنے سے کم ثابت کرتا ہے۔ جس مشین پر ناکامی ہو وہاں سے جانچیں، یا انٹرفیس اور ماخذ کو واضح طور پر پن کریں۔

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

دونوں سروں پر کیپچر باقی کیسز کو الگ کرتا ہے۔ جو SYN کلائنٹ کو چھوڑ کر کبھی نہیں پہنچتا اس کا مطلب روٹنگ، انکرپشن یا اوپر کی رسائی فہرست ہے۔ جو SYN پہنچ کر جواب نہیں پاتا اس کا مطلب سروس یا اس کا میزبان فلٹر ہے، اور ٹنل کبھی مسئلہ نہیں تھا۔

واپسی ٹریفک اپنی الگ نظر کا حقدار ہے۔ غیر متناسب روٹنگ اور الٹے راستے کی فلٹرنگ غلط انٹرفیس پر آنے والے جوابات کو پھینک دیتی ہے، جو بند پورٹ کے بجائے یک طرفہ کنکشن کے طور پر دکھتا ہے۔ فائر وال کو ایسی علامت کا ذمہ دار ٹھہرانے سے پہلے sysctl قدر چیک کریں جو اس نے پیدا نہیں کی۔

لاگنگ پہلا قدم نہیں بلکہ دوسری رائے کے طور پر کام کرتی ہے۔ فارورڈ زنجیر پر ایک عارضی لاگ بیان انٹرفیس اور پتوں کے نام بتاتا ہے جنہوں نے اسے مارا، اور بعد میں ہٹانا آسان ہے۔ اسے مستقل چھوڑ دیں تو آپ نے جواب کے بجائے لاگ حجم کا مسئلہ بنا لیا۔

ہر تبدیلی کو وہاں رکھیں جہاں وہ دوبارہ جڑنے کے بعد قائم رہے

ip route add سے شامل کردہ روٹ تب تک زندہ رہتا ہے جب تک انٹرفیس نیچے نہ جائے۔ اسے اس کے بجائے کنکشن پروفائل میں محفوظ کریں: NetworkManager کنکشن پر اضافی روٹس قبول کرتا ہے، اور netplan انہیں بوٹ کے درمیان رکھتا ہے۔ یہی قاعدہ کلائنٹ کی طرف فائر وال استثنا پر بھی لاگو ہوتا ہے، جو اگلی دوبارہ لوڈنگ کے بعد غائب ہو جاتا ہے۔

سرور کی طرف کے قواعد اس ترتیب فائل میں ہوتے ہیں جو سروس شروع ہونے پر لوڈ کرتی ہے، نہ کہ اس انٹرایکٹو سیشن میں جو آپ کے بند کرنے پر ختم ہوتا ہے۔ قاعدہ لکھیں، دوبارہ لوڈ کریں، اور تصدیق کریں کہ شمار کنندہ ہلا، کیونکہ نحو کو مسترد کرنے والی دوبارہ لوڈنگ پرانے قواعد کے مجموعے کو خاموشی سے اس کی جگہ پر چھوڑ دیتی ہے۔

پھر اصل ایپلیکیشن درخواست کو شروع سے آخر تک دہرائیں اور ریکارڈ کریں کہ کون سی پرت بدلی۔ جس روٹ مرمت کو فلٹر تبدیلی کی بھی ضرورت تھی وہ پھر بھی ناکام ہوگی، اور پہلی کے چلے جانے کا علم ہونے کے بعد دوسری ناکامی پڑھنا بہت آسان ہے۔ نتیجے کے ساتھ تاریخ اور کلائنٹ ورژن لکھیں، کیونکہ روٹنگ اور فلٹرنگ کے ڈیفالٹ ورژنوں کے درمیان بدلتے ہیں۔ وہ نوٹ ٹکٹ پر رکھیں تاکہ اگلا شخص دو مرحلوں کا سفر دہرانے کے بجائے وہیں سے شروع کرے جہاں آپ رکے تھے۔