OpenVPN نے DNS سرور بھیجا، لیکن Linux اسے نظر انداز کرتا ہے

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

پہلی جانچ: کنکشن کیسے شروع ہوتا ہے

کنکشن کا مالک طے کرتا ہے کہ کون ریزالور کی سیٹنگز لاگو کر سکتا ہے۔ شیل سے دیا گیا براہ راست openvpn کمانڈ اپنی پروسیس کے سوا کچھ نہیں رکھتا، جبکہ systemd یونٹ، NetworkManager یا وینڈر کا کلائنٹ ہر ایک کے پاس DNS شائع کرنے کا اپنا طریقہ ہے۔ ان میں سے کسی کو ماننے سے پہلے پروسیس کی فہرست اور یونٹ کا نام پڑھیں۔

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

آگے بڑھنے سے پہلے مالک لکھ لیں۔ ہر اگلی جانچ اسی پر منحصر ہے۔

دوسری جانچ: ریزالور کا لنک واقعی کیا رکھتا ہے

systemd-resolved ہوسٹ پر، resolvectl status ہر لنک کو اس کے DNS سرورز اور ڈومینز کے ساتھ فہرست کرتا ہے۔ ٹنل کا لنک تلاش کریں اور اس کے اندراجات پڑھیں، اور یہ نہ مانیں کہ انٹرفیس کا نام tun0 ہے، کیونکہ نمبر کاری ترتیبِ تخلیق کی پیروی کرتی ہے۔ اگر بھیجا گیا پتہ لنک پر نہ ہو تو حوالگی ناکام ہوئی ہے، استفسار نہیں۔

اگر پتہ موجود ہے تو اگلا سوال یہ ہے کہ وہ لنک کن ڈومینز کا دعویٰ کرتا ہے۔ ڈومین فہرست کے بغیر لنک صرف ان ناموں کا جواب دیتا ہے جن کے بارے میں براہ راست پوچھا جائے، اور split-DNS تعیناتی شاذ و نادر ہی یہ چاہتی ہے۔ صرف پتہ ضروری ہے، کافی نہیں۔

کوئی نتیجہ اخذ کرنے سے پہلے ریزالور کی آؤٹ پٹ میں لنک کا نام VPN لاگ میں انٹرفیس کے نام سے موازنہ کریں۔ وہاں عدم مطابقت عام طور پر بتاتی ہے کہ لاگ کی سطر کسی دوسری پروسیس سے آئی ہے۔

تیسری جانچ: کیا نام کی جگہ وہ لنک منتخب کرتی ہے

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

ڈومین کی تفویض چیک کریں، صرف سرور کا پتہ نہیں۔ ~corp.example کے طور پر لکھا گیا ڈومین روٹنگ ڈومین ہے، اور ٹلڈا نشان تبدیل کرتا ہے کہ نام کیسے ملایا جاتا ہے۔

اگر ایپلیکیشن کا اپنا ریزالور ہے تو سسٹم ٹول کے بجائے اسی طریقہ کار سے جانچیں جو وہ استعمال کرتی ہے۔ سسٹم ریزالور سے بچنے والا استفسار ٹول لنک کی حالت سے قطع نظر کامیاب ہوگا۔

چوتھی جانچ: ایک مالک، دو نہیں

اگر NetworkManager پہلے ہی VPN اور ریزالور کی حالت سنبھالتا ہے تو غیر متعلقہ ہک اسکرپٹ شامل کرنا متنازع لکھنے والے پیدا کرتا ہے۔ پیکیج جو ہک systemd-resolved کے لیے فراہم کرتا ہے وہ معاون انضمام ہے، اور یہ ایک مخصوص زندگی کے چکر کی توقع رکھتا ہے: script-security 2، ایک up راستہ، up-restart، ایک down راستہ اور down-pre۔ وہ اختیارات رجسٹریشن اور ہٹانے کو صرف پہلے کنکشن پر نہیں بلکہ درست لمحات میں واقع ہونے دیتے ہیں۔

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

اپنے آؤٹ پٹ ہدف کو بدلنے کے لیے کسی ڈسٹری بیوشن کی ریزالور اسکرپٹ میں ترمیم کرنا ایک ہی ہوسٹ کا حل درج کرتی ہے۔ یہ عام مرمت نہیں ہے۔

پانچویں جانچ: دوبارہ جڑنے کے بعد وہی نتیجہ

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

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