Linux VPN پر پتہ، راستہ، DNS اور فائرفال کا مالک کون ہے؟

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

یہ نقشہ ایک بار لکھیں، اور زیادہ تر دوبارہ رابطے کی ناکامیاں پراسرار ہونا چھوڑ دیں گی۔ چار چیزیں اہم ہیں: آلہ اور اس کے پتے، راستے اور پالیسی قواعد، DNS کنفیگریشن اور فائرفال۔

آلہ اور اس کے پتے

ٹنل آلہ یا تو پروفائل جاننے والا مینیجر بناتا ہے، یا کوئی ڈیمون جسے کسی نے ہاتھ سے شروع کیا ہو۔ دونوں ترتیبیں اپنے طور پر کام کرتی ہیں؛ انہیں ملانا نہیں۔ اگر NetworkManager پروفائل کا مالک ہے تو آلہ کا بھی مالک رہنے دیں، اور اسی ٹنل نام کے خلاف غیر منظم OpenVPN عمل شروع نہ کریں۔

لکھیں کہ سیشن ختم ہونے پر آلہ کون ہٹاتا ہے۔ جو آلہ اپنے سیشن سے زیادہ جیتا رہے وہی پرانے پتوں اور ان کے بعد کی الجھن کا سب سے عام ذریعہ ہے۔

راستے اور پالیسی قواعد

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

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

DNS ہمیشہ الگ مالک ہے

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

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

فائرفال کی حالت، اور اسے کون بحال کرتا ہے

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

اگر قواعد کو دوبارہ رابطہ برداشت کرنا ہے تو یہ صاف کہیں۔ اگر نہیں کرنا تو یہ بھی کہیں، کیونکہ اگلا انجینئر زیادہ آسان جواب فرض کرے گا۔

زندگی کا چکر: بوٹ، دوبارہ رابطہ، انہدام

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

مشاہدے کے لیے ip monitor link address route کرنل کی تبدیلیاں ہوتے ہی دکھاتا ہے، مگر یہ ارادہ نہیں، واقعات کی اطلاع دیتا ہے: حذف شدہ راستہ یہ نہیں بتاتا کہ کس عمل نے اسے حذف کیا۔ اسے ملکیت کے نقشے سے جوڑیں، اور الجھا دینے والا بند ہونا امیدواروں کی مختصر فہرست بن جائے گا۔

استثناؤں کی بھی قیمت ہوتی ہے۔ تنازع سے بچنے کے لیے پوری آلہ کلاس کو غیر منظم نشان زد کرنا وہ حالت کسی کو نہیں دیتا، جو اصلاح نہیں، فیصلہ ہے۔