آپ کا iptables قاعدہ برج شدہ VPN ٹریفک کو کبھی کیوں نہیں دیکھتا
برج سے گزرنے والے فریم اُس IP چین کو نظرانداز کر سکتے ہیں جس کی آپ نگرانی کر رہے ہیں۔ ایک اور قاعدہ شامل کرنے سے پہلے مقامی bridge خاندان کا پرانے br_netfilter سے موازنہ کریں۔
ایک ہی ہوسٹ پر دو ورچوئل مشینیں برج کے ذریعے LAN تک پہنچتی ہیں، اور ip forward چین میں رکھا قاعدہ ایسا کاؤنٹر دکھاتا ہے جو کبھی نہیں ہلتا۔ فریم حقیقی ہیں، ٹریفک گزر رہی ہے، اور قاعدہ محض اُس کے راستے پر نہیں ہے۔ Linux برج ٹریفک ظاہر کرنے کے دو طریقوں کا موازنہ اِس خاموشی کی وضاحت کرتا ہے، اور یہ بھی بتاتا ہے کہ ایک پرانا ماڈیول لوڈ کرنا اُس سے بدتر جواب کیوں ہے جتنا نظر آتا ہے۔
ایک ہوسٹ سے گزرنے والے دو راستے
پیکٹ اِس ہوسٹ کو دو بالکل مختلف طریقوں سے چھوڑ سکتا ہے، اور یہی فرق طے کرتا ہے کہ کون سے ہُک اُسے دیکھیں گے۔ اگر منزل کسی جسمانی پورٹ کے پار ہے اور فریم برج کے دو پورٹوں کے درمیان سوئچ ہوتا ہے، تو ہوسٹ ایک Ethernet فریم آگے بھیجتا ہے؛ راؤٹنگ کوڈ سے نہیں پوچھا جاتا، اور کوئی روٹ شدہ چھلانگ نہیں ہوتی۔ اگر منزل خود ہوسٹ ہے، یا ٹنل انٹرفیس کے ذریعے پہنچنے والا نیٹ ورک ہے، تو پیکٹ روٹ ہوتا ہے اور IP پرت کے ہُک واقعی لاگو ہوتے ہیں۔ اِس دو شاخی راستے کو یاد رکھیں، کیونکہ چینوں اور خاندانوں کے بارے میں ہر بعد کا سوال اِسی سے نکلتا ہے کہ فریم دو راستوں میں سے کون سا لیتا ہے۔
یہی فرق اُس قاعدے کے پیچھے کی پوری کہانی ہے جو کچھ بھی شمار نہیں کرتا۔ veth9a1 سے enp3s0 تک برج شدہ فریم IP اسٹیک کو نہیں، برج کو عبور کرتا ہے، اِس لیے ip forward چین کو ملانے کے لیے کچھ نظر نہیں آتا۔ پرانی مثال میں انٹرفیس کے نام یہ طے نہیں کرتے کہ آپ کے پاس کون سا راستہ ہے، اور اسی لیے پہلا قدم قواعد کے مجموعے کی بجائے ٹوپولوجی کو دیکھنا ہے۔
ٹنل ایک تیسرا معاملہ شامل کرتا ہے جو نام پانے کے لائق ہے۔ TUN ڈیوائس ہوسٹ کو IP پیکٹ دیتی ہے، اِس لیے وہ روٹ ہوتے ہیں اور واقعی IP چینوں سے گزرتے ہیں، جبکہ برج سے جڑی TAP ڈیوائس فریم دیتی ہے اور برج والے معاملے کی طرح برتاؤ کرتی ہے۔ ڈیوائس کی قسم طے کرتی ہے، مصنوعات کا نام نہیں۔
اُن دو خاندانوں کا موازنہ کریں جو برج شدہ فریم دیکھ سکتے ہیں
Linux nftables کے bridge خاندان کے ذریعے مقامی برج فلٹرنگ کی حمایت کرتا ہے، اور اُڑتی ہوئی فریموں کو جانچ کر گرانے کے لیے اُسے کسی پرانے ماڈیول کی ضرورت نہیں۔ کرنل کی اپنی برج دستاویزات یہی سفارش براہِ راست دیتی ہیں، جسے کسی تلاش کے نتیجے کے آپ کو ماڈیول لوڈ کرنے کہنے سے پہلے جاننا مفید ہے۔
| Observation point | What it sees | What it costs |
|---|---|---|
nftables bridge family chains | Ethernet frames forwarded between bridge ports, in both directions | Rules must be written in bridge syntax with link-layer matches |
Legacy br_netfilter plus an ip chain | Bridged IPv4 and IPv6 packets, re-exposed through IP-layer hooks | Existing host rules may begin matching traffic they never saw before |
inet chain for routed traffic | Packets the host routes, including traffic arriving from a TUN device | No visibility into purely switched frames |
iptables کی بجائے nft کمانڈ استعمال کرنا بذاتِ خود قاعدے کو صحیح خاندان میں نہیں رکھتا۔ bridge خاندان میں اعلان شدہ چین فریم دیکھتی ہے؛ ip، ip6 یا inet میں اعلان شدہ چین اُنہیں نہیں دیکھتی، چاہے اُسے کوئی بھی بائنری بنائے۔ خاندان چین کی خصوصیت ہے، اُس اوزار کی نہیں جس نے اُسے ٹائپ کیا۔
پرانہ راستہ مختلف انداز میں کام کرتا ہے، اور اسی لیے عادت کے تحت طرف چننے کی بجائے موازنہ کرنا چاہیے۔ br_netfilter لوڈ کرنے اور bridge-nf-call ترتیبات فعال کرنے سے برج شدہ IPv4 اور IPv6 ٹریفک دوبارہ IP پرت کے ہُکوں کے ذریعے ظاہر ہوتی ہے، تاکہ ایک عام iptables قاعدہ آخرکار اُس سے میل کھا سکے۔ فریم نہیں بدلتیں؛ اُن ہُکوں کا مجموعہ بدلتا ہے جن سے وہ گزرتی ہیں، یعنی ہر موجودہ ہوسٹ قاعدے کے پاس اب نیا سامعین ہے۔
قاعدہ شامل کرنے سے پہلے مؤثر راستہ پڑھیں
تین کمانڈیں طے کرتی ہیں کہ آپ کہاں ہیں: برج کس سے جڑا ہے، پرانا ماڈیول فعال ہے یا نہیں، اور bridge خاندان میں کون سی چیزیں پہلے سے موجود ہیں۔ کچھ لکھنے سے پہلے اُنہیں چلائیں، کیونکہ جواب ہی طے کرتا ہے کہ آپ دو ڈیزائنوں میں سے کون سا بڑھا رہے ہیں۔ یہ قدم چھوڑ دینا ہی وہ طریقہ ہے جس سے صحیح قاعدہ ایسی چین میں پہنچ جاتا ہے جس سے کچھ نہیں گزرتا۔
bridge link show
lsmod | grep br_netfilter
nft list ruleset | grep -A4 "chain forward"آؤٹ پٹ معاملات کو صاف طور پر الگ کرتا ہے۔ برج کے نیچے درج پورٹ بتاتے ہیں کہ کون سے انٹرفیس سوئچ ہو رہے ہیں؛ خالی lsmod نتیجہ یعنی برج شدہ فریموں کی IP پرت پر کوئی دید نہیں؛ bridge خاندان کی موجودہ forward چین یعنی پالیسی کا مالک پہلے سے ہے اور آپ کا قاعدہ اپنی نئی چین میں نہیں، وہیں جاتا ہے۔
پھر ایک ایسا قاعدہ شامل کریں جو واپس پڑھنے میں آسان ہو، کاؤنٹر کے ساتھ اور فیصلہ بدلے بغیر، اور ایک نمائندہ بہاؤ برج سے گزاریں۔ ہلتا ہوا کاؤنٹر ثابت کرتا ہے کہ فریم قاعدے تک پہنچی۔ صرف اتنا ہی وہ ثابت کرتا ہے، اِس لیے رد شدہ راستے کے ساتھ بھی چلیں، کیونکہ سب کچھ قبول کرنے والی پالیسی بھی ہلتا ہوا کاؤنٹر پیدا کرتی ہے۔
nft add rule bridge filter forward iifname "veth9a1" oifname "enp3s0" counter acceptپرانہ ماڈیول رویہ کہاں بدلتا ہے
چلتی ہوئی برج پر پرانا راستہ فعال کرنا دید شامل کرنے کا غیر جانبدار عمل نہیں ہے۔ جو قواعد پہلے برج ٹریفک کے لیے ناقابلِ رسائی تھے وہ قابلِ رسائی ہو جاتے ہیں، جن میں دوسرے انٹرفیس کے لیے لکھے گئے ہوسٹ قواعد بھی شامل ہیں، اور ip forward چین کی طے شدہ drop پالیسی اچانک اُن فریموں پر لاگو ہو سکتی ہے جو پہلے بغیر چھوئے گزرتی تھیں۔ جس ہوسٹ کا انتظام اُسی برج سے ہوتا ہے، وہاں نتیجہ کنسول کے بغیر لاک آؤٹ ہے۔ یہ کوئی فرضی ناکامی کی حالت نہیں؛ یہ اُس مشین پر ہُکوں کا مجموعہ بڑھانے کا عام نتیجہ ہے جہاں آپ اُسی راستے سے پہنچتے ہیں جو آپ نے ابھی بڑھایا ہے۔
زیادہ محفوظ ترتیب یہ ہے کہ طے کریں کہ پالیسی کس خاندان کی ہے، قواعد وہیں لکھیں، اور کوئی بھی sysctl بدلنے سے پہلے ایک خودمختار بحالی راستہ رکھیں۔ اگر دو خاندان قواعد رکھتے ہیں، تو دستاویز کریں کہ کون سا مستند ہے؛ دو متوازی پالیسیاں ہی وہ طریقہ ہیں جس سے پیکٹ ایک جگہ قبول اور دوسری جگہ مسترد ہوتا ہے، پڑھنے کے لیے ایک بھی فائل کے بغیر۔
الگ تھلگ کرنے کو بھی ابھی مکمل ڈیزائن چاہیے۔ ایک ذریعے کو ایک منزل تک اجازت دینا صرف یہ ثابت کرتا ہے کہ ایک بہاؤ کام کرتا ہے، جبکہ ضرورت عموماً یہ ہوتی ہے کہ VM اپنے پڑوسیوں یا ہوسٹ تک نہ پہنچ سکے۔ مسترد قواعد کے کاؤنٹر قبولیت کے قاعدے کے کاؤنٹر سے زیادہ اہم ہیں، کیونکہ قبولیت کا کاؤنٹر وہی ہے جس کے ہلنے کی آپ پہلے سے توقع کر رہے تھے۔
آخر میں، ہوسٹ اِن پٹ کے معاملے کو الگ رکھیں۔ برج کے اپنے IP پر بھیجی گئی ٹریفک input پر آتی ہے، forward پر نہیں، اور forward کا قاعدہ آپ کوئی بھی خاندان چنیں، اُسے کبھی نہیں دیکھے گا۔ تین معاملے، دو خاندان، ایک سبق: راستہ ہُک طے کرتا ہے، اور ہُک طے کرتا ہے کہ آپ کا قاعدہ ہے بھی یا نہیں۔