UFW قواعد کے ساتھ OpenVPN گیٹ وے کو ایک LAN تک محدود رکھیں

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

پہلے ٹوپولوجی اور اجازت لکھیں

مثال استعمال کرتی ہے صارف کے دائرے میں TUN آلے کو کہا جاتا ہے والا Community OpenVPNtun0 سرور، کلائنٹ پول 10.77.0.0/24, اور ایک منسلک ذیلی نیٹ ورک 192.168.60.0/24 lan0 پر۔ IPv4 فارورڈنگ پہلے ہی کام کرتی ہے اور LAN کا پول کی طرف واپسی راستہ پہلے ہی موجود ہے، اس لیے یہاں کچھ بھی ان دونوں کے درمیان ترجمے پر منحصر نہیں۔

اس ہوسٹ پر فائر وال UFW کی ملکیت ہے، اور کوئی کنٹینر قواعد کا مجموعہ یا الگ nftables جدول پہلے کا منظوری راستہ نہیں بنا سکتا۔ فلٹر کو نظر انداز کرنے والا فلو آف لوڈ شارٹ کٹ گارڈ زنجیروں کو محض سجاوٹ بنا دے گا، اس لیے یقینی بنائیں کہ کوئی بھی فعال نہیں۔ OpenVPN کی اپنی client-to-client فارورڈنگ بند رکھیں، کیونکہ وہ ہم مرتبہ آمدورفت جو کبھی آپریٹنگ سسٹم کے فلٹر سے نہیں گزرتی اس سے محدود نہیں کی جا سکتی۔ بیرونی سامع اور انتظامی قواعد جیسے ہیں ویسے رہتے ہیں، کیونکہ یہ تبدیلی فائر وال کو بدلنے کے بجائے ڈکرپٹ شدہ ٹنل آمدورفت کو کنٹرول کرتی ہے۔

گارڈز کو UFW کی ابتدائی منظوریوں سے پہلے رکھیں

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

فائل کے *filter حصے میں /etc/ufw/before.rules, موجودہ اعلانات کے ساتھ اور کسی بھی قاعدہ لائن سے پہلے دو زنجیریں اعلان کریں۔

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

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

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

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

پڑھیں کہ ہر گارڈ کیا گزرنے دیتا ہے اور کیا مسترد کرتا ہے

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

ہم مرتبہ پیکٹ tun0 میں داخل ہوتا ہے اور اس سے نکلتا ہے، اس لیے منزل کی جانچ تک پہنچنے سے پہلے ہی وہ LAN انٹرفیس ٹیسٹ میں ناکام ہو جاتا ہے۔ LAN سے کلائنٹس کی طرف نئے رابطے بھی جواب کی سمت کے ٹیسٹ میں ناکام ہوتے ہیں، جو بطور طے شدہ الٹا کال بیک راستہ بند کر دیتا ہے۔

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

ذیلی نیٹ ورک کی اجازت دیں اور طرف کے دروازے بند کریں

پہلے راستے کی اجازت کا پیش منظر دیکھیں، پھر لاگو کرنے کے لیے پیش منظر کا جھنڈا ہٹائیں: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. اس کے بعد صارف قواعد کی ترتیب کا جائزہ لیں، کیونکہ پہلے کا انکار اب بھی بعد کی اجازت پر بھاری رہتا ہے۔ پورے ذیلی نیٹ ورک کی اجازت بھی غلط شکل ہے جب صرف ایک ہوسٹ کا HTTPS پورٹ قابل رسائی ہونا چاہیے۔

غور کریں کہ اندراج کا اخراج کیا کرتا ہے: ٹنل کلائنٹس گیٹ وے پر ہی کسی خدمت تک نہیں پہنچ سکتے، بشمول اس کے LAN پتے سے بندھا DNS سامع۔ وہاں DNS کی میزبانی کے لیے اخراج سے پہلے جان بوجھ کر استثنا اور نظر ثانی شدہ اجازت کا معاہدہ درکار ہے۔ اگر UFW IPv6 سنبھالتا ہے، تو tun0 کے لیے before6.rules فائل میں بھی مطابق اخراج شامل کریں، کیونکہ IPv4 منازل کی فہرست IPv6 پیکٹوں کے بارے میں کچھ نہیں کہتی۔

پیش منظر نہیں، لوڈ شدہ پالیسی کی تصدیق کریں

دوبارہ لوڈ کا پیش منظر دیکھیں، اسے دیکھ بھال کی ونڈو میں لاگو کریں، اور زندہ قواعد کا مجموعہ پڑھیں۔

sudo ufw --dry-run reload
sudo ufw show raw

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

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

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