מדוע WSL מאבד את שם המארח של העבודה כשהחיבור ל-VPN נוצר?
אותו שם עובד ב-Windows ונכשל בתוך WSL ברגע שהמנהרה עולה. בדקו את מצב ה-DNS של הפלטפורמה ואת העקיפות הישנות לפני שמוסיפים פותר.
Windows פותר את המארח הפנימי בלי שום תלונה, ואותו שם נכשל בתוך WSL ברגע שהמנהרה עולה. התיקון הרגיל הוא לכתוב פותר ציבורי בתוך ההפצה, מה שמשחזר גלישה רגילה והופך את שם המארח של העבודה לבלתי ניתן לפתרון. זה מחליף כשל אחד באחר ומסתיר את השכבה שבאמת נשברה. לפני שמוסיפים או מסירים שורת פותר כלשהי, בררו איזו משלוש השכבות נכשלת.
שללו קודם כשל ניתוב
שאלו את אותו שם מלא ומדויק בשני הצדדים, לא שני שמות דומים. הצלחה ב-Windows וכשל ב-WSL עבור אותה מחרוזת היא החתימה של שני מסלולי פתרון, ומעט דברים אחרים מייצרים את הדפוס הזה כל כך נקי. אם WSL גם לא מצליח להגיע לשירות בכתובתו המספרית הידועה, קיימת גם בעיית ניתוב או סינון. במקרה כזה עבודת DNS לא תחשוף אותה, והצהריים ילכו לשכבה הלא נכונה.
שלושה תסמינים מכסים את רוב המקרים האלה, וכל אחד מצביע למקום אחר. קראו את השורה המתאימה לפני שפותחים קובץ תצורה:
| Symptom inside WSL | Likely layer | Where to look |
|---|---|---|
| Private name fails while public browsing works | Resolver path | Tunneling mode and the Windows build |
| A name that worked yesterday fails today | Stale override | Generated resolver file, immutable flag, shell profile |
| The name resolves but the service does not | Routing or filtering | The resolved address and the path to it |
השורה האמצעית היא זו שאנשים קוראים לא נכון, כי השינוי ששבר אותה נעשה שבועות קודם ונראה מוצלח אז. השורה השלישית היא זו שאנשים מאבחנים לא נכון, כי שם שנפתר מרגיש כמו הוכחה שהרשת בריאה. שתי השורות שולחות אתכם לקטע אחר בהמשך.
למנהרור DNS יש רצפת גרסה
Microsoft מתעדת מצב רשת של WSL שמנהרר בקשות DNS אל הפותר של Windows דרך ערוץ וירטואליזציה. בגרסאות Windows 11 הנתמכות הוא מופעל כברירת מחדל, ולכן שתי מכונות באותה רשת ארגונית מתנהגות אחרת. המשתנה הוא מספר הגרסה, לא המדיניות הארגונית.
מדריך הרשת של WSL מתאר את המצב הזה ואת הגרסאות שתומכות בו. התכונה חשובה כי מדיניות ה-DNS הארגונית חיה בדרך כלל בפותר של Windows, והפצה שיורשת את המסלול של Windows יורשת איתה גם את המדיניות. להפצה ששואלת פותר ציבורי אין מסלול לשם פרטי, כמה שמסודרת תהיה התצורה שלה. המנגנון הזה מסביר את כל התסמין, והוא מסביר למה עקיפת הפותר הציבורי נכשלת.
קראו את מספר הגרסה לפני שמשנים משהו. הגדרה שהועתקה מהתקנה חדשה יותר אינה הוכחה שהתקנה ישנה יותר מיישמת אותה. רשמו את מספר הגרסה לצד השינוי, כי ההבדל בין שתי מכונות הוא כמעט תמיד גרסה ולא מדיניות.
עקיפות ישנות מאריכות ימים יותר מהבעיה שפתרו
מתכונים ישנים יותר השביתו קובצי פותר שנוצרים, קיבעו שרת שמות בקוד קשיח או נעלו את הקובץ בתכונת אי-שינוי. השינויים האלה נשארים במקומם הרבה אחרי שבעיית הקישוריות שגרמה להם נעלמה, ובדרך כלל הם הסיבה לכך שהגדרה חדשה יותר נראית כאילו אינה עושה דבר. הם גם שורדים התקנה מחדש של ההפצה בדמות פרופיל shell שמשכתב את הקובץ בכל התחברות. האחרון הוא הקשה ביותר למציאה, כי הוא בלתי נראה מהקובץ שכולם בודקים.
חפשו קובץ פותר שנכתב ביד, תכונת אי-שינוי עליו וסקריפט אתחול שמשכתב אותו. בדקו את דגל אי-השינוי לפני עריכה, כי כתיבה לקובץ נעול נכשלת באופן שנקרא כמו בעיית הרשאות. בדקו אחר כך את פרופיל ה-shell, כי סקריפט שם משחזר את התוכן הישן בתוך שניות מהתיקון שלכם.
להסרת עקיפה יש השלכות, לכן רשמו מה הסרתם ולמה. הפצה שבאמת זקוקה לפותר סטטי למטרה אחרת תישבר כשהקובץ הנוצר יחזור.
שני קבצים, שני תפקידים שונים
שני קובצי התצורה חיים במקומות שונים ושולטים בדברים שונים, וערבוב ביניהם יוצר עריכות שמוחלות על השכבה הלא נכונה. הקובץ בצד Windows קובע מאפיינים של המכונה הווירטואלית, ואילו הקובץ בצד ההפצה קובע איך ההפצה הזו בונה את תצורת הפותר שלה. אף אחד מהם לא עוקף את השני, ולכן שניהם חייבים להסכים.
עבור התקנה שתומכת בתכונה, הקטע בצד Windows קצר. זה כל השינוי באותו צד:
[wsl2]
dnsTunneling=trueהקטע הזה שייך לפרופיל המשתמש של Windows והוא חל על המכונה הווירטואלית ולא על הפצה אחת. המנהרור גם דורש שההפצה לא השביתה את יצירת הפותר, ולכן הקובץ בצד ההפצה חייב להשאיר את ההתנהגות הזו בשקט. שנו אחד בלי השני והמצב לא עושה דבר בשקט, וזו הדרך הנפוצה ביותר שבה התיקון הזה מדווח כשבור. בדקו את שני הקבצים באותו מושב, כי שתי עריכות שנעשו בהפרש שבועות הן שתי עריכות שאיש לא יכול לייחס.
הפעילו מחדש, ואז שאלו משני הצדדים
ההגדרות האלה נקראות כשהסביבה עולה, ולכן shell חדש בתוך הפצה פועלת לא יטען אותן מחדש. כבו את הסביבה במקום להפעיל מחדש את ה-shell, ושמרו קודם כל עבודה שרצה כי כל הפצה נעצרת איתה. ההחמצה הזו לבדה מסבירה את רוב הדיווחים על שינוי בלי השפעה.
אחר כך שאלו את אותה שאלה משני הצדדים. הפלט גם מראה לאיזה פותר ההפצה הגיעה בפועל:
wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'הפקודה הראשונה מסיימת את הסביבה, השנייה מראה באיזה פותר ההפצה משתמשת עכשיו, ושתי האחרונות מציגות את אותה שאלה לכל צד. השוו את התשובות ולא את מצב ההגדרה. שאילתה שעדיין נכשלת אחרי הפעלה מחדש נקייה כששני הקבצים נכונים מצביעה על מדיניות הפותר הארגונית, ולשיחה הזו יש בעלים אחר.