לקוח Azure VPN ב-Mac: לשים את שרתי ה-DNS בתוך הפרופיל

ב-macOS שלוש שאלות שונות נענות באותה משיכת כתפיים. איזה לקוח זה? מאיפה מגיעים שרתי ה-DNS שלו? ואחרי שההגדרה כבר במקום, למה שם קצר עדיין נכשל? יש להן תשובות נפרדות, ורק הראשונה עוסקת בקובץ הפרופיל. הסדר הנכון הופך בעיית DNS מעורפלת לצעד אחד שאפשר לאמת בכל פעם.

לאשר איזה לקוח אתם מגדירים

זהו לקוח Azure VPN של Microsoft שמשתמש בOpenVPN לגישה מנקודה לאתר. ה-XML שלו אינו פרופיל IKEv2 מקורי של macOS, והוא גם לא קובץ תצורה לכל לקוח OpenVPN של צד שלישי.

אם ה-Mac מתחבר דרך תיבת הדו-שיח המובנית של המערכת, אתם במסמך הלא נכון.

ה-DNS נמצא בתוך XML הפרופיל

הורידו את הפרופיל הנוכחי עבור השער ושיטת האימות הרצויים, ואז שמרו עותק שלא שונה לפני שאתם נוגעים במשהו. ערכו רק את עותק העבודה, ואל תדביקו את חומר האימות שלו בכרטיס תמיכה.

מדריך ההגדרות האופציונליות מציב את רשומות ה-DNS בתוך רכיב clientconfig. קטע מינימלי נראה כך, עם כתובת שהארגון שלכם באמת מפעיל.

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

הכתובת הזו להמחשה בלבד, ולא פותר שמספק Azure. שלבו את הרשומות בתצורה הקיימת במקום להדביק רכיב clientconfig נוסף, משום ש-Microsoft מציינת שרכיבים כפולים אינם נתמכים ב-macOS. פרופילים שנוצרו עשויים גם לשאת מציין מקום nil במקום שבו אמורה להיות התצורה האמיתית, והוספת הגדרות לצד רכיב nil אינה תיקון.

הייבוא הוא השינוי

שמירת הקובץ לבדה לא משנה דבר. פתחו את לקוח Azure VPN, בחרו Import, בחרו את ה-XML המתוקן, מלאו את השדות הנדרשים ושמרו את החיבור.

לאחר מכן התחברו מחדש דרך החיבור המיובא הזה. פרופיל שנשאר על הדיסק בזמן שחיבור ישן יותר נשאר פעיל הוא הסיבה הנפוצה ביותר לכך שעריכה נכונה נראית כאילו אינה עושה דבר.

מגבלת הסיומת קובעת את הבדיקה הראשונה

כמפורט ב-30 באוקטובר 2026, ערכי סיומת DNS נוספים בתצורה הזו אינם נשמרים כראוי ב-macOS. העתקת דוגמת סיומת מ-Windows והבטחת התנהגות זהה היא הדרך שבה פותר עובד מדווח כשבור. הזינו את הסיומות, שמרו, התחברו מחדש ובדקו אם הן שרדו את ההתחברות מחדש. אם לא, תכננו סביב שמות מלאים במקום להיאבק בלקוח.

בדקו תחילה עם שם מארח פרטי מלא. אם ה-FQDN נפתר והשם הקצר לא, למדתם משהו ספציפי: הפותר נגיש והרחבת שם קצר חסרה. זהו פגם שונה משרת DNS שאינו נגיש, והוא דורש אחראי אחר.

הפותר עדיין צריך מסלול

רישום כתובת ב-XML אינו יוצר שירות DNS. הכתובת חייבת להפעיל פותר מורשה שיכול לענות או להעביר את מרחב השמות הפרטי, וה-Mac חייב להיות רשאי להגיע אליו דרך המנהרה. אם הפותר הזה נמצא מאחורי כלל חומת אש שאינו מכיר את טווח המנהרה, השאילתות פגות בלי שגיאה שימושית. אז הפסק הזמן נראה בדיוק כמו כתובת שגויה, ואנשים עורכים את ה-XML מחדש במשך שעה.

בדקו את מצב הפותר הפעיל של ה-Mac המחובר, ואז שאלו את השרת הזה ישירות כדי לבודד את תשובתו מבחירת הפותר של היישום. שאילתה ישירה מוכיחה שהשרת עובד. היא אינה מוכיחה שחיפושים רגילים בוחרים בו.

למסור שלוש תוצאות נפרדות

הפרידו ביניהן במסירה: הפרופיל המתוקן יובא, הפותר המיועד ענה לשם המבוקש, והיישום הגיע לכתובת שהוחזרה. לכל אחד אחראי אחר ותיקון אחר.

שורה אחת לכל תוצאה מספיקה, והיא מונעת מהאדם הבא לערוך שוב פרופיל שכבר היה נכון.