WSL2 איבד את ה-DNS לאחר התחברות ה-VPN? שתי סיבות

קובץ resolver מיושן ומטריקת ניתוב מתחרה יוצרים את אותו תסמין בתוך WSL2. תעדו את שני הצדדים ואז תקנו את זה שבאמת שבור.

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

למה ההפצה שומרת resolver משלה

לקוח ה-DNS של Windows אינו משמש בתוך ההפצה. WSL2 בונה קובץ resolver משלו בעת האתחול, שמצביע לכתובת stub ש-Windows מפרסם במתג הווירטואלי עבור המכונה הווירטואלית המשנית.

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

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

אספו קודם ראיות בשני הצדדים

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

בתוך ההפצה, הדפיסו את קובץ ה-resolver, את טבלת הניתוב וחיפוש פנימי אחד וחיפוש ציבורי אחד:

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

ב-Windows, פרטו את שרתי ה-DNS לפי מתאם ואת טבלת IPv4 עם מטריקות. לקוח VPN מתקין בדרך כלל נתיב לרשת המשנה של WSL2, והמטריקה שלו קובעת אם התעבורה הזאת יוצאת דרך המנהרה או נשארת מקומית.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

מטריקת נתיב או קובץ מיושן

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

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

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

במקרה של ניתוב, הסירו את המטריקה האוטומטית ממתאם המנהרה ותנו לו מספר מעל נתיב הקישור של WSL2:

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

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

קחו את הקובץ, בכוונה

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

צרו /etc/wsl.conf בתוך ההפצה עם קטע הרשת שמשבית את היצירה, ואז כתבו את קובץ ה-resolver בעצמכם, קודם שרת ארגוני ואחר כך שרת ציבורי כגיבוי:

[network]
generateResolvConf = false
search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

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

בדקו שמות, ואז חבילות

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

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

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

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

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