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

کسی کنٹرول کو چھونے سے پہلے ٹریفک کردار کا نام لیں

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

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

Traffic roleControl that decides itWhere it lives in the configSymptom when it is wrong
A client reaching a listener on the routerInput policy of the zone that carries the connection, or a rule for the portoption input in the zone stanza, or a named ruleThe handshake never completes and the tunnel log says nothing
A tunnel client reaching the router itselfInput policy of the tunnel zoneoption input in the VPN zoneA ping to the gateway fails
A tunnel client reaching another LAN hostForwarding from the tunnel zone to the LAN zoneconfig forwarding plus the zone assignmentThe gateway answers and the file share times out
The router's own traffic leaving the WANOutput policy, and translation if the far side needs itoption output and option masqThe tunnel never establishes, or replies vanish

روٹر پر سننے والے کو ایک تنگ اِن پٹ قاعدہ درکار ہے

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

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

config zone
    option name 'wan'
    option input 'REJECT'
    option forward 'REJECT'
    option output 'ACCEPT'
    option masq '1'

config rule
    option name 'allow-openvpn'
    option src 'wan'
    option proto 'udp'
    option dest_port '1194'
    option target 'ACCEPT'

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

fw4 check
service firewall reload

کلائنٹ کی درخواست اِن پٹ سے نہیں، فارورڈنگ سے گزرتی ہے

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

خود روٹر تک پہنچنا اب بھی اِن پٹ راستہ استعمال کرتا ہے، اسی لیے گیٹ وے کو ping اس کے پیچھے کی فائل شیئرنگ کے بارے میں کچھ نہیں بتاتا۔ وہ دو ناکامیاں الگ بلاکس میں رہتی ہیں اور الگ تبدیلیوں سے درست ہوتی ہیں۔ دونوں میں سے کوئی بھی بدلنے سے پہلے دونوں راستے الگ لکھیں۔

ماسکریڈنگ روٹنگ کا فیصلہ ہے، اجازت نہیں

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

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

اجازت شدہ اور مسترد درخواست سے فیصلہ ثابت کریں

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

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

nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'

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

متعلقہ مضامین