ہر VPN کلائنٹ پول کے لیے ایک منزل رینج بلاک کریں
ایک nftables قاعدہ گیٹ وے کی اپنی ٹریفک کو چھوئے بغیر منظور شدہ VPN پول کے لیے منزل کا سابقہ مسترد کر سکتا ہے۔ ہُک اور پوزیشن کو ملائیں۔
ایک قاعدہ منظور شدہ VPN پول کو منزل کی رینج سے دور رکھ سکتا ہے، گیٹ وے کے کسی اور کام میں خلل ڈالے بغیر۔ قاعدہ بذات خود مختصر ہے؛ یہ کام کرے گا یا نہیں یہ وہ ہُک طے کرتا ہے جس میں یہ رہتا ہے اور زنجیر میں اس کی پوزیشن۔ ان دونوں میں غلطی ہو تو ایسا فائر وال ملتا ہے جو درست دکھتا ہے اور غیر مستقل برتاؤ کرتا ہے۔ جب قاعدہ پیکٹ کو دیکھتا ہے تو پیکٹ کیا کر رہا ہے، وہاں سے شروع کریں۔
قاعدہ دراصل کیا ملتا ہے
قاعدہ بیک وقت تین چیزوں کو ملاتا ہے: ان پٹ انٹرفیس، ماخذ سابقہ اور منزل کا سابقہ۔ ڈراپ لاگو ہونے سے پہلے تینوں درست ہونے چاہئیں، اور یہی اسے تنگ رکھتا ہے۔ اسے ایک اظہار کے طور پر پڑھنا تین الگ پالیسیوں کی نسبت آسان ہے۔
انٹرفیس کی مطابقت ہی فارورڈ شدہ کلائنٹ ٹریفک کو گیٹ وے کے اپنے کنکشنز سے الگ کرتی ہے۔ اس کے بغیر، صرف ماخذ پول کا نام لینے والا قاعدہ گیٹ وے کی طرف سے اسی پتے سے بنائے گئے پیکٹوں کو بھی متاثر کرے گا، اگر ایسا کبھی ہو۔ ماخذ سابقہ پالیسی کو منظور شدہ کلائنٹس تک محدود کرتا ہے، اور منزل کا سابقہ اسے ایک رینج تک۔ قاعدہ کو فہرست نہیں، تقاطع کے طور پر پڑھیں۔
کچھ بھی تبدیل کرنے سے پہلے تین قدریں لکھیں: ٹنل انٹرفیس کا نام، وہ پول جو سرور تقسیم کرتا ہے، اور وہ سابقہ جسے آپ مسترد کرنا چاہتے ہیں۔ ان میں سے کسی میں ٹائپو ہو تو ایسا قاعدہ بنتا ہے جو صاف پارس ہوتا ہے مگر کچھ محفوظ نہیں کرتا۔ وہ تین قدریں قاعدے کے پاس تبدیلی کے ریکارڈ میں رکھیں۔
ہُک طے کرتا ہے کہ قاعدہ کس پر لاگو ہوتا ہے
netfilter زنجیر ایک ہُک سے منسلک ہوتی ہے، اور ہُک ہی طے کرتا ہے کہ زنجیر کون سے پیکٹ دیکھتی ہے۔ forward ہُک گیٹ وے کے ذریعے روٹ ہونے والی ٹریفک دیکھتا ہے، اور کلائنٹ سے منزل تک کی ٹریفک یہی ہے۔ زنجیر میں باقی سب کسی اور سامعین کی طرف ہے۔
input ہُک گیٹ وے کو ہی مخاطب ٹریفک دیکھتا ہے، لہٰذا وہاں رکھا قاعدہ گزرگاہ کے بجائے اس کی اپنی خدمات تک رسائی کنٹرول کرتا ہے۔ output ہُک گیٹ وے کی طرف سے پیدا کردہ ٹریفک دیکھتا ہے، جو کلائنٹ پول پالیسی کی ضرورت کے برعکس ہے۔ زنجیروں کے نام من مانی لیبل ہیں جو قواعد لکھنے والے نے چنے، لہٰذا نام سے ہُک کا اندازہ نہ لگائیں۔ زنجیر کہاں منسلک ہے یہ دیکھیں، پھر اندازہ لگائیں کہ یہ کیا مل سکتی ہے۔
| Hook | Traffic it sees | Right for this policy |
|---|---|---|
| input | Addressed to the gateway | No, that is the host's own services |
| forward | Routed through the gateway | Yes, for client-to-destination traffic |
| output | Generated by the gateway | No, that is the opposite direction |
منسلکہ پڑھنا ایک سطر کی جانچ ہے جو قاعدے کو ایسی زنجیر میں گرنے سے روکتی ہے جو پیکٹ کو کبھی نہیں دیکھتی۔
وسیع accept سے پہلے قاعدہ رکھیں
قواعد ترتیب سے جانچے جاتے ہیں، اور پہلا فیصلہ جیتتا ہے۔ زنجیر میں پہلے والا وسیع accept ان پیکٹوں کے لیے جانچ ختم کر دیتا ہے جنہیں وہ ملتا ہے، لہٰذا بعد میں شامل کیا گیا ڈراپ ان کے لیے کبھی نہیں چلتا۔ یہی ترتیب کا قاعدہ درست دکھنے والے قاعدے کے بے اثر ہونے کی پوری وجہ ہے۔
قاعدہ آخر میں شامل کرنے کے بجائے accept سے پہلے داخل کریں۔ اگر زنجیر میں ٹنل انٹرفیس کے لیے پہلے سے عام accept موجود ہے، تو نیا قاعدہ اس سے پہلے ہونا چاہیے، ورنہ وہ محض آرائش ہے۔ نتیجے میں آنے والی ترتیب دیکھیں، وہ فائل نہیں جو آپ نے ترمیم کی، کیونکہ کئی فائلوں سے جوڑا گیا قواعد کا مجموعہ شاید کسی ایک سے بھی نہ ملے۔ پھر پول سے آنے والے آزمائشی پیکٹ سے تصدیق کریں۔
sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.confتیسری ہدایت فائل کو لاگو کیے بغیر پارس کرتی ہے، جو نحو کی غلطیاں خلل بننے سے پہلے پکڑ لیتی ہے۔ رول بیک منصوبے کے ساتھ لاگو کریں، کیونکہ forward زنجیر میں غلط قاعدہ اس ٹنل کو کاٹ سکتا ہے جس پر آپ کام کر رہے ہیں۔
موجودہ بہاؤ آپ کے نئے قاعدے کی پروا نہیں کرتے
قاعدے کے وجود سے پہلے بنایا گیا conntrack اندراج پہلے والے accept سے ملتا رہتا ہے۔ اسی لیے نیا ڈراپ کبھی نئے کنکشنز کے لیے کام کرتا دکھتا ہے اور جس کی جانچ ہو رہی ہے اس کے لیے کچھ نہیں کرتا۔
زنجیر کے سرے پر حالت کی مطابقت پڑھیں۔ اگر یہ آپ کے قاعدے سے پہلے established اور related ٹریفک قبول کرتا ہے، تو ہر جاری بہاؤ بند ہونے تک بہتا رہتا ہے۔ ہنگامی قاعدے کے لیے عام طور پر یہی برتاؤ مطلوب ہوتا ہے، اور جب آپ فوری کٹوتی کی توقع کریں تو یہ الجھن دیتا ہے۔ تعیناتی سے پہلے طے کریں کہ کون سا اثر چاہیے۔ کھلے کنکشن کو دوبارہ استعمال کرنے والا امتحان آپ کو غلط کہانی سنائے گا۔
sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'پہلی ہدایت دکھاتی ہے کہ بہاؤ ہے یا نہیں، اور دوسری دکھاتی ہے کہ پہلے والا حالت قاعدہ اسے قبول کرتا رہتا ہے یا نہیں۔ دونوں صرف پڑھنے کے لیے ہیں اور واقعے کے دوران چلانا محفوظ ہے۔
یہ قاعدہ کیا نہیں ہے
قاعدہ ڈومین کی کالی فہرست، IPv6 پالیسی یا کسی ایک ایپلیکیشن اکاؤنٹ پر پابندی نہیں ہے۔
ان میں سے ہر ایک کو اپنا طریقہ کار چاہیے۔ ڈومین بلاک کو نام حل کرنے پڑتے ہیں، جو پیکٹ فلٹر نہیں کرتا۔ IPv6 ٹریفک کو اپنی مطابقت چاہیے، کیونکہ ip اظہار ip6 پیکٹوں کے بارے میں کچھ نہیں کہتا۔ ایپلیکیشن سطح کی پابندی سابقہ مطابقت کی نہیں، خدمت یا تصدیق شدہ پراکسی کی ہے۔ ان ضروریات کو الگ رکھنا ہی ایک تنگ قاعدے سے چار کام مانگنے سے روکتا ہے۔
یہ قاعدہ جو معاہدہ دیتا ہے وہ درست ہے: منظور شدہ پول سے ایک منزل کے سابقے تک ٹریفک مسترد ہوتا ہے، جبکہ غیر متعلقہ گیٹ وے ٹریفک اپنی موجودہ پالیسی برقرار رکھتا ہے۔ وہ جملہ قاعدے کے پاس لکھیں، اور اگلا شخص جان جائے گا کہ یہ کس لیے تھا۔