صرف VPN والا iptables ہوسٹ: tun ڈیوائس کا نام دیں، tun+ نہیں

-o tun+ لکھنا درست ہدایت لگتا ہے اور درحقیقت یہ ایسا وائلڈ کارڈ ہے جو کرنل کی ہر سرنگ سے مطابقت رکھتا ہے۔ دوسرا VPN کلائنٹ، کوئی کنٹینر پل یا کریش ہوئے سیشن کا چھوڑا ہوا انٹرفیس — سب اسے پورا کرتے ہیں، اور پھر ہوسٹ اس ٹریفک کی اجازت دیتا ہے جسے پالیسی روکنے کے لیے لکھی گئی تھی۔ نیچے کا طریقہ ایک ڈیوائس نام مقرر کرتا ہے، استثناؤں کو ایسے ترتیب دیتا ہے کہ سرنگ واقعی بن سکے، اور اگر قواعد بری طرح پڑیں تو واپسی کا راستہ چھوڑ دیتا ہے۔ ہر مرحلہ الگ سے واپس لیے جانے کے قابل حد تک مختصر ہے۔

مرحلہ 1: اب جو قواعد ہیں انہیں لکھ لیں

پہلے سے طے شدہ پالیسی بدلنے سے پہلے موجودہ حالت محفوظ کریں تاکہ واپسی یادداشت نہیں بلکہ حکم ہو۔ iptables-save > /root/iptables.pre ہر جدول کو ایسی فائل میں لکھتا ہے جسے آپ بحال کر سکتے ہیں، اور جب آپ جو پالیسی مقرر کرنے والے ہیں وہ اسے اٹھانے والا کنکشن کاٹ دے تو کھلے root سیشن والا دوسرا ٹرمینل بےجا خوف نہیں ہے۔ اگر آپ دور سے کام کرتے ہیں تو flush بھی ہنگامی سوئچ کے طور پر شیڈول کریں۔

پھر انٹرفیس کی فہرست بنائیں، کیونکہ جو نام آپ نے فرض کیا وہ ایسا نام ہے جو آپ کو پڑھنا چاہیے تھا: ip -br link دکھاتا ہے کہ ابھی کیا موجود ہے، اور سرنگ اس وقت تک ظاہر نہیں ہوگی جب تک وہ اوپر نہ آئے۔ پڑھتے وقت ہی ڈیوائسوں کے نام لکھ لیں۔

مرحلہ 2: سرنگ کو اس کا اپنا نام دیں

OpenVPN کلائنٹ کنفیگریشن میں dev tun_work قبول کرتا ہے، اور پھر Linux tun0 مختص کرنے کے بجائے بالکل اسی نام کا انٹرفیس بناتا ہے۔ جب تک کوئی اور اس پر دعویٰ نہ کرے، نام دوبارہ جڑنے کے دوران مستحکم رہتا ہے، اور ڈیوائس کا نام لینے والے قاعدے کو بامعنی بنانے والی بات یہی ہے۔

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

مرحلہ 3: پالیسی endpoint استثنا پہلے رکھ کر لکھیں

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

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

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

مرحلہ 4: صرف موجودگی نہیں، ترتیب بھی چیک کریں

قواعد ترتیب سے جانچے جاتے ہیں، اس لیے پہلے آنے والا ACCEPT بعد میں شامل کردہ REJECT کو محض چھپا دیتا ہے۔ established اور related کا میل ہی وہ چیز ہے جو آپ کی اپنی جانے والی درخواستوں کے جوابات کو عام آنے والا راستہ کھولے بغیر واپس آنے دیتا ہے، اور اسے سرنگ کی منظوری کے بعد رکھنے کا مطلب ہے کہ گرنے والی سرنگ بھی اپنے انٹرفیس پر واپسی ٹریفک گزرنے دیتی ہے۔

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

مرحلہ 5: اسے بوٹ اور پتہ خاندان دونوں سے گزرنے کے قابل بنائیں

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

پھر IPv6 الگ سے چیک کریں، کیونکہ IPv4 کے لیے اچھی پہلے سے طے شدہ انکار پالیسی دوسرے خاندان کے بارے میں کچھ نہیں کہتی۔ ip -6 route آپ کو بتائے گا کہ ہوسٹ کے پاس کوئی راستہ ہے یا نہیں جو صرف IPv4 سنبھالنے والی سرنگ کے گرد ٹریفک لے جا سکے، اور ip6tables یا nftables کو اپنے مساوی قواعد درکار ہیں۔ قواعد مجموعے کی ہم آہنگی پر بھروسا کرنے کے بجائے IPv6-only منزل کے ساتھ جانچیں۔

مرحلہ 6: تصدیق کریں اور بحالی کے لیے تیار رہیں

سرنگ اوپر لائیں، تصدیق کریں کہ آپ کی مطلوبہ سروس کام کرتی ہے، پھر کوئی ایسی چیز آزمائیں جسے پالیسی کو مسترد کرنا چاہیے۔ اگر جواب آپ کو حیران کرے تو iptables-restore < /root/iptables.pre سے بحال کریں، اور اسی کے بعد قواعد میں ترمیم شروع کریں۔ مستقل مزاجی اور آزمودہ بحالی راستہ ہی اسے ایسی تبدیلی بناتا ہے جو آپ دو بار کر سکتے ہیں۔