שרת DNS שגוי ב-VPN של Windows: מדד, סדר קישור או סיומת
שלושה מנגנונים של Windows בוחרים את פותר ה-DNS, והם נכשלים אחרת. החלט לפי היקף מרחב השמות, סדר גלובלי, או אם תיקון שורד חיבור מחדש.
לקוח Windows יכול להחזיק מנהרה תקינה, לשאת את הפותר הארגוני ובכל זאת לשלוח שמות פנימיים לנתב הביתי. שלושה מנגנונים שונים קובעים איזה שרת עונה, והם נכשלים בדרכים שונות. אין צורך לתקן את כל השלושה: הסימפטום אומר לך איזה מהם בפעולה. עץ ההחלטות שלמטה אורך כמה דקות ומונע את התוצאה הרגילה, שבה שינוי מדד, סידור מחדש של הרישום וכלל NRPT נוחתים יחד ואיש לא יודע מה מהם עשה משהו.
שלושה מנגנונים מחליטים, ובדרך כלל אחד מהם שגוי
מדד הממשק מסדר מתאמים עבור משפחת כתובות נתונה. סדר הקישור תחת Tcpip\Linkage הוא רשימה ברמת המכונה של מזהי ממשקים שמסלולי קוד ותיקים עדיין בודקים. טבלת מדיניות פתרון שמות (NRPT) קושרת מרחב שמות לשרתים מסוימים, ורשימת הסיומות קובעת אם שם קצר בכלל מורחב. הם בלתי תלויים, ולכן פותר נכון במתאם ה-VPN מפסיד להעדפה מיושנת במקום אחר.
| What you see | Mechanism to check | First command |
|---|---|---|
| Every name is slow, public names sometimes wrong | Global adapter order: metric, then Linkage | Get-NetIPInterface |
| Internal names resolve to a public address | The query left through the home resolver, not the tunnel | Resolve-DnsName intranet.corp.example -Type A, then the same query with -Server 10.20.0.10 |
| Only corp.example names fail, public names fine | Namespace binding: NRPT or suffix | Get-DnsClientNrptRule |
| Short name fails, fully qualified name works | Suffix list on the adapter, with the corporate suffix ahead of other entries, or pushed by the server | Get-DnsClientGlobalSetting |
| Works, then breaks after a reconnect | Runtime setting that was never persisted | Get-VpnConnection for the stored profile, then Get-NetIPInterface again after a reconnect |
אף אחד מהמנגנונים האלה אינו הצד השני של המנהרה. אם השרת שה-VPN דוחף אינו יכול לפתור את השם, כל הגדרה בצד הלקוח היא קישוט, ולכן ההחלטה הראשונה היא אם הפותר עצמו יכול לענות כששואלים אותו ישירות.
החלטה ראשונה: האם הפותר הנדחף יכול לענות בכלל?
שאל את השרת במפורש והשווה לשאילתה רגילה. הפער בין התשובות מפריד בין בעיית בחירה לבעיית נגישות, וזה הפיצול המהיר כאן:
Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type Aאם הראשונה מצליחה והשנייה נכשלת, הפותר נגיש ו-Windows בוחר רע; עבור להחלטות מרחב השמות והסדר שלמטה. אם גם הראשונה נכשלת, שום דבר בלקוח לא יעזור: בדוק ש-UDP ו-TCP 53 מגיעים לשרת דרך המנהרה, ששום חומת אש מארחת בשרת אינה מפילה את המאגר, ושהמעבירים של השרת עצמו בריאים.
עצור בפיצול הזה. החלת כלל NRPT על פותר שאינך יכול להגיע אליו מייצרת את אותה תקלה עם יותר תצורה לבטל, והיא מסתירה את התקלה האמיתית מאחורי כלל שנראה סמכותי.
החלטה שנייה: מרחב שמות אחד, או כל שאילתה?
ההיקף קובע את הכלי. כשנכשלים רק שמות ארגוניים, קשר את מרחב השמות במקום לסדר מחדש את המכונה: כלל NRPT שולח את הסיומת הזו לפותר המנהרה ומשאיר את כל השאר בשקט. כשכל חיפוש נפגע, הבעיה היא העדפת מתאמים גלובלית, והמדד הוא נקודת ההתחלה כי הוא לא משנה שום הגדרת שרת.
קבע את המדד לכל משפחת כתובות, בשני הממשקים, ואחר כך אמת את הסדר:
Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6החלף את 11 ב-ifIndex של מתאם המנהרה מהשורה שלמעלה; אם 11 הוא מתאם ה-LAN, אותה פקודה מורידה את המסלול השגוי. העלאת מתאם ה-LAN במקום מגיעה לאותו סדר מהצד השני: netsh int ip set interface interface="Ethernet" metric=15, ול-netsh int ipv6 set interface interface="Ethernet" metric=15 עבור המשפחה השנייה, כי int ip נוגע רק ב-IPv4.
סדר הקישור הוא המוצא האחרון ולא הצעד הראשון. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage מחזיק רשימת Bind של מזהי התקנים, והעברת מזהה המנהרה לחזית אכן משנה איזה מתאם נשאל ראשון, אבל זהו ערך רישום ברמת המכונה בלי היקף לפי מרחב שמות. ייצא אותו לפני העריכה ואחר כך חבר מחדש את המנהרה כדי שהסדר יחול במצב שהלקוח מצפה לו.
עבור מרחב שמות אחד, העדף את הכלי הצר יותר:
Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServersהחלטה שלישית: האם התיקון שורד חיבור מחדש?
מדד שעובד עד החיבור הבא בקו חיוג מעולם לא נשמר. L2TP/IPsec ופרופילי חיבור אחרים נוצרים מחדש כשהחיבור מתחיל, ולכן הערך השמור חי ברשומת ספר הטלפונים כ-IpInterfaceMetric, ולא רק בממשק החי. יש סביבות שכותבות את השדה הזה בסקריפט בדיוק מהסיבה הזו; אחרות דוחפות את ההעדפה ממדיניות ניהול ומשאירות את הקצה בשקט.
מטמון ורישום הם שכבה נפרדת. הרצת אלה לאחר שהמנהרה עולה מתקנת רשומות מיושנות ורושמת את הלקוח מחדש, אבל אף אחת מהן לא מסדרת מתאם מחדש:
ipconfig /registerdns
ipconfig /flushdnsיש מתג כיבוי באותה שכבה. השבתת רישום דינמי במתאם הפיזי מונעת מהלקוח לפרסם את כתובתו מצד ה-VPN תחת השם השגוי, וזה תיקון שונה מהרענון שלמעלה.
IPv6 ראוי לשורה משלו בהחלטה. אם למתאם הפיזי יש כתובת IPv6 גלובלית בעוד המנהרה נושאת IPv4 בלבד, Windows עשוי להעדיף את המסלול ללא מנהרה לפתרון שמות. בדוק את המשפחה הזו בנפרד, כי מדד שנקבע ל-IPv4 לא אומר עליה דבר:
Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetricהשבתת IPv6 במתאם ה-LAN מסירה את המסלול הזה ואת הפרוטוקול איתו; שינוי מדד בממשק IPv6, או כלל NRPT למרחב השמות הארגוני, שומר על המשפחה ומתקן את ההעדפה. בחר בצר יותר אלא אם החלטת שהקישור הזה לא אמור להחזיק IPv6.
אמת עם המקור הנקוב, ושמור על בעלים אחד
אמת בכלים שמדווחים איזה מקור בתוקף, ולא רק אם דף נטען:
ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type Aאחר כך הפרד סינון מבחירה, כי מבפנים ליישום הם נראים זהים. block-outside-dns של OpenVPN חוסם פורט 53 במתאמים האחרים; הוא לא בוחר פותר. אם עכשיו כל שאילתה נכשלת, ייתכן שמסנן חוסם את השרת היחיד שאפשר להגיע אליו; אם הפותר המוגדר מותעלם, הסדר או כלל מרחב השמות שגוי. שינוי שניהם יחד הופך שאילתה חסומה ושאילתה מותעלמת לבלתי ניתנות להבחנה.
שמור בעלים אחד למדיניות ה-DNS: פרופיל ה-VPN, מדיניות ניהול או כלל NRPT, ולא שניים מהם. לפני שתסיים:
- הפותר הנדחף עונה כשהוא נקרא בשמו במפורש, וחיפוש רגיל משתמש בו.
- הכלל או המדד ששינית מכסים את משפחת הכתובות שנושאת בפועל את השאילתות.
- ההגדרה שורדת ניתוק וחיבור מחדש, או שהעברת אותה לפרופיל השמור.
- מנגנון אחד בדיוק הוא הסמכותי, והאחרים הושארו כפי שהיו.
התייחס לסדר כמצב סביבתי ולא כדבר שמסיימים. בדוק אותו שוב לאחר חיבור מחדש ולאחר עדכון Windows שנוגע במחסנית הרשת, כי כל אחד מהשניים יכול להחזיר את המתאם הפיזי לחזית.