דליפת DNS ב-VPN של Windows: למה המדד מנצח את המסלול

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

שני הסברים לדליפה אחת

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

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

השוו מדדים ו-resolvers יחד

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

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

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

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

דרגו את המנהרה ובדקו שוב

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

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

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

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

גרמו לזה לשרוד התחברות מחדש

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

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