tun0 نہیں ہے؟ nftables میں ڈکرپٹ شدہ IPsec کو meta ipsec سے ملائیں
پالیسی پر مبنی گیٹ وے اب بھی eth0 پر آنے والے صاف اندرونی پیکٹ آگے بھیجتا ہے۔ غائب انٹرفیس نہیں، سیکیورٹی راستہ اور سروس ملائیں۔
آپ ٹنل انٹرفیس کی توقع کرتے ہیں، اسے ڈھونڈتے ہیں، اور فائر وال میں ملانے کے لیے کچھ نہیں ہوتا۔ یہ پالیسی پر مبنی گیٹ وے کے لیے معمول ہے: خفیہ کردہ تبادلہ فزیکل انٹرفیس پر آتا ہے، اور پھر آگے بھیجا جانے والا ڈکرپٹ شدہ اندرونی پیکٹ بھی اسی انٹرفیس پر آتا دیکھا جاتا ہے۔ tun0 نہیں ہے کیونکہ کسی نے اسے بنایا ہی نہیں۔
اندرونی درخواست اب بھی اپنے ماخذ، منزل اور سروس والا الگ پیکٹ ہے، اور کرنل جانتا ہے کہ یہ کس سیکیورٹی انجمن سے نکلا۔ یہی علم ایک فائر وال اصول مل سکتا ہے۔
دو پیکٹ، ایک انٹرفیس
آنے والی سمت کا تصور کریں۔ ESP یا UDP میں لپٹا پیکٹ آتا ہے، کرنل ملنے والی پالیسی ڈھونڈتا ہے، اسے ڈکرپٹ کرتا ہے اور صاف پیکٹ آگے بھیجنے والے راستے کو دیتا ہے۔ صرف انٹرفیس کا نام دیکھنے والا اصول اس پیکٹ کو اسی تار پر آنے والی کسی بھی دوسری ٹریفک سے الگ نہیں کر سکتا۔
اسے الگ کرتا ہے پیکٹ سے جڑا آنے والے سیکیورٹی راستے کا سیاق۔ nftables اسے meta ipsec exists کے طور پر دکھاتا ہے، جو درست ہے جب پیکٹ IPsec سیکیورٹی راستے سے آیا ہو۔ اسے کلائنٹ پول، منزل اور سروس کے ساتھ جوڑیں، اصول محفوظ رہنے کے لیے کافی مخصوص ہو جاتا ہے۔
سیاق چھوڑ دینا عام غلطی ہے، اور یہ ظاہری نہیں سیکیورٹی کی غلطی ہے۔ کلائنٹ پول سے آنے والا سب کچھ قبول کرنے والا اصول مقامی نیٹ ورک سے آیا جعلی پیکٹ بھی اسی خوشی سے قبول کرتا ہے، کیونکہ ماخذ پتہ بذات خود کسی چیز کا ثبوت نہیں ہے۔ ماخذ کو بامعنی بنانے کا سب سے سستا طریقہ سیکیورٹی راستے کا سیاق ہے۔ اصول کو شروع ہی سے اس کے ساتھ لکھیں، آڈٹ کے بعد شامل کرنے کے بجائے۔
آگے بھیجنے کا اصول لکھیں
فرض کریں کہ 10.90.0.0/24 میں کلائنٹ والی تصدیق شدہ IPv4 دور دراز رسائی سروس اور 203.0.113.40 پر ایک منظور شدہ منزل ہے۔ اس بہاؤ کے لیے اصول کا ٹکڑا ایسا دکھتا ہے۔
meta ipsec exists ip saddr 10.90.0.0/24 \
ip daddr 203.0.113.40 tcp dport 443 \
oifname "eth0" counter accept
پتے اور انٹرفیس بدلنے والی مثالیں ہیں۔ جائزہ شدہ متبادل کو آگے بھیجنے کی پالیسی میں اس اصول سے پہلے رکھیں جو بہاؤ کو بصورت دیگر مسترد کرتا، اور اسے نصب کرنے کے لیے موجودہ اصولوں کا مجموعہ خالی نہ کریں؛ گیٹ وے صاف کمرے کا تجربہ نہیں ہے۔
oifname کی اصطلاح رکھنے کے قابل ہے۔ یہ باہر جانے کا فیصلہ درج کرتی ہے اور اصول کو اس سمت میں ملنے سے روکتی ہے جو آپ کا ارادہ نہ تھا، اور یہ انٹرنیٹ تک کئی راستوں والے گیٹ وے پر اہم ہے۔ ایک ہی اپ لنک والے ٹیسٹ باکس پر اصطلاح زائد لگتی ہے، اور اسی لیے باکس کو دوسرا اپ لنک ملنے سے پہلے یہ ہٹا دی جاتی ہے۔
بیرونی تبادلے کی اجازتیں الگ ہیں۔ گیٹ وے کے ان پٹ راستے کو وہ IKE اور ESP یا UDP لپیٹنے والے پورٹ درکار ہیں جو یہ واقعی استعمال کرتا ہے، اور یہ اجازتیں اندر کے ڈکرپٹ شدہ پیکٹ کے بارے میں کچھ بھی اجازت نہیں دیتیں۔ دونوں کو ملانا وہ راستہ ہے جس سے چلتا ہوا ٹنل ہر چیز آگے بھیجنے والی فائر وال کے ساتھ ختم ہوتا ہے۔
آنے والا سیاق جانے والا سیاق نہیں ہے
اسی اظہار کا خاندان دوسری سمت کو rt ipsec سے ڈھکتا ہے، جو اس جانے والی سیکیورٹی انجمن کو بیان کرتا ہے جو پیکٹ استعمال کرے گا۔ یہ مختلف سوال کا جواب دیتا ہے: یہ نہیں کہ یہ پیکٹ کہاں سے آیا، بلکہ یہ کہ اگلے حصے میں یہ محفوظ رہے گا یا نہیں۔
یہ فرق اس گیٹ وے پر اہم ہے جو ایک ٹنل ختم کرتا ہے اور ساتھ ہی دوسری میں آگے بھیجتا ہے۔ پیکٹ ڈکرپٹ ہو کر آ سکتا ہے اور پھر بھی اسے انکرپٹ ہو کر جانا پڑ سکتا ہے، اور صرف آنے والے سیاق کے لیے لکھی گئی اجازت جانے والی شرط کے بارے میں کچھ نہیں کہتی۔ اگر پالیسی وہ تحفظ مانگتی ہے، تو اصولوں کے مجموعے کو یہ ظاہر کرنا چاہیے، روٹنگ سنبھال لے گی سمجھنے کے بجائے۔
دونوں سوال الگ اصولوں میں رکھیں تاکہ قاری دیکھ سکے کہ کون سا نافذ ہے۔ دونوں کی جانچ کرنے والا ایک ہی ہوشیار اصول جائزہ لینے میں مشکل ہے اور جب اس کا آدھا ملنا بند کر دے تو ڈیبگ کرنا کہیں زیادہ مشکل ہے۔ کاؤنٹر والے دو اصول یہ بھی بتاتے ہیں کہ کون سی شرط ناکام ہو رہی ہے، جو ایک مشترکہ اصول کبھی نہیں کرے گا۔
NAT فائر وال کا فیصلہ نہیں ہے
نجی کلائنٹ پول سے انٹرنیٹ کی طرف جانے والی ٹریفک کو عام طور پر ماخذ ترجمہ چاہیے تاکہ جواب واپسی کا راستہ پا سکے۔ لیکن دوسری جانے والی IPsec پالیسی کے لیے چنی گئی ٹریفک کو اپنی مطلوبہ استثنا برقرار رکھنی ہوتی ہے، اور اگلے تحفظ کے فیصلے کے بارے میں سوچے بغیر ہر نجی ماخذ کو ماسک کرنا اسے توڑ دیتا ہے۔
NAT زنجیر کے اندر اجازت بھی عام اجازت نہیں ہے۔ NAT اور فلٹرنگ کے کام الگ ہیں، اور NAT زنجیر قائم شدہ بہاؤ کے ہر بعد والے پیکٹ کی جانچ نہیں کرتی، اور اسی لیے تحفظ کے لیے اس پر بھروسا کرنا ایسے اصول بناتا ہے جو ٹیسٹ میں کام کرتے دکھتے ہیں اور بوجھ تلے ناکام ہوتے ہیں۔
الٹا بھی سچ ہے اور لوگوں کو حیران کرتا ہے: ایک فلٹر بنیادی زنجیر میں کہیں اجازت دوسری لاگو زنجیر میں بعد کی تردید کے سامنے کوئی وزن نہیں رکھتی۔ نتیجہ ترتیب اور زنجیر کا دائرہ طے کرتے ہیں، فائل میں اجازت کا ہونا نہیں۔
درست اندرونی سروس کی تصدیق کریں
آپ نے جس مخصوص منزل اور پورٹ کی اجازت دی ہے اسے حقیقی کلائنٹ سے پرکھیں اور تصدیق کریں کہ جواب واپس آتا ہے۔ پھر کوئی ایسی چیز پرکھیں جس کی اجازت آپ نے نہیں دی اور دیکھیں کہ وہ گزرتی نہیں، کیونکہ بہت چوڑا اصول بھی پہلا ٹیسٹ صحیح اصول کی طرح اچھی طرح پاس کرتا ہے۔ جو درخواست کبھی کلائنٹ سے نکلتی ہی نہیں وہ بھی فائر وال کا نتیجہ نہیں ہے، اس لیے کاؤنٹر پڑھ کر دیکھیں کہ پیکٹ کا اندازہ ہوا بھی یا نہیں۔ دو ٹیسٹ اور ایک کاؤنٹر پڑھنا آپ کو اصولوں کا مجموعہ پڑھنے میں گزاری پوری دوپہر سے زیادہ بتائیں گے۔
nftables حوالہ meta ipsec، rt ipsec اور سمت کے لیے مخصوص اظہارات کی دستاویز کرتا ہے، اور آپ کے نصب شدہ ورژن کے ساتھ نحو جانچنے کی جگہ وہی ہے۔ اور دائرہ واضح رکھیں: یہ IPv4 کی مثال ہے، یہ IPv6 کے بارے میں کچھ نہیں کہتی، اور یہ من مانی عوامی پورٹ آگے بھیجنے کو VPN سروس کا حصہ نہیں بناتی۔