הגדרת DNS במתאם VPN של Windows עם PowerShell, ואז אימות

Windows מצמיד את ה-DNS של המנהרה למתאם, לא לפרופיל ה-VPN. הגדירו אותו לאחר ההתחברות ב-PowerShell, ואז בדקו אם התחברות מחדש שומרת עליו.

חיבור VPN של Windows אינו שומר שרתי DNS בפרופיל שאתם עורכים בהגדרות. כשהמנהרה עולה, הלקוח מנהל משא ומתן על תצורת ה-IP עם השער, השער שולח רשימת פותרים, ו-Windows מחיל אותה על מתאם המנהרה. המתאם הזה הוא ממשק נפרד מה-Wi-Fi או מה-Ethernet שלכם, והרשימה שייכת לממשק, לא לפרופיל. ברגע שאתם יודעים איזה אובייקט מחזיק בערך, עקיפתו ב-PowerShell היא פקודה אחת; לגרום לעקיפה לשרוד התחברות מחדש הוא החלק שדורש החלטה.

איזה אובייקט מחזיק בכתובת

RAS יוצר את מתאם המנהרה כשהחיבור מצליח ומסיר אותו כשהחיבור נופל. שרתי ה-DNS שאתם רואים ב-ipconfig /all מגיעים במהלך חילוף התצורה הזה, לצד כתובות IPv4 ו-IPv6 והמסלולים. מכיוון שהערך מוצמד לממשק, Set-DnsClientServerAddress כותב למשהו שקיים רק כל עוד החיבור קיים.

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

מצאו את הכינוי לפני שנוגעים ב-DNS

שם הפרופיל וכינוי הממשק הם בדרך כלל אותו מחרוזת, אבל הם לא אותו אובייקט. Get-VpnConnection מפרט פרופילים; Get-NetAdapter מפרט את הממשקים שבאמת יש ל-Windows. פקודות ה-cmdlet של DNS רוצות את השני, והשניים מתפצלים לעתים קרובות יותר ממה שאנשים מצפים, במיוחד כשהלקוח מוסיף תיאור כמו "(RAS)" לשם המתאם.

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

Add-VpnConnection -Name "Corporate" -ServerAddress vpn.example.net `
  -TunnelType Ikev2 -EncryptionLevel Required `
  -AuthenticationMethod Eap -AllUserConnection

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

rasdial.exe "Corporate"
Get-NetAdapter | Where-Object InterfaceDescription -like "*VPN*"
Get-DnsClientServerAddress -InterfaceAlias "Corporate"

החילו את העקיפה בסדר הנכון

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

ה-cmdlet עצמו הוא שורה אחת, מתועד ב תיעוד ההפניה של Set-DnsClientServerAddress של מיקרוסופט:

Set-DnsClientServerAddress -InterfaceAlias "Corporate" -ServerAddresses 10.20.0.53,10.20.0.54
Get-DnsClientServerAddress -InterfaceAlias "Corporate" -AddressFamily IPv4

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

מדוע התחברות מחדש עלולה לבטל את השינוי

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

קיימות שלוש תשובות עמידות, וערימתן יוצרת תקלות משלהן. סיומת DNS ספציפית לחיבור יחד עם כלל NRPT שולחת רק את מרחב השמות הפנימי לפותרת הפנימית ומשאירה שמות ציבוריים בשקט. הגדרת Group Policy או MDM שמוחלת על חיבור ה-VPN קובעת DNS בזמן ההתחברות בלי שום סקריפט. משימה מתוזמנת שמגיבה לאירוע החיבור ומריצה שוב את ה-cmdlet היא האפשרות הגסה, אבל היא עובדת ומשאירה יומן. בחרו בעלים אחד ל-DNS ורשמו מי הוא.

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

אמתו את הפתרון, לא רק את ההגדרה

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

Resolve-DnsName server01.corp.example -Server 10.20.0.53
Resolve-DnsName server01.corp.example

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

הריצו את הבדיקה פעמיים, פעם אחת מיד אחרי ההתחברות ופעם אחת אחרי התנתקות והתחברות מחדש, והשוו את הפלט של Get-DnsClientServerAddress משתי ההרצות. אם הערך שנדחף חזר בחיבור השני, העקיפה חיה ומתה עם המתאם, ורק כלל ה-NRPT או נתיב המדיניות מהסעיף הקודם יחזיק מעמד. שמרו את שתי התמלילים ואת חותמות הזמן של ההתחברות; הן מכריעות את שאלת ההישארות מהר יותר מסבב עריכות נוסף.

מאמרים קשורים