WSL2 לא יורש את ה-VPN הארגוני, וזה בדיוק הבאג
WSL2 פועל ברשת וירטואלית משלו ולעולם אינו יורש את מחסנית ה-VPN של המארח. הפרידו בין כשלי שמות לכשלי נתיב לפני שאתם עורכים את resolv.conf בכלל.
הוויקי הפנימי נטען ב-Edge, בעוד git clone בתוך ההפצה מגיע לפסק זמן. התצפית הבודדת הזו נקראת בדרך כלל כ«ה-VPN חוסם את WSL2», והשעה הבאה הולכת על עריכת /etc/resolv.conf. הקריאה השימושית יותר היא של-WSL2 מעולם לא היה נתיב הרשת של המארח: הוא פועל ב-VM עזר עם מתאם משלו, מסלולים משלו וקובץ resolver ש-Windows מייצר עבורו. כל מה שלהלן תלוי במי מהשלושה באמת חסר לכם.
ל-VM יש מחסנית, מטריקה ו-resolver משלו
במצב NAT המוגדר כברירת מחדל, ההפצה יושבת מאחורי מתג וירטואלי ומגיעה לאינטרנט דרך המארח, אך אינה רואה את המתאמים של המארח. ip addr מציג ממשק אחד עם כתובת פרטית, ip route מציג נתיב ברירת מחדל דרך אותו מתג, ו-/etc/resolv.conf הוא קובץ שנוצר ומצביע על stub resolver שבחר Windows. שום דבר מזה לא משתנה מפני שקליינט VPN עלה בצד Windows.
לכן «הדפדפן עובד» מוכיח כל כך מעט. הדפדפן משתמש במחסנית של המארח, במנהרה ובמדיניות ה-resolver של המארח. המעטפת שלכם משתמשת במחסנית אחרת שבמקרה חולקת כרטיס רשת פיזי. הם מסכימים במקרה הטוב ונפרדים בדיוק כאשר ה-VPN מתקין מסנן, כותב מחדש את רשימת ה-DNS או מוסיף נתיב לתת-הרשת של המתג הווירטואלי.
שני מבחנים קובעים באיזה עולם אתם נמצאים, והם חייבים לרוץ בתוך ההפצה:
getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.confכשל של שמות בזמן שכתובת מילולית עונה הוא בעיית resolver. כשל של שמות וכתובות יחד הוא בעיית נתיב, ושום סכום של עריכת resolver לא ייגע בה. הראיות מצד Windows מגיעות לאחר מכן: Get-NetAdapter | Get-DnsClientServerAddress ו-route print -4 מראים אם המנהרה תפסה את תת-הרשת שבה חי ה-VM שלכם.
מיתוס ראשון: שרתי ה-DNS הארגוניים פותרים את זה
עריכת קובץ ה-resolver היא העצה הקלאסית, והיא נכונה בערך חצי מהזמן. כשהיא נכונה, היא נכונה מסיבה מסוימת: הקובץ שנוצר מצביע על resolver שמכיר רק שמות ציבוריים, ולכן שאילתה עבור intranet.example.internal חוזרת כלא קיימת למרות שהנתיב תקין.
נעיצת השרתים של ה-VPN פירושה למנוע מ-Windows ליצור מחדש את הקובץ, כי כל קובץ שתכתבו ביד מוחלף באתחול הבא:
[network]
generateResolvConf = falseשמרו אותו בתור /etc/wsl.conf, הריצו wsl --shutdown מ-Windows, ואז הפעילו את ההפצה וכתבו /etc/resolv.conf עם שרתי המנהרה ראשונים ו-resolver ציבורי רק כגיבוי. זהו שינוי מתמשך עם עלות תחזוקה: הקובץ כבר לא עוקב אחרי המארח, כך שכאשר כתובות ה-DNS הארגוניות משתנות ההפצה ממשיכה לשאול את הישנות. מישהו צריך להיות הבעלים של הקובץ הזה.
הוא גם לא עושה דבר כשהכשל רחב יותר. אם curl אל 1.1.1.1 מגיע לפסק זמן, קליינט המנהרה מסנן את המתג הווירטואלי או מנתב את תת-הרשת של ה-VM אל תוך המנהרה, ו-resolver נכון רק נותן לכם שמות שעדיין אי אפשר להגיע אליהם.
מיתוס שני: שינוי המטריקה מחזיק מעמד
כששמות נפתרים אך התעבורה יוצאת דרך המתאם הפיזי, מדדי הממשק הם הידית. תנו למתאם ה-VPN עלות גבוהה ולמתג WSL עלות נמוכה:
Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1אחר כך זכרו שבהרבה גרסאות קליינט מתאם המנהרה נוצר מחדש בכל התחברות והמדד חוזר לברירת המחדל שלו. פקודה חד-פעמית היא תיקון שפג בשקט, בדרך כלל לאורך סוף שבוע, והכרטיס חוזר עם «זה עבד בשבוע שעבר». משימה מתוזמנת שמופעלת על ידי אירוע ה-VPN, או סקריפט שהמשתמש מריץ לאחר התחברות, הם הגרסה הכנה של התיקון הזה.
אותו פקיעה חל על נתיבי מארח שנוספו עבור קידומת עקשנית אחת. יש להם ערך כאבחון, כי הם אומרים לכם אם הבעיה היא יעד אחד או כל הנתיב, אבל הם לא ארכיטקטורה.
מיתוס שלישי: תיקון אחד מכסה כל גרסת Windows
| Approach | What it actually does |
|---|---|
| Resolver pin | Fixes private names only; no effect on path failures |
| Sidecar distribution | Forwards traffic over a socket to a helper VM, so the switch's filter no longer matters |
| Mirrored networking | Gives the distribution the host's interface set; also enables DNS tunnelling |
wsl-vpnkit הוא דפוס ה-sidecar: הפצה קטנה מחזיקה בנתיב בצד המארח ומעבירה עבור הפצות אחרות דרך socket וירטואלי, כך שתעבורת יישומים מפסיקה להיות תלויה במתג המסונן. הוא צריך שהנתיב הסטנדרטי יעבוד, כלומר להסיר את עקיפות networkingMode ו-dnsTunneling מ-%UserProfile%\.wslconfig, לשחזר את generateResolvConf = true בכל הפצה עובדת ולהפעיל את השירות בכניסה.
מצב מראה הוא החלופה המובנית ב-Windows 11 22H2 ואילך, והוא הגדרה אחת ועוד כיבוי:
[wsl2]
networkingMode=mirroredבתוך ההפצה ip addr מציג אז את מתאמי המארח, המנהרה עשויה להופיע ביניהם, ו-מנהרת DNS מעבירה שאילתות דרך ה-resolver של Windows גם כאשר הקליינט כותב מחדש את רשימת ה-DNS. זה לא אוניברסלי: כמה מנהלי התקן סינון עדיין מפילים את הנתיב המראה, וכללי חומת האש של Hyper-V עשויים לדרוש אישור מפורש. מדריך הרשת של WSL של Microsoft הוא העמוד שיש להשוות לגרסה שלכם לפני יישום מתכון שנכתב לגרסה חדשה יותר.
בדקו שלושה דברים אחרי כל שינוי
בחרו מנגנון אחד לכל מכונה וכתבו אותו, כי השניים משתלבים רע. sidecar מעל מצב מראה מכפיל את ההעברה, ומארח מראה עם רשומת sidecar מיושנת ב-.wslconfig נוטה להיכשל אחרי שדרוג ולא לפניו.
בכל בחירה שתבחרו, מבחן הקבלה הוא אותן שלוש בקשות בתוך ההפצה: שם פנימי, שם ציבורי וכתובת גולמית. אחר כך חזרו עליהן לאחר ניתוק וחיבור מחדש של המנהרה, ואחרי wsl --shutdown. כשל של השם הפנימי בלבד פירושו מדיניות resolver; כשל של השם הפנימי והציבורי יחד עם כתובת שעובדת עדיין פירושו מדיניות resolver; כשל של הכול פירושו הנתיב.
אם מארח פנימי אחד נכשל בעוד השאר עובדים, הפסיקו להסתכל על ה-resolver וחפשו נתיב חסר לקידומת הזו. אם הכול עובד עד החיבור מחדש הבא, מצאתם תיקון שתלוי במצב זמן ריצה, וצריך להחיל אותו שוב אוטומטית או להחליפו באחד משני המנגנונים שלמעלה.