VPN گیٹ وے دوبارہ شروع ہونے کے بعد بھی IPv4 فارورڈنگ برقرار رہے

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

گیٹ وے تک پہنچنا فارورڈنگ جیسا نہیں ہے

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

لکھیں کہ کلائنٹ پیکٹ کس انٹرفیس پر آتا ہے اور اگلا راستہ کس انٹرفیس سے نکلتا ہے۔ دونوں ایک ہی نیم اسپیس کے ہیں، اور اہم ترتیب اسی نیم اسپیس میں ہے۔

قدر وہیں پڑھیں جہاں پیکٹ واقعی ہیں

ہوسٹ نیم اسپیس میں روٹ کرنے والے گیٹ وے پر، ایک ہی کمانڈ سوال کا جواب دیتی ہے: sysctl net.ipv4.ip_forward۔ جب انگریس اور اگلا راستہ کسی نامزد نیم اسپیس میں رہتے ہیں تو اسی نیم اسپیس سے پوچھیں: ip netns exec vpn-gw sysctl net.ipv4.ip_forward۔ ہوسٹ کی قدر نیم اسپیس کی قدر کا متبادل نہیں، اور ہوسٹ پر ایک ہونا کسی چیز کا ثبوت نہیں۔

ہر روٹنگ سیاق میں ایسا لیبل نہیں ہوتا جو آپ ip netns کو دے سکیں۔ کنٹینر رن ٹائم اور سروسز ایسے نیم اسپیس بناتے ہیں جو کبھی دوستانہ نام کے تحت رجسٹر نہیں ہوتے، اور ان کے لیے آپ رن ٹائم کے معائنہ کے اوزار استعمال کرتے ہیں۔ vpn-gw کی جگہ اصل نام یا اسی سیاق تک پہنچنے والا رن ٹائم طریقہ رکھیں، اور ہوسٹ سطح پر اندازہ لگانا بند کریں۔

ترتیب کو ایک ہی مالک دیں

روایتی systemd ہوسٹ گیٹ وے پر، پائیدار شکل منتظم کے منتخب کردہ نام والی drop-in فائل ہے، جیسے /etc/sysctl.d/60-vpn-forwarding.conf، جس میں net.ipv4.ip_forward = 1 ہوتا ہے۔ فائل لکھیں، پھر وہی مخصوص فائل لوڈ کریں تاکہ زندہ حالت بھی بدلے: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf، اور اس کے بعد واپس پڑھ کر جانچیں۔ فائل کا نام مثال ہے، محفوظ VPN راستہ نہیں، اور شروع کا نمبر اہم ہے کیونکہ بعد میں ترتیب دی گئی فائلیں جیتتی ہیں۔

ترجیح وہ جگہ ہے جہاں پائیداری خاموشی سے ٹوٹتی ہے۔ تقسیم کے لوڈر اور اپنی drop-in دونوں جانچیں، کیونکہ procps sysctl --system آخر میں /etc/sysctl.conf بھی پڑھتا ہے، جبکہ systemd کا sysctl.d ترتیب بالکل الگ تسلسل ہے۔ بعد کی تفویض اسی کلید کو فوراً واپس رکھ سکتی ہے، جس سے آپ کی فائل درست مگر مؤثر قدر غلط رہتی ہے۔ اس بحث کو جیتنے کے لیے موجودہ منتظم فائل پر دوبارہ نہ لکھیں؛ مالک تلاش کریں اور وہیں تبدیل کریں۔

بوٹ کے بعد بنایا گیا نیم اسپیس ہوسٹ drop-in سے بالکل کنٹرول نہیں ہوتا۔ اس کی ترتیب اسی کی ہے جو اسے بناتا ہے، چاہے کنٹینر رن ٹائم ہو یا نیم اسپیس کی پروویژننگ یونٹ۔ سوال سے بچنے کے لیے کنٹینر کو وسیع ہوسٹ مراعات دینا درست مالک کی شناخت میں دس منٹ لگانے سے بدتر سودا ہے۔

سوئچ پلٹنے سے پہلے اس کی قیمت جانیں

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

یہ ہر بار کلائنٹ کے ہوسٹ تک نہ پہنچنے پر اسے بند و چالو کرنے کو بھی خارج کرتا ہے۔ اگر قدر پہلے ہی ایک ہے تو خرابی راستے میں کہیں اور ہے، اور اسی کلید کو تیسری بار دوبارہ لکھنے سے وہ ہلے گی نہیں۔

پائیداری ثابت کریں، پھر راستے کا باقی حصہ جانچیں

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

فارورڈنگ فعال ہونے پر بھی تین چیزیں جانچنی باقی رہتی ہیں۔ کلائنٹ کو منزل تک راستہ چاہیے، گیٹ وے کو اگلا راستہ اور اس کے استعمال کی اجازت چاہیے، اور منزل کو کلائنٹ کے ٹنل پتے تک واپسی راستہ چاہیے۔ نجی روٹ شدہ LAN کو خودبخود NAT کی ضرورت نہیں ہوتی، اس لیے تینوں میں سے کون سا غائب ہے یہ جاننے سے پہلے masquerading نہ شامل کریں، اور گیٹ وے سے نہیں بلکہ مطلوبہ کلائنٹ سے جانچیں، کیونکہ گیٹ وے پر پیدا ہونے والی درخواست اس فارورڈنگ راستے کو کبھی نہیں چھوتی جو آپ نے ابھی فعال کیا ہے۔ IPv6 کی اپنی فارورڈنگ اور روٹنگ پالیسی ہے، اس لیے کام کرنے والی IPv4 جانچ اس کے بارے میں کچھ نہیں کہتی۔

drop-in راستہ، نیم اسپیس کا مالک اور واپس پڑھنے والی کمانڈ runbook میں ساتھ رکھیں۔ آگے یہ لینے والے کو قدر پڑھنا، یہ دیکھنا کہ مالک کون ہے، اور ایک منٹ میں فیصلہ کرنا آنا چاہیے کہ مسئلہ پائیداری کا ہے یا باقی راستے کا۔