OpenVPN DNS بھیجتا ہے، مگر آپ کا حل کنندہ اسے کبھی نہ دیکھ سکے

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

علامت: لاگ DNS دکھاتا ہے اور نام اب بھی ناکام ہوتے ہیں

OpenVPN dhcp-option DNS اور ڈومین معلومات لے کر چلتا ہے، اور کلائنٹ وہ درج کرتا ہے جو اسے ملا۔ کچھ عمل درآمدات میں کلائنٹ وہ ترتیبات اندر ہی لاگو کرتا ہے؛ دیگر میں انہیں کسی انٹیگریشن اسکرپٹ یا نیٹ ورک سروس کے لیے برآمد کرتا ہے۔ لاگ لائن کہانی کا صرف پہلا نصف بیان کرتی ہے۔ دوسرا نصف کہیں ایسی جگہ ہوتا ہے جس پر کلائنٹ کا کنٹرول نہیں۔ ناکامی عموماً وہیں رہتی ہے۔

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

موصول ہونا لاگو ہونا نہیں

کلائنٹ بھیجی گئی DNS قدر درج کر سکتا ہے جبکہ سسٹم حل کنندہ اب بھی کسی دوسری سروس کی ملکیت میں ہو۔ براؤزر کی اپنی انکرپٹڈ-DNS پالیسی بھی ہو سکتی ہے جو سسٹم حل کنندہ کو مکمل طور پر نظرانداز کرتی ہے، جس سے وہ یادگار صورتحال بنتی ہے جہاں ایک ایپلیکیشن اندرونی نام حل کرتی ہے اور دوسری نہیں۔

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

ہر پلیٹ فارم پر حل کنندہ کا مالک تلاش کریں

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

اصل حالت اس آلے سے پڑھیں جو واقعی سوالات کا جواب دیتا ہے: systemd-resolved ہوسٹ پر resolvectl query internal.example.net، یا پلیٹ فارم کا متبادل۔ پھر اس جواب کا موازنہ اس DNS سرور سے کریں جسے کلائنٹ لاگ بھیجنے کا دعویٰ کرتا ہے۔

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

اسکرپٹس اور foreign_option

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

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

لاگ نہیں، نام آزمائیں

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

اگر نام حل ہو جائے مگر سروس ناکام ہو، تو DNS دوبارہ بدلنے کی بجائے روٹنگ اور ایپلیکیشن رسائی کی طرف بڑھیں۔ OpenVPN دستی dhcp-option اور اسکرپٹ ماحول کی دستاویز کرتا ہے؛ دوسری حل کنندہ فائل میں ترمیم سے پہلے یہ تصدیق کرنے کے لیے استعمال کریں کہ آپ کے کلائنٹ کو کیا لاگو کرنا چاہیے۔