resolv.conf ב-WSL 2: ה-DNS מפסיק לעבוד כשהחיבור ל-VPN עולה

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

הקובץ נוצר, לא מוגדר

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

מצב כשל שני שקט יותר: WSL עשוי להעתיק שרתים רק מחלק מהמתאמים. אם למתאם הפיזי כבר יש resolver IPv6, שרתי ה-IPv4 שמספק מתאם ה-VPN עלולים להיזרק במקום להיתוסף, והקובץ נראה שלם בעודו משמיט בדיוק את זה שעונה על שמות פנימיים.

השוו את התצוגה של Windows לתצוגה של Linux

קראו את שני הצדדים לפני עריכה. בתוך ההפצה, ראו מה הקובץ מכיל והאם הוא קובץ רגיל או קישור. ב-Windows, פרטו את ה-resolver לכל מתאם, כולל זה שה-VPN יצר:

ls -l /etc/resolv.conf
cat /etc/resolv.conf

Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetAdapter | Where-Object Status -eq 'Up'

כשמתאם ה-VPN מציג את שרתי הארגון ו-Linux מציג משהו אחר, אי-ההתאמה היא ביצירה ולא בנגישות. השוו את רשימת המתאמים וגם את הכתובות, כי מתאם חסר מסביר שרת חסר. ההבחנה הזו מכריעה אם אתם מתקנים את WSL או חומת אש, ולשניים אין דבר במשותף.

הפסיקו את היצירה וכתבו קובץ משלכם

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

[network]
generateResolvConf = false

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

nameserver 172.28.4.10
nameserver 172.28.4.11
search site.corp.example
options timeout:1 attempts:2 rotate

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

טפלו ב-resolver שזז ואז אמתו

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

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

בדקו בשם ולא במנות: getent hosts sensor-access0.corp.example עובר דרך מחסנית ה-resolver, בעוד ping עשוי להצליח מול כתובת שמורה או מילולית. לאחר מכן חזרו על כך אחרי ניתוק והתחברות מחדש, כי הגדרה שעובדת פעם אחת ונוצרת מחדש בהמשך לא תוקנה מעולם. שמרו את התוכן הקודם ורשמו איזה רכיב מחזיק בנתיב במכונה הזו, כדי שהשינוי הבא יתחיל בראיות.