Windows پر OpenConnect کی DNS ترتیبات درحقیقت کون لاگو کرتا ہے؟
Windows ریزالور کی حالت تین جگہوں پر رکھتا ہے۔ ایڈاپٹر DNS کو ہاتھ سے تبدیل کرنے یا نام کی جگہ کا قاعدہ شامل کرنے سے پہلے وہ معاون تلاش کریں جس کے پاس کنکشن ہے۔
ٹنل کھڑا کرنا اس کی DNS اقدار نصب کرنے کے مترادف نہیں۔ OpenConnect بات چیت کرتا ہے، اور Windows کی طرف کا ایک معاون لاگو کرتا ہے۔ ان دو مراحل کے درمیان خلا اسی کلائنٹ پر زیادہ تر نجی ناموں کی ناکامیوں کی وضاحت کرتا ہے، اور معاون تقریباً کبھی Windows VPN ترتیبات کا صفحہ نہیں ہوتا۔
گیٹ وے نے جو پیش کیا اور Windows نے جو نصب کیا انہیں الگ کریں
کلائنٹ کنکشن ڈیٹا ایک اسکرپٹ انٹرفیس کو دیتا ہے، اور Unix اور Windows کے ورژن الگ پروگرام ہیں۔ Windows پر عمل درآمد عام طور پر ایک JavaScript معاون ہوتا ہے جو کسی بھی ایڈاپٹر کو چھونے سے پہلے اندرونی DNS سرور اور اندرونی ڈومین جیسے متغیرات پڑھتا ہے۔ ٹنل میں بذات خود کچھ بھی ریزالور کی حالت نہیں لکھتا۔
یہ تقسیم اہم ہے کیونکہ کوئی قدر بات چیت میں موجود ہو سکتی ہے اور کبھی ایڈاپٹر تک نہ پہنچے۔ غائب، آدھے راستے میں ناکام ہونے والا، یا GUI غلاف میں بند پرانی نقل والا معاون Windows کو بالکل ویسا ہی چھوڑ دیتا ہے جیسا وہ تھا۔ سیشن جڑا ہوا دکھائی دیتا ہے، نجی نام اب بھی مقامی فراہم کنندہ کے ذریعے حل ہوتا ہے، اور کلائنٹ کی ونڈو میں کوئی چیز فرق کی طرف اشارہ نہیں کرتی۔ معاون کا اپنا آؤٹ پٹ پڑھنا ہی یہ جاننے کا واحد قابلِ اعتماد طریقہ ہے کہ کون سا مرحلہ ٹوٹا۔
| Stage | What exists there | Where you see it |
|---|---|---|
| Negotiated | Internal DNS address and domain pushed by the gateway | Client log or helper input |
| Installed | Adapter DNS entry, connection suffix, or namespace rule | Adapter and policy queries |
| Selected | Resolver Windows uses for one specific query | The failing application |
GUI غلاف اپنی کلائنٹ اور معاون کی نقل لا سکتا ہے، اس لیے ڈسک پر کہیں اور دوسرا openconnect.exe کچھ ثابت نہیں کرتا۔ اس کی تشکیل کا فیصلہ کرنے سے پہلے وہ ایگزیکیوٹیبل تلاش کریں جس نے سیشن شروع کیا۔
ریزالور کی حالت کو بدلے بغیر پڑھیں
تین صرف پڑھنے والی استفساریں عام الجھن کا احاطہ کرتی ہیں، اور ہر ایک مختلف سوال کا جواب دیتی ہے:
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -Effectiveایڈاپٹر سطح کا سرور وہی ہے جسے زیادہ تر لوگ VPN DNS کہتے ہیں۔ کنکشن کے لیے مخصوص لاحقہ طے کرتا ہے کہ مختصر نام بالکل پھیلے گا یا نہیں۔ نام کی جگہ کی پالیسی فہرست ایڈاپٹر ترتیب سے قطع نظر ملتے ناموں پر لاگو ہوتی ہے، اور وہاں خالی نتیجہ عیب نہیں جب معاون نے کبھی ایک بنانے کا ارادہ نہ کیا ہو۔ ترمیم سے پہلے تینوں پڑھنا ہی ایسی درستی کو روکتا ہے جو صرف علامت کو کہیں اور منتقل کرتی ہے۔
مکمل اہل نام سے شروع کریں۔ اگر FQDN حل ہوتا ہے اور مختصر نام نہیں، تو خلا لاحقہ یا تلاش کی فہرست ہے، سرور کا پتہ نہیں۔
دوسرے مرحلے کے طور پر مطلوبہ سرور سے براہ راست پوچھیں، کسی بھی پہلے سے نصب ریزالور ٹول کے ساتھ۔ براہ راست جواب ثابت کرتا ہے کہ سرور قابل رسائی اور زون کے لیے مستند ہے۔ یہ اس بارے میں کچھ ثابت نہیں کرتا کہ کوئی ایپلیکیشن بطور طے شدہ کس سرور سے پوچھتی ہے۔
کنکشن رکھنے والے جزو کا نام لیں
دو ترتیبیں عام ہیں۔ ٹرمینل سے شروع کیا گیا کلائنٹ اپنا اسکرپٹ راستہ واضح طور پر دیتا ہے، اس لیے مالک چلائی گئی کمانڈ میں نظر آتا ہے۔ پیک شدہ ایپلیکیشن آپ کے لیے کلائنٹ شروع کرتی ہے اور معاون کو اپنی ڈائریکٹری میں رکھتی ہے، یعنی یہ کب بدلے گا یہ وینڈر طے کرتا ہے۔
کچھ بھی بدلنے سے پہلے انسٹالیشنوں کے درمیان معاون کے ورژن کا موازنہ کریں۔ فائل کا نام جانی پہچانی لگنے کی وجہ سے آئینے سے لیایا گیا معاون بلند حقوق کے ساتھ چلانا DNS کے خلا کو سیکیورٹی واقعہ بنا دیتا ہے۔
مالک معلوم ہونے کے بعد مرمت کا ہدف واضح ہو جاتا ہے: لانچر میں معاون اسکرپٹ راستہ، پیکیج اپ ڈیٹ، یا گیٹ وے پر درست شدہ پروفائل۔ ان میں سے کسی کو بھی ایڈاپٹر کی خصوصیات ہاتھ سے تبدیل کرنے کی ضرورت نہیں۔
مالک درست کریں، ایڈاپٹر نہیں
ایڈاپٹر پر ہاتھ سے مقرر کردہ DNS اکثر منقطع ہونے کے بعد بھی رہتا ہے، اسی لیے یہ کام کرتا دکھائی دیتا ہے اور پھر اگلے نیٹ ورک پر پریشانی پیدا کرتا ہے۔ ہر انٹرفیس پر پیچ کیا گیا عوامی ریزالور نجی نام کی جگہ کے مسئلے کو حل کرنے کے بجائے چھپاتا ہے۔ جب معاون کو کبھی DNS قدر نہ ملی ہو، تو گیٹ وے پروفائل دیکھنے کی جگہ ہے۔ جب اسے مل گئی اور ایڈاپٹر اب بھی پرانا سرور دکھاتا ہے، تو معاون کنیکٹ کے دوران ناکام ہوا اور کلائنٹ لاگ عام طور پر اسے ٹنل سیٹ اپ لائنوں کے قریب درج کرتا ہے۔
معاون راستے سے حالت دوبارہ بنائیں، پھر پورا چکر جانچیں: جڑیں، نجی FQDN حل کریں، سروس کھولیں، منقطع کریں، اور تصدیق کریں کہ ایڈاپٹر اپنے سابقہ سروروں کے ساتھ واپس آیا۔
اصل میں ناکام ہونے والی ایپلیکیشن کی جانچ کریں
اپنی انکرپٹڈ-DNS ترتیب والا براؤزر اوپر کی ہر بات نظر انداز کرتا ہے اور عوامی ریزالور سے جواب دیتا رہتا ہے۔ ٹنل اٹھنے سے پہلے کا محفوظ منفی جواب رکھنے والی ایپلیکیشن بھی ویسا ہی برتاؤ کرتی ہے۔ ریزالور کے پتے دوبارہ بدلنے سے پہلے اسے اسی مشین پر سادہ سسٹم استفسار سے موازنہ کریں۔
اگر سسٹم استفسار درست ہے اور ایپلیکیشن غلط، تو باقی خرابی اسی ایپلیکیشن کی DNS تشکیل میں ہے، VPN راستے میں نہیں۔