په 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 غوره کړئ، اړین ځایونه ډک کړئ او اړیکه وساتئ.

بیا د هغه وارد شوي اړیکې له لارې بیا وصل شئ. پروفایل چې په ډیسک کې پاتې وي او زاړه اړیکه فعاله پاتې شي، دا هغه تر ټولو عام دلیل دی چې سم تعدیل د هېڅ نه کولو په څیر ښکاري.

د ضمیمې محدودیت ستاسو لومړی ازموینه ټاکي

لکه څنګه چې د 2026 کال د اکتوبر په 30 مستند شوي، په دې ترتیب کې اضافي DNS ضمیمې ارزښتونه په macOS کې سم نه پاتې کیږي. د Windows د ضمیمې بېلګه کاپي کول او د همدې چلند ژمنه کول هغه لاره ده چې فعال حل کوونکی مات شوی راپور کیږي. ضمیمې دننه کړئ، وساتئ، بیا وصل شئ او وګورئ چې ایا د بیا وصلیدو وروسته پاتې شوې که نه. که نه، د کلاینټ سره د جګړې پرځای د بشپړ وړ نومونو سره پلان جوړ کړئ.

لومړی د بشپړ وړ شخصي هوسټ نوم سره وازموئ. که FQDN حل شي او لنډ نوم نه شي، تاسو یو ځانګړی شی زده کړ: حل کوونکی د لاسرسي وړ دی او د لنډ نوم پراخول نشته. دا د نه لاسرسي وړ DNS سرور څخه بېل نقص دی، او بل مسؤل شخص ته اړتیا لري.

حل کوونکی لا هم لارې ته اړتیا لري

په XML کې د یوې پتې لیست کول DNS خدمت نه جوړوي. په پته کې باید یو مجاز حل کوونکی چلیږي چې کولای شي شخصي نوم تشه ته ځواب ووایي یا یې ولیږي، او Mac باید اجازه ولري چې د تونل له لارې ورته ورسیږي. که هغه حل کوونکی د اور وژنې د یوې قاعدې شاته وي چې د تونل ساحه نه پېژني، پوښتنې پرته له ګټورې تېروتنې وخت تیروي. بیا وخت تېریدل په بشپړ ډول د غلطې پتې په څیر ښکاري، او خلک یو ساعت XML بیا سمول کیږي.

د وصل شوي Mac د فعال حل کوونکي حالت وګورئ، بیا له هغه سرور څخه مستقیم وپوښتئ ترڅو د هغې ځواب د اپلیکیشن د حل کوونکي له انتخاب څخه جلا کړئ. مستقیمه پوښتنه ثابتوي چې سرور کار کوي. دا ثابتوي نه چې عادي لټونونه هغه غوره کوي.

درې جلا پایلې وسپارئ

د سپارلو په وخت کې دا جلا وساتئ: تعدیل شوی پروفایل وارد شو، غوښتل شوی حل کوونکی د غوښتل شوي نوم ځواب ورکړ، او اپلیکیشن د بیرته راستنیدلې پتې ته ورسید. هر یو بل مسؤل او بله حل لري.

د هرې پایلې لپاره یوه کرښه بس ده، او دا بل کس د هغه پروفایل د بیا سمولو څخه منع کوي چې لا دمخه سم و.