WSL2: מדריך מתקדם לתצורת רשת ומצבי NAT ​​ומצבים שיקוף

Informatec Digital » משאבים » WSL2: מדריך מתקדם לתצורת רשת ומצבי NAT ​​ומצבים שיקוף

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

הבנת תצורת הרשת של WSL2, מצבי ה-NAT והמשוק שלה, השימוש ב-.wslconfig ו-wsl.conf, וכיצד הם מקיימים אינטראקציה עם חומות אש, VPN, Docker וכלים כמו Tailscale היא המפתח למניעת כאבי ראש. נראה שלב אחר שלב כיצד כל ההתקנה הזו עובדת, כיצד לחשוף שירותים ל-Windows ולרשת הרשת המקומית, אילו פקודות להשתמש כדי לקבל את כתובות ה-IP הנכונות, ואילו אפשרויות תצורה מתקדמות עומדות לרשותך כדי לכוונן את הסביבה שלך, להפוך אותה ליציבה ומעל הכל, מאובטחת.

איך הרשת עובדת בפועל ב-WSL2

WSL2 כבר לא חולק את מחסנית הרשת המארחת כמו WSL1במקום זאת, היא מפעילה כל הפצת לינוקס בתוך מכונה וירטואלית קטנה המנוהלת על ידי Hyper-V. למכונה וירטואלית זו יש מתאם וירטואלי משלה (בדרך כלל eth0) וכתובת IP פרטית שהוקצתה על ידי מתג וירטואלי פנימי.

במצב ברירת המחדל שלו, WSL2 משתמש בארכיטקטורה מבוססת NAT (תרגום כתובות רשת). Windows משמש כנתב/מארח, והפצת לינוקס נמצאת ברשת משנה פרטית, בדרך כלל בתוך הטווח. 172.16.0.0/12תת-רשת זו יכולה להשתנות לאחר אתחול מחדש או הפעלה מחדש של WSL, דבר ששיגע יותר מאדם אחד בעת הגדרת כללי חומת אש סטטיים.

מנקודת מבט מעשית, משמעות הדבר היא שכתובת ה-IP של הפצת WSL2 שלך אינה יציבה או נגישה ישירות מה-LAN כפי שהיה במקרה של WSL1: כברירת מחדל, יש קישוריות בין Windows ל-WSL2 רק דרך כללי ניתוב מחדש ו-NAT, וחשיפה לרשת המקומית דורשת צעדים נוספים או שימוש במצב שיקוף.

בנוסף לארכיטקטורת בסיס זו, Windows 11 22H2 וגירסאות מאוחרות יותר מוסיפות יכולות רשת חדשות. (מצב שיקוף, dnsTunneling, autoProxy, חומת אש של Hyper-V וכו') הנשלטים מהקובץ הגלובלי .wslconfigבעוד שאפשרויות מסוימות בתוך לינוקס מנוהלות באמצעות /etc/wsl.conf.

זיהוי כתובות IP ב-WSL2

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

תרחיש 1: ב-Windows, ברצונך לדעת את כתובת ה-IP של הפצת WSL2 כדי שאפליקציה במארח (לדוגמה, לקוח, דפדפן או כלי בדיקה) תוכל להתחבר לשירות הפועל בתוך לינוקס. לשם כך, תוכל להפעיל את הפקודות הבאות ב-Windows (CMD או PowerShell):

wsl.exe --distribution <DistroName> hostname -i

אם ברצונך להשתמש בהפצה המוגדרת כברירת מחדל, תוכל להשמיט את פרמטר ההפצה. ופשוט להתקשר wsl.exe hostname -iברקע, פקודה זו מופעלת בלינוקס hostname --ip-addresses ומחזירה את כתובת ה-IP של המופע. תוצאה אופיינית עשויה להיראות בערך כך:

172.30.98.229

תרחיש 2: מהפצת לינוקס, עליך לדעת את כתובת ה-IP של מארח Windows , לדוגמה, כדי שאפליקציית WSL2 תוכל להתחבר לשרת הפועל באופן מקורי על Windows (Node.js, SQL Server, Caddy וכו'). בתוך מעטפת לינוקס, תוכל להשתמש ב:

ip route show | grep -i default | awk '{ print $3 }'

הפלט יהיה שער ברירת המחדל של המכונה הווירטואלית WSL2 , התואם לכתובת ה-IP של מארח Windows כפי שנראה מ-Linux, משהו כמו:

172.30.96.1

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

מצב NAT: התנהגות ברירת מחדל של רשת WSL2

WSL2 עובד במצב NAT כבר מהקופסה, ועבור סביבות פיתוח פשוטות רבות, זה יותר ממספיק . הדבר החשוב הוא להבין מה עובד "בכוחות עצמו" ומה לא, כדי שלא תבזבזו זמן במרדף אחרי רוחות רפאים.

גישה לשירותי לינוקס מ-Windows באמצעות localhostאם אתם מפעילים יישום רשת (לדוגמה, שרת Node.js, שרת Flask, שרת SQL בלינוקס) בהפצת WSL2 שלכם, תוכלו לגשת אליו מ-Windows באמצעות localhost:puertoWindows מעביר אוטומטית חיבורים נכנסים לכתובת ה-IP הפנימית של המכונה הווירטואלית WSL2.

גישה לשירותים הפועלים על Windows מ- Linux : דברים משתנים כאן. כדי להגיע ליישום רשת במארח (כגון שרת Node.js, SQL Server או Caddy ב- Windows) מ- WSL2, עליך להשתמש בכתובת ה- IP של המארח כפי שנראית בלינוקס, המתקבלת באמצעות פקודת ה- path המוגדרת כברירת מחדל:

ip route show | grep -i default | awk '{ print $3 }'

עם כתובת ה-IP הזו אתה יכול להתחבר מלינוקס לכל שירות במארח, לדוגמה http://172.30.96.1:3000 אם שרת Windows שלך מאזין לפורט 3000 בכל הממשקים.

כאשר אתה מתחבר באמצעות כתובות IP מרוחקות (לא localhost), יישומים רואים אותן כחיבורי LAN.משמעות הדבר היא שיש להגדיר שרתים רבים להאזנה 0.0.0.0 במקום 127.0.0.1לדוגמה, עם Flask תוכלו להפעיל:

app.run(host='0.0.0.0')

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

גישה ל-WSL2 מרשת התקשורת המקומית (LAN) באמצעות NAT

אחד השינויים המעצבנים ביותר במעבר מ-WSL1 ל-WSL2 הוא שההפצות אינן נגישות יותר ישירות מה-LAN . ב-WSL1, אם מערכת ה-Windows שלך הייתה גלויה ברשת, שירותי ההפצה ירשו את החשיפה הזו כמעט ללא מאמץ.

ב-WSL2, למכונה הווירטואלית יש כתובת IP פרטית משלה והיא אינה מפורסמת אוטומטית ברשת ה-LAN . כדי להשיג משהו דומה להתנהגות הישנה, ​​במצב NAT עליך ליצור שרת פרוקסי ב-Windows, בדיוק כפי שהיית עושה עם כל מכונה וירטואלית Hyper-V.

Windows כולל כלי קלאסי לכך: netsh interface portproxyפקודה אופיינית להפניית פורט מארח לכתובת ה-IP/פורט של WSL2 תהיה:

netsh interface portproxy add v4tov4 listenport=<puertoHost> listenaddress=0.0.0.0 connectport=<puertoWSL> connectaddress=(wsl hostname -I)

בפועל, היית מחליף את הסמנים בערכים ספציפיים , לדוגמה:

netsh interface portproxy add v4tov4 listenport=4000 listenaddress=0.0.0.0 connectport=4000 connectaddress=192.168.101.100

כאן listenaddress=0.0.0.0 זה מציין ש-Windows יאזין לכל כתובות ה-IPv4 של המארח.ויעביר את מה שנכנס דרך פורט 4000 אל 192.168.101.100:4000אשר תהיה כתובת ה-IP של WSL2 שתתקבל באמצעות:

• wsl hostname -I זה נותן לך את כתובת ה-IP של הפצת לינוקס בתוך ה-VM של WSL2.
• cat /etc/resolv.conf זה חושף את כתובת ה-IP של מארח Windows Vista מ-WSL2.

בעזרת טכניקה זו ניתן להפוך שירות הפועל על WSL2 לנגיש מכל מחשב ברשת המקומית (LAN) , כל עוד חומת האש של Windows מאפשרת זאת ואתה ברור שאתה חושף שירות של מכונה וירטואלית, ולא של המארח ישירות.

IPv6 ותכונות רשת מודרניות

WSL2 יכול לעבוד גם עם IPv6, דבר שרלוונטי במיוחד בסביבות מודרניות, VPN ורשתות ארגוניות . כדי לנהל כתובות, הפקודות הבסיסיות בלינוקס שוות ערך לאלו של IPv4:

• wsl hostname -i מ-Windows כדי להציג את כתובת ה-IP של הפצת WSL2
• ip route show | grep -i default | awk '{ print $3 }' מלינוקס כדי לקבל את כתובת ה-IP של מחשב המארח של Windows

הקפיצה האמיתית באיכות התמיכה ב-IPv6 וב-VPN היא במצב רשת משוקף , הזמין ב-Windows 11 22H2 וגירסאות מאוחרות יותר, אותן נראה בפירוט בהמשך.

מצב רשת משוקף: שיקוף ממשקי Windows בלינוקס

במחשבים עם Windows 11 22H2 ומעלה, ניתן להפעיל את מצב הרשת "המשתקף" ב-WSL2, מה שמשנה לחלוטין את המודל: במקום NAT קלאסי, לינוקס "רואה" את ממשקי הרשת של Windows משתקפים.

כדי להפעיל זאת, עליך לערוך את הקובץ .wslconfig של המשתמש שלךשנמצא ב %UserProfile%\.wslconfigמ-PowerShell עם הרשאות מנהל, ניתן לפתוח אותו באמצעות:

notepad $env:USERPROFILE\.wslconfig

בפנים, הוסיפו (או שנו) את הקטע [wsl2] כדי להפעיל מצב שיקוף :

[wsl2]
networkingMode=mirrored

לאחר שמירת הקובץ, עליך להפעיל מחדש את WSL2 כדי שהוא ייכנס לתוקף , לדוגמה עם:

wsl --shutdown

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

• תמיכה מקורית ב-IPv6 ושילוב משופר עם רשתות ארגוניות ו-VPN
• יכולת להתחבר לשירותי Windows מ- Linux באמצעות 127.0.0.1 directamente (למרות שזה אסור) ::1 (כגון לולאת IPv6 לשם כך)
• תמיכה משופרת בשידור מרובה (multicast) בתוך האינטגרציה בין Windows ל-Linux
• גישה ישירה ל-WSL מה-LAN ללא צורך ב-netsh portproxyבאמצעות כתובת ה-IP של מכונת ה-Windows עצמה

הפעלת מצב זה פותרת רבות מבעיות ה-WSL2 NAT הקלאסיות וזו האפשרות המומלצת ברוב סביבות הפיתוח והאחסון העצמי המודרניות שבהן ניתן להשתמש ב-Windows 11 מעודכן.

מנהור DNS ושימוש בפרוקסי ב-WSL2

ב-Windows 11 22H2 וגירסאות מאוחרות יותר, זיהוי שמות מ-WSL2 עבר גם הוא שיפוץ משמעותי.המפתח טמון בשתי פונקציונליות המוגדרות ב .wslconfig: dnsTunneling y autoProxy.

אפשרות dnsTunneling זה מופעל כברירת מחדל במקטע [wsl2]. זה מאפשר לטפל בבקשות DNS של לינוקס באמצעות תכונת וירטואליזציה, במקום להישלח כחבילות רשת רגילות. זה משפר מאוד את התאימות עם VPN ותצורות רשת מורכבות במארח.

מצד, autoProxy=true מאלץ את WSL להשתמש בהגדרות הפרוקסי של Windows HTTPאם המארח נמצא מאחורי פרוקסי תאגידי או אבטחתי, WSL2 יורש אותו אוטומטית מבלי שתצטרך להתמודד עם משתני סביבה באופן ידני.

יכול להיות לך, למשל, משהו כזה בפנים .wslconfig:

[wsl2]
dnsTunneling=true
autoProxy=true

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

חומת אש של Hyper-V וחשיפה לשירות מאובטח

בסביבות מודרניות, רשת WSL2 עוברת גם דרך חומת אש ייעודית . החל מ-WSL 2.0.9 ב-Windows 11 22H2, תכונת חומת האש של Hyper-V מופעלת כברירת מחדל, ומוסיפה שכבת סינון נוספת לתעבורת מכונות וירטואליות (כולל תעבורת WSL2).

אם אתם עובדים במצב שיקוף וברצונכם לחשוף לצמיתות שירותי WSL2 לרשת ה-LAN (למשל, ממשקי API, לוחות מחוונים או שירותי אירוח עצמי), עליכם לוודא שכללי חומת האש מאפשרים זאת.

גישה סבירה מ-PowerShell עם הרשאות מנהל היא ליצור כלל Hyper-V עבור רשתות פרטיות :

New-NetFirewallHyperVRule -DisplayName "WSLPrivateInboundRule" -Profiles Private -Direction Inbound -Action Allow -VMCreatorId ((Get-NetFirewallHyperVVMCreator).VMCreatorId)

אם מסיבה כלשהי ברצונך להשבית את הגנת Hyper-V הספציפית הזו (וזאת פחות מומלצת), תוכל להשתמש ב:

Set-NetFirewallHyperVVMSetting -Name ((Get-NetFirewallHyperVVMCreator).VMCreatorId) -Enabled False

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

ארכיטקטורת רשת WSL2, טווחי X11 ו-172.16.0.0/12

מקרה קלאסי שחושף פרטים על רשת WSL2 הוא השימוש ביישומים גרפיים דרך X11 , לדוגמה הפעלת Xming ב-Windows ושליחת יישומי לינוקס דרך DISPLAY.

בעת שדרוג מ-WSL1 ל-WSL2, משתמשים רבים מגלים ש-X מפסיק לעבוד. מכיוון שהרשת מפסיקה להיות "משותפת" והופכת לרשת NAT וירטואלית עם טווחים כגון 172.16.0.0/12אשר יכול גם להשתנות לאחר כל הפעלה מחדש של Windows או WSL.

כדי לגרום ל-X לעבוד שוב עם Xming מ-WSL2, הטריק הרגיל הוא להשיג את כתובת ה-IP של Windows ש-Linux רואה באמצעות:

ENS

DISPLAY=$(grep nameserver /etc/resolv.conf | cut -d' ' -f2):0

במקביל, יש צורך להתאים את חומת האש של Windows כדי לאפשר תעבורת X11 מאותה תת-רשת NATגישה אופיינית היא לערוך את כלל ה-Xming על ידי הוספת הטווח 172.16.0.0/12 ב-TCP+UDP 6000.

רבים בסופו של דבר מבטלים את אימות ה-Xming עם האפשרות -acזה למעשה "פותח את הדלת" לכל לקוח X שמגיע מאותה רשת. זה עובד, אבל מבחינה ביטחונית זה די מפוקפק, אז כדאי לשקול פתרונות מוגבלים יותר או להשתמש ב-WSLg (יישומי GUI משולבים) ב-Windows 11.

wsl.conf ו- .wslconfig: תצורת WSL2 מתקדמת

WSL מציע שני קבצי תצורה עיקריים השולטים הן בהתנהגות המכונה הווירטואלית והן בהתנהגות של כל הפצה.: /etc/wsl.conf (על ידי הפצה) ו %UserProfile%\.wslconfig (גלובלי עבור כל הפצות WSL2).

wsl.conf חי בתוך הפצת לינוקס, ב /etc/wsl.confהוא משמש להגדרת אפשרויות מקומיות עבור אותה הפצה: הרכבות אוטומטיות, יצירה של hosts y resolv.confיכולת פעולה הדדית עם Windows, משתמש ברירת מחדל, systemd וכו'.

.wslconfig הוא נשמר מחוץ ללינוקס, בפרופיל המשתמש של חלונות. (C:\Users\<Usuario>\.wslconfig) ושולט בפרמטרים גלובליים של המכונה הווירטואלית שמפעילה את WSL2: זיכרון, מעבדים, ליבה, מצב רשת, חומת אש, DNS, גודל דיסק וירטואלי, תמיכה בממשק משתמש גרפי וכו'.

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

כדי לאלץ הפעלה מחדש של תת-מערכת ניתן להשתמש ב :

• wsl --list --running כדי לבדוק אם יש הפצות פעילות
• wsl --shutdown לסגור את כל ההפצות בבת אחת
• wsl --terminate <distroName> כדי לעצור הפצה ספציפית

רק כאשר WSL כבוי ומופעל מחדש, שינויי התצורה מוחלים בפועל , דבר שרבים מתעלמים ממנו וחושבים שההגדרות שלהם "לא עובדות".

אפשרויות wsl.conf עיקריות לפי מקטע

את הקובץ wsl.conf זה בהשראת הפורמט הקלאסי .ini, עם מקטעים ומפתחותהסעיפים העיקריים הם [automount], [network], [interop], [user], [boot], [gpu] y [time].

En [automount] אתה שולט באופן שבו כונני Windows מותקנים בתוך לינוקס (בדרך כלל נמוך) /mnt):

• enabled (bool, ברירת מחדל true)אם נכון, C:/, D:/ וכו' מותקנים אוטומטית ב /mnt/c, /mnt/d...
• mountFsTab (בול)אם זה נכון, זה מעובד /etc/fstab בעת הפעלת ההפצה.
• root (שַׁרשֶׁרֶת): ספריית השורש שבה יותקנו הכוננים, לדוגמה /windir/ יש /windir/c.
• options (רשימה מופרדת בפסיקים)פרמטרים ספציפיים ל-DrvFs כגון metadata, uid, gid, umask, fmask, dmask o case.

DrvFs היא מערכת קבצים המגשרת בין Windows ו- Linux , שנועדה לגשת ל- NTFS מ- WSL עם בקרת הרשאות, מטא-דאטה ורגישות לאותיות גדולות וקטנות.

בקטע [network] אתה מתאים את היצירה האוטומטית של קבצי רשת:

• generateHostsאם זה נכון, WSL יוצר אוטומטית /etc/hosts.
• generateResolvConfאם זה נכון, WSL יוצר /etc/resolv.conf עם DNS מדור קודם.
• hostnameשם המארח שבו ההפצה תשתמש.

מדור [interop] שולט על יכולת פעולה הדדית עם Windows:

• enabled: מאפשר או מבטל את היכולת להפעיל תהליכי Windows מ-WSL.
• appendWindowsPath: מחליט האם להוסיף נתיבי Windows אל $PATH לינוקס.

En [user] ניתן לציין את המשתמש שישמש כברירת מחדל בעת הפעלת ההפצה:

• default: שם משתמש שיופעל כברירת מחדל ב-WSL.

מדור [boot] זה שימושי במיוחד ב-Windows 11 וב-Server 2022 כדי להפעיל באופן אוטומטי שירותים, כגון Docker בתוך WSL:

• commandמחרוזת פקודה לביצוע בעת הפעלת WSL, לדוגמה service docker start.
• protectBinfmt: מגן על יצירת יחידות systemd כאשר systemd מופעל.

יש לך גם מדורים כמו [gpu] (לאפשר גישה לכרטיס המסך של Windows מ-Linux), ו- [time] כדי לסנכרן את אזור הזמן עם Windowsזה מונע בעיות בעת מעבר לשעון קיץ או נסיעה.

.wslconfig: בקרת מכונה וירטואלית WSL2

בעוד שקובץ wsl.conf מכוון את ההתנהגות של כל הפצה, קובץ .wslconfig מאפשר לך לכוונן את המכונה הווירטואלית המשותפת לכל הפצות WSL2 . קובץ זה רלוונטי רק להפצות הפועלות כ-WSL2, ולא כ-WSL1.

בתוך .wslconfig החלק הראשי הוא [wsl2]היכן שאתה מגדיר פרמטרים מרכזיים:

• kernel y kernelModulesנתיבים מוחלטים מ-Windows לליבה מותאמת אישית של לינוקס ולמודולים שלה.
• memoryמגבלת זיכרון של מכונה וירטואלית (ברירת מחדל 50% מזיכרון המארח), לדוגמה 4GB.
• processorsמספר המעבדים הלוגיים שהוקצו למכונה הווירטואלית.
• localhostForwardingמאפשר גישה לפורטים פתוחים ב-WSL2 מ-Windows באמצעות localhost.
• swap y swapFileגודל ונתיב קובץ ההחלפה עבור המכונה הווירטואלית.
• guiApplications: מאפשר או מבטל תמיכה ביישומי GUI (WSLg).
• dnsProxyכאשר אתה במצב NAT, הוא מחליט אם שרת ה-DNS של לינוקס יהיה מופע ה-NAT של המארח או עותק של ה-DNS של Windows.
• networkingModeכאן אתם בוחרים בין none, nat, bridged (מְיוּשָׁן), mirrored o virtioproxy.
• firewall, dnsTunneling y autoProxy: אפשרויות שדנו בהן כדי לשלב טוב יותר את רשת ה-WSL עם מדיניות Windows.
• defaultVhdSize: גודל מקסימלי של ה-VHD שבו מאוחסנת מערכת הקבצים של ההפצה (ברירת מחדל 1 טרה-בייט).

יש גם מדור [experimental] היכן מופעלות תכונות בבדיקות כמו:

• autoMemoryReclaimהגדרות שחזור זיכרון אוטומטי (מושבת, הדרגתי, dropCache).
• sparseVhdיצירת דיסקים וירטואליים דלילים כדי לחסוך מקום.
• bestEffortDnsParsing y dnsTunnelingIpAddressכוונון עדין עבור מנהור DNS.
• ignoredPorts: פורטים שאפליקציות לינוקס יכולות להשתמש בהם גם אם הן נמצאות בשימוש ב-Windows כאשר אתה במצב שיקוף.
• hostAddressLoopbackמאפשר למארח ולקונטיינר להתחבר באמצעות כתובות IP מקומיות של המארח במצב שיקוף.

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

WSL2, Docker ורשתות לאירוח עצמי עם Tailscale

מקרה מעשי מאוד הוא שימוש ב-WSL2 על שרתי Windows (אפילו Windows Server 2025) כפלטפורמת אירוח עצמי , המשלבת Ubuntu על WSL2, Docker Engine (ללא Docker Desktop), Tailscale ו-Reverse Proxy כמו Caddy כדי לחשוף שירותים כמו n8n או Supabase.

המטרה היא ליצור סביבת Docker יציבה בתוך WSL2, תוך הימנעות מבעיות של Docker Desktop בשרתים . על ידי התקנת Docker Engine ישירות על אובונטו (WSL2), רשת הקונטיינרים מסתמכת על רשת WSL2, אשר בתורה תלויה ב-NAT או במצב שיקוף המוגדר בקובץ wslconfig.

עם Tailscale מותקן על WSL2, תוכלו לפרסם את השירותים שלכם על גבי VPN מסוג mesh מבלי לפתוח פורטים בנתב, ולהשתמש ב-Caddy כ-Reverse Proxy כדי לרכז אישורי TLS, נתיבים ואיזון עומסים קל משקל בין קונטיינרים.

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

• בחר מצב רשת קוהרנטי יחיד (NAT או משוקף) ותעד אותו
• הימנעו מקונפליקטים בין פורטים בין Windows ל-WSL2, בהסתמך על ignoredPorts אם אתה משתמש במראה
• שלוט בחשיפת השירות רק באמצעות Tailscale או Caddyבמקום לפתוח פורטים "כברירת מחדל" בחומת האש
• אוטומציה של ההפעלה של Docker, Tailscale ו-Caddy מ- [boot] ב-wsl.conf כדי שתהיה סביבה קרובה יותר לייצור

עם ארכיטקטורה זו, WSL2 מפסיק להיות רק כלי פיתוח ויכול להפוך לפלטפורמת אירוח עצמי רצינית למדי , בתנאי שמקבלים את המגבלות שלה (וירטואליזציה על Hyper-V, שכבת רשת נוספת וכו') ומגדירים אותה בקפידה.

שיטות עבודה מומלצות לרשתות WSL2 לפיתוח ובדיקה

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

עבור שירותי פיתוח, השתמשו בפורטים גבוהים (מעל 1024) והימנעו מפורטים בעלי זכויות יתר או כאלה שנמצאים בשימוש רב; זה ממזער התנגשויות ומבטל את הצורך בהרשאות נוספות.

ודא שהקוד והנתונים נמצאים בתוך מערכת הקבצים של לינוקס. (אתה ~/ או מסלולים פנימיים) במקום לעבוד ישירות על /mnt/cמכיוון שגישה ל-NTFS מ-WSL איטית יותר ויכולה לפגוע בשירותים עתירי קלט/פלט.

אוטומציה של הגדרות רשת וכללי ניתוב מחדש באמצעות סקריפטים ב-PowerShell וב-Bash: לדוגמה, סקריפט שמגדיר את WSL2 בעת הפעלתו. netsh portproxy (אם תמשיך עם NAT) או בדוק את כללי חומת האש בעת שימוש בשיקוף.

הימנעו מהסתמכות על שינוי כתובות IP שנוצר על ידי המתג הווירטואלי הפנימי. במידת האפשר, עבדו עם localhost, שמות מארחים או ערכים ב /etc/hosts עבור השירותים שלך, כך ששינוי IP לא יפגע בחצי מתשתית הבדיקות שלך.

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

כאשר מוגדר כראוי, WSL2 מציע רשת מבודדת אך גמישה, מושלמת לפיתוח מתקדם, בדיקות API, עבודה עם קונטיינרים וסימולציה של סביבות מבוזרות . המפתח טמון בשליטה במצבי רשת (NAT לעומת mirrored), בקבצי wsl.conf ו- .wslconfig, ובאינטראקציה עם חומת האש והכלים במחסנית (Docker, Tailscale, reverse proxies), כך ש-Windows ו-Linux יוכלו לפעול על אותה מכונה ללא התנגשויות פורטים או פגיעה באבטחה.