nftables OpenVPN کے کلائنٹس کے درمیان ٹریفک کو کیوں نہیں دیکھ سکتا

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

سرور سے ہوکر ایک پیکٹ کا پیچھا کریں

روٹ شدہ سرنگ میں ڈیمون ہر کلائنٹ کا ڈکرپٹ شدہ پیکٹ سرنگ ڈیوائس کو دیتا ہے۔ وہاں سے میزبان اسے روٹ کرتا ہے، فارورڈ ہک چلتا ہے، اور سرنگ ڈیوائس سے ملنے والا قاعدہ ٹریفک گن سکتا ہے یا گرا سکتا ہے۔ زیادہ تر فائر وال مثالوں کا یہی مفروضہ ہے۔

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

کون سا راستہ چلا، یہ طے کرنے والا کاؤنٹر امتحان

جس قاعدے کا اطلاق ہونا چاہیے اس پر کاؤنٹر لگائیں، ان دو کلائنٹس کے درمیان منتقلی چلائیں جنہیں یہ قاعدہ روکنا چاہیے، اور پھر کاؤنٹر پڑھیں۔

sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forward

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

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

سوئچ رسائی فہرست نہیں ہے

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

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

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

فارورڈنگ نقطہ کا انتخاب

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

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

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

قواعد بدلنے سے پہلے کیا جانچنا ہے

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

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