nftables cgroup بائی پاس کے لیے ماخذ ایڈریس کی درستی بھی ضروری ہے

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

تین فیصلے، ایک نہیں

درجہ بندی بتاتی ہے کس کو استثنا ہے۔ روٹنگ بتاتی ہے نشان زد پیکٹ اس کی بجائے کہاں جاتا ہے۔ ماخذ کا انتخاب بتاتا ہے دور والا سرا کیا دیکھے گا اور جواب کہاں واپس آنا چاہیے۔

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

ترتیب بھی اہم ہے۔ درجہ بندی پیکٹ بننے پر ہوتی ہے، اس کے بعد روٹنگ، اور باہر نکلنے کے مقام پر ترجمہ۔

اگر آپ نہیں بتا سکتے کہ تین مراحل میں سے کون سا خراب ہے، تو آپ ڈیبگ نہیں کر رہے، آپ قواعد دوبارہ ترتیب دے کر امید کر رہے ہیں۔

ایسا cgroup ملائیں جو کل بھی موجود ہو

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

nft list ruleset
systemctl status session.slice 2>/dev/null
cat /proc/self/cgroup

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

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

دوسری تلاش route زنجیر شروع کرتی ہے

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

table inet bypass {
  chain mark {
    type route hook output priority mangle; policy accept;
    socket cgroupv2 level 2 "app.slice" meta mark set 0x1 comment "app bypass"
  }
}
ip rule add fwmark 0x1 lookup 200
ip route add default via 203.0.113.1 dev wlan0 table 200

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

نشان کی قدر جان بوجھ کر منتخب کریں۔ WireGuard بیرونی نقل و حمل ٹریفک کے لیے اپنا fwmark استعمال کرتا ہے، اور اتفاقاً اسی نمبر پر اترنا ٹنل کی اپنی روٹ استثنا میں ایسے طریقوں سے خلل ڈال سکتا ہے جن کی تشخیص تکلیف دہ ہو۔

ماخذ ایڈریس روٹ کی پیروی نہیں کرتا

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

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

تنگ درستی وہ ماخذ ترجمہ قاعدہ ہے جو اس ایپلیکیشن کے نشان اور اس کے حقیقی آؤٹ پٹ انٹرفیس تک محدود ہے، پہلے سے موجود NAT کے ساتھ ضم ہے، اسے بدلتا نہیں:

table inet bypass {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    meta mark 0x1 oifname "wlan0" masquerade
  }
}

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

اب بھی استثنا سے کیا بچتا ہے

ناموں کا حل کسی دوسرے cgroup میں الگ resolver عمل سے آ سکتا ہے، اس لیے براؤزر کے ساکٹ کی درجہ بندی اس کی تلاشوں کی نہیں ہوتی۔ اگر resolver کے سوالات ٹنل میں رہیں اور کنکشن اس سے باہر جائے، تو split-horizon جوابات راستے سے میل نہیں کھا سکتے۔ یہ اختلاف ایسی خرابیاں پیدا کرتا ہے جو DNS بگز جیسی دکھتی ہیں مگر نہیں ہیں۔

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

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