firewalld کے سامع کی قاعدہ اور فارورڈنگ پالیسی: ہر ایک کیا کرتا ہے

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

دو پالیسیاں، ایک ٹنل

بیرونی پالیسی ایک سادہ سوال کا جواب دیتی ہے: کیا اس ماخذ سے آنے والا پیکٹ اس ہوسٹ پر UDP 1194 تک پہنچ سکتا ہے؟ اندرونی پالیسی دوسرے سوال کا جواب دیتی ہے: کیا اس ٹنل کے پیچھے مصدقہ کلائنٹ اس منزل تک، اس پروٹوکول سے، اس پورٹ پر پہنچ سکتا ہے؟ پہلی ساکٹ کے بارے میں ہے، دوسری راستے کے بارے میں، اور firewalld انہیں الگ اشیاء سے ماڈل کرتا ہے کیونکہ وہ الگ مقامات پر طے ہوتی ہیں۔ ایک اس ہوسٹ پر ساکٹ کی خصوصیت ہے، دوسری اس سے گزرنے والے راستے کی۔

عملی نتیجہ یہ ہے کہ کام کرنے والا ٹنل دوسری پالیسی کے بارے میں کچھ نہیں بتاتا، اور درست دوسری پالیسی پہلی کو غیر ضروری نہیں بناتی۔

اصل بیرونی سامع کو اجازت دیں

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

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

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

ڈکرپٹ شدہ منزل کو الگ سے مجاز کریں

VPN سرور پر ہی چلنے والی خدمت سے رابطہ مقامی ان پٹ پالیسی ہے۔ LAN میں کسی دوسرے ہوسٹ کو فارورڈ کیا جانے والا رابطہ فارورڈنگ پالیسی چاہتا ہے، کرنل میں فعال فارورڈنگ اور واپسی کا راستہ — یہ تین الگ تقاضے ہیں جنہیں لوگ اکثر ایک میں ملا دیتے ہیں۔ جدید firewalld پالیسی اشیاء اندرونی اور بیرونی زون کے درمیان ہدایت شدہ ٹریفک بیان کرتی ہیں، اور یہ بتانے کی درست جگہ وہی ہے کہ کون سے VPN ماخذ کون سی نجی خدمات تک پہنچ سکتے ہیں۔

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

انٹرفیس پر بھروسہ کرنا غلط شارٹ کٹ کیوں ہے

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

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

تین چیزیں جانچیں، جن میں ایک انکار بھی

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

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