Mac پر Azure VPN Client: DNS سرورز کو پروفائل میں رکھیں

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

تصدیق کریں کہ آپ کون سا کلائنٹ ترتیب دے رہے ہیں

یہ Microsoft کا Azure VPN Client ہے جو پوائنٹ سے سائٹ تک رسائی کے لیے OpenVPN استعمال کرتا ہے۔ اس کا XML macOS کا اصل IKEv2 پروفائل نہیں، اور کسی بھی تیسرے فریق کے OpenVPN کلائنٹ کی ترتیب کی فائل بھی نہیں۔

اگر Mac بلٹ اِن سسٹم ڈائیلاگ سے جڑتا ہے تو آپ غلط دستاویز میں ہیں۔

DNS پروفائل XML کے اندر رہتا ہے

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

اختیاری ترتیبات کی رہنما DNS اندراجات کو clientconfig عنصر کے اندر رکھتی ہے۔ کم سے کم ٹکڑا ایسا دکھتا ہے، اُس پتے کے ساتھ جو آپ کا ادارہ واقعی چلاتا ہے۔

<clientconfig>
    <dnsservers>
        <dnsserver>10.20.2.4</dnsserver>
    </dnsservers>
</clientconfig>

یہ پتہ مثال کے طور پر ہے، Azure کا فراہم کردہ حل کنندہ نہیں۔ اندراجات کو موجودہ ترتیب میں شامل کریں، دوسرا clientconfig عنصر چپکانے کے بجائے، کیونکہ Microsoft کہتا ہے کہ macOS پر نقل شدہ عناصر معاون نہیں۔ تیار شدہ پروفائلوں میں جہاں اصل ترتیب ہونی چاہیے وہاں nil متبادل بھی ہو سکتا ہے، اور nil عنصر کے ساتھ ترتیبات جوڑنا مرمت نہیں۔

درآمد ہی تبدیلی ہے

فائل محفوظ کرنے سے بذات خود کچھ نہیں بدلتا۔ Azure VPN Client کھولیں، Import منتخب کریں، نظر ثانی شدہ XML منتخب کریں، مطلوبہ خانے بھریں اور کنکشن محفوظ کریں۔

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

لاحقہ کی حد آپ کا پہلا امتحان طے کرتی ہے

جیسا کہ 30 اکتوبر 2026 کو دستاویزی کیا گیا، اس ترتیب میں اضافی DNS لاحقہ اقدار macOS پر درست طریقے سے نہیں رہتیں۔ Windows کی لاحقہ مثال نقل کرنا اور یکساں رویے کا وعدہ کرنا وہی طریقہ ہے جس سے کام کرنے والا حل کنندہ خراب بتایا جاتا ہے۔ لاحقے درج کریں، محفوظ کریں، دوبارہ جڑیں اور دیکھیں کہ دوبارہ جڑنے کے بعد وہ باقی رہے یا نہیں۔ اگر نہیں، تو کلائنٹ سے لڑنے کے بجائے مکمل اہل ناموں کے ساتھ منصوبہ بنائیں۔

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

حل کنندہ کو اب بھی راستہ چاہیے

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

منسلک Mac کی فعال حل کنندہ حالت دیکھیں، پھر اس کے جواب کو ایپ کے حل کنندہ انتخاب سے الگ کرنے کے لیے اس سرور سے براہ راست پوچھیں۔ براہ راست سوال ثابت کرتا ہے کہ سرور کام کرتا ہے۔ یہ ثابت نہیں کرتا کہ عام تلاشیں اسی کو منتخب کرتی ہیں۔

تین الگ نتائج حوالے کریں

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

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