WSL2 לא מגיע לרשת המשנה של VPN: קראו את הנתיב במארח

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

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

ודאו היכן הנתיב נעצר

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

בתוך ההפצה, ip -4 addr מציג מתאם וירטואלי עם כתובת מטווח ה-NAT של WSL, ו-ip route מציג נתיב ברירת מחדל אל שער ה-WSL. אין נתיב לקידומת הארגונית, כי למתאם המנהרה של המארח אין מקבילה בתוך ההפצה. שער ברירת המחדל מוביל ל-NAT של WSL, לא לרשת הארגונית.

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

בחרו רשת משוקפת או נתיב בסקריפט

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

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

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

משכו את פרטי המנהרה הנוכחיים מהמארח

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

powershell.exe 'Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" } | Get-NetIPAddress -AddressFamily IPv4 | Select-Object IPAddress, PrefixLength'

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

powershell.exe '(Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" }).InterfaceIndex'
powershell.exe '(Get-NetIPConfiguration -InterfaceIndex 27).IPv4DefaultGateway.NextHop'

העבירו את הפלט דרך tr -d '\r' לפני שאתם מקצים אותו למשתנה. PowerShell מסיים שורות בהחזרת קרון, ובלי ההסרה השדה האחרון נושא תו נסתר שגורם לפקודת נתיב להיכשל בשגיאת פירוש מבלבלת.

החילו את הכתובת והנתיב בתוך ההפצה

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

sudo ip addr add 172.20.14.37/22 dev vpn
sudo ip route add 172.20.0.0/16 via 172.20.12.1 dev vpn

NetworkManager מפיל כתובת שהוגדרה ידנית כשהחיבור מתמחזר, ואף לקוח DHCP לא מבקש מחליפה. הגדירו את השיטה לאוטומטית כדי שכל התחברות מחדש תרענן את הכתובת, ואז העלו את החיבור שוב. שיטה ידנית נראית יציבה עד ההתחברות מחדש הראשונה:

nmcli con show vpn
sudo nmcli con mod vpn ipv4.method auto
sudo nmcli con up vpn

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

קבעו את השם והוכיחו את הנתיב

הליבה יכולה לשנות את שם ממשק ההפצה בין eth1 ל-eth2 אחרי החלפת רשת, ואז סקריפט שנכתב לפי שם עורך את ההתקן הלא נכון. כלל udev שמקושר ל-MAC נותן לממשק תווית יציבה:

SUBSYSTEM=="net", ACTION=="add", ATTRS{address}=="3c:52:82:0a:1b:7c", NAME="vpn"

ואז אמתו עם הכתובת, הנתיב וחיבור TCP אמיתי: ip -4 addr show dev vpn, ip route get 172.20.4.10 וחיבור לפורט פנימי מוכר. חיפוש הנתיב אמור לציין את התקן ה-vpn ואת כתובת המקור שהוספתם.

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

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