להפעיל את ה-VPN במארח או בתוך ה-VM? מדריך החלטה
בעל המנהרה קובע מה מכסה מה. בחרו מיקום במארח או באורח, ואז אמתו אותו בבדיקות מסלול, DNS ויציאה בתוך האורח.
בניית המנהרה בתוך האורח ובנייתה במארח משנות שתיהן את הכתובת שהדפדפן מדווח, ושם נגמר הדמיון. מנהרה בבעלות האורח שומרת את המפתחות שלה, את מסלול ברירת המחדל שלה ואת הפותר שלה בתוך גרעין האורח, בעוד המארח מעביר מנות מוצפנות לכתובת מרוחקת אחת. מנהרה בבעלות המארח היא התמונה ההפוכה: לקוח המארח מחזיק בהפעלה ומיישם מסלולים ומדיניות, והאורח לווה את מה שיוצא. בחרו בבעלים הלא נכון וכל תסמין מאוחר יותר ישלח אתכם למכונה הלא נכונה. שתי פקודות מכריעות את השאלה בכדקה בערך, ושאר המדריך הזה הוא מה לעשות עם התשובה.
החליטו מי הבעלים לפני שאתם נוגעים בלקוח
הכלל עוסק במקום שבו מיוצר הטקסט המוצפן, לא במכונה שמציגה סמל VPN. אם האורח מייצר אותו, האורח זקוק למסלול עובד לשרת ה-VPN ולשום דבר אחר מהמארח. אם המארח מייצר אותו, האורח זקוק לכך שהנתיב דרך המארח ישרוד כל מדיניות שלקוח המארח כופה על תעבורה מקומית.
שלוש שאלות בדרך כלל בוחרות את המיקום בשבילכם. האם התעבורה של האורח חייבת לשרוד לקוח ארגוני במארח? אז המנהרה שייכת לאורח. האם כמה אורחים זקוקים לאישור אחד ולכתובת יציאה אחת? אז היא במארח, עם העברה שהוגדרה בכוונה. האם התעבורה של האורח אמורה להישאר מחוץ ל-VPN של המארח לגמרי? אז מנהרה באורח היא הסידור היחיד שנותן לכם את זה מכוח הבנייה.
רשמו את התשובה בשורה אחת לצד שם ה-VM: guest-owned או host-owned. במעבדה של שש מכונות ההערה הזאת חוסכת יותר זמן מכל שלב שלמטה, כי היא מונעת מכם לאתר תקלה במנהרה שמעולם לא הייתה במכונה שאליה התחברתם.
WSL1 ו-WSL2 הם מקרים הפוכים
WSL1 אינו מכונה וירטואלית, ולכן שאלת המיקום מתנדפת ברובה. הקבצים הבינאריים של לינוקס שלו רצים מול מחסנית הרשת של Windows דרך שכבת תרגום, ולקוח VPN של לינוקס אין ממשקים עצמאיים להגדיר. הסידור שעובד הוא מנהרה בצד Windows, כשההפצה משתמשת בתוצאה בלי להחזיק בדבר.
WSL2 הוא ההפך. הוא מריץ גרעין אמיתי במכונה וירטואלית עזר קלת משקל מאחורי מתג וירטואלי של Hyper-V, ומרחב הכתובות שלו מתורגם ב-NAT דרך מתאם בצד המארח. לכן לקוח לינוקס בתוך ההפצה מתנהג כפי שהיה מתנהג בקופסת לינוקס פיזית: הוא יוצר tun0 או wg0, מתקין מסלולים משלו ועובד. הכשל חי בצד המארח. כשלקוח VPN של Windows מתחבר עם מדיניות שחוסמת תעבורה ברשתות מקומיות, הוא מתייחס לתת-הרשת של WSL2 כרשת מקומית לא מהימנה וקוטע את נתיב ה-NAT. אז ההפצה מאבדת DNS וגישה יוצאת בזמן שהמנהרה שלה עצמה עדיין בריאה: wg show מדווח על לחיצת יד, ip route נראה תקין, ו-curl נתקע.
איזה תיקון תוכלו להשתמש בו תלוי בגרסת Windows. הוותיק יותר הוא חריגה בלקוח המארח עבור תת-הרשת של WSL, שמתווספת תחת הגדרות הרשת המקומית או המנהרה המפוצלת של הלקוח. החדש יותר, בגרסאות Windows 11 שתומכות בו, הוא רשת משוקפת: שימו networkingMode=mirrored בקטע [wsl2] של %UserProfile%\.wslconfig, הריצו wsl --shutdown, וההפצה תשתף את הממשקים של המארח במקום תת-רשת NAT פרטית. מצב משוקף משנה גם את התנהגות localhost והפורטים הנכנסים, אז התייחסו אליו כהגירה ולא כמתג.
NAT, גשר ומה המארח יכול לראות
תחת NAT, מנות המנהרה של האורח ממוענות לכתובת הציבורית של שרת ה-VPN ויוצאות דרך מתאם המארח כ-UDP או TCP מוצפן. המארח רואה זרימה אחת ואת מספר הבתים שלה, שום דבר על היעדים שבתוכה. תחת מתאם מגושר לאורח יש זהות משלו בשכבה 2 ברשת ה-LAN הפיזית, הוא לוקח חכירת DHCP משלו, ונראה לכל מדיניות מבוססת MAC כמו התקן שני. אף אחד מהמצבים לא מאפשר למארח לקרוא את המטען של המנהרה; האורח המגושר פשוט הרבה יותר גלוי לרשת שסביבו.
יש גם רצפה לבידוד. אורח לא יכול להתחבא מהמכונה שבבעלותה הזיכרון שלו, ומי ששולט במארח יכול לקרוא מפתחות מה-RAM של האורח. מה שמנהרה באורח נותנת לכם הוא גבול ניתוב וגבול תוכנה זדונית, לא הגנה מפני האדם שמחזיק במחשב הנייד. כדאי להחזיק פתוחים את מצבי המתאם המתועדים בזמן שאתם בוחרים, כי המצב משנה גם את מה שהמארח רואה וגם את מה שה-LAN רואה.
מדריך: מקם, הגדר, הוכח
הריצו את ארבע הבדיקות האלה לפי הסדר במעטפת אורח חדשה, ועצרו בראשונה שאינה מתיישבת עם הבעלים שרשמתם.
ip route get 1.1.1.1שמחזירtun0אוwg0פירושו בעלות האורח, ו-eth0עם קפיצה פרטית הבאה פירושו בעלות המארח.resolvectl query example.com, או קראו את/etc/resolv.confבמקום שבו האורח אינו מריץ שירות פותר. מנהרה שנושאת תעבורה אך לא DNS היא המצב החצי-מוגדר הנפוץ ביותר.- השוו יציאות:
curl -4 -s https://ifconfig.meבאורח לעומתcurl.exe -4 -s https://ifconfig.meבמארח. כתובות שונות פירושן שהאורח מחזיק במנהרה, ומארח על ה-VPN עם אורח שמציג את ספק הבית הוא המקרה שבו שום דבר לא עבר בירושה. - חזרו על שניהם עם
-6. מנהרה של v4 בלבד מדליפה v6 אלא אם הלקוח חוסם או מנתב אותו, והרבה לקוחות משאירים v6 על הממשק הפיזי כברירת מחדל.
בתכנון של שער במארח, שבו כמה אורחים חולקים מנהרה אחת, המארח חייב להעביר ולתרגם. במארח לינוקס אלה שלושה חלקים, והאורח נופל בשקט חזרה למסלול הרגיל שלו כשאחד מהם חסר:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPTבצד WireGuard, ה-AllowedIPs של עמית המארח חייב לכלול את תת-הרשת של האורחים, למשל 192.168.122.0/24, אחרת מנות החזרה לא יגיעו לעולם וההגדרה תיראה כמו בעיית חומת אש. מארח Windows משיג אותה תוצאה עם שיתוף חיבור לאינטרנט או כלל NAT במתג Hyper-V, וזקוק לאותה בדיקת נתיב חזרה.
כשהפריסה עדיין פתוחה, הטבלה הזו מכסה את הסידורים הנפוצים ביותר:
| Situation | Owner | Check first |
|---|---|---|
| One VM, host also on a corporate VPN | Guest | Does the host client block local networks? |
| Six lab VMs, one exit address | Host plus forwarding | ip_forward, NAT rule, server AllowedIPs |
| Malware or research VM | Guest, NAT | Snapshot age and resolver state |
| Bridged VM on an office LAN | Guest | DHCP lease and port security |
שתי מנהרות, שני אורחים והקונפליקטים ביניהן
כשאתם צריכים שתי יציאות בבת אחת, הדפוס שמחזיק הוא מנהרה אחת לכל אורח. כל VM שומר על מסלול ברירת המחדל ועל הפותר שלו, המארח נשאר ברשת הרגילה, ושתי המנהרות לא מתווכחות לעולם על אותה טבלת ניתוב. גישור בין שני אורחים גם לא מאחד את המסלולים שלהם: הרשת הווירטואלית מספקת נתיב, ועדיין צריך לומר לכל לקוח שהתעבורה המקומית הזו רשאית לעקוף את המנהרה.
הרצת מנהרת מארח ומנהרת אורח יחד היא לגיטימית, וקינון מכוון הוא לפעמים בדיוק מה שאתם רוצים, כשהאורח יוצא דרך המנהרה שלו וזו יוצאת דרך זו של המארח. מה שהופך את זה לתקלה הוא שאיש לא רשם איזו נקודת קצה אמורה להיות מושגת דרך איזו שכבה. החזיקו רשימה של שתי עמודות עם יעד ובעלים, והתנגשות מסלולים הופכת לחיפוש במקום אחר צהריים של גילוי.
אמתו, ואז השאירו את השחזור אצל הבעלים
בדקו מבפנים האורח עם תהליך יישום חדש: תעבורה, פתרון שמות, שתי משפחות הכתובות ומה קורה כשהמנהרה נופלת. סמל ה-VPN של המארח לא אומר דבר על הכיסוי של האורח, וזה האישור הכוזב הנפוץ ביותר בכל התחום הזה.
השחזור שייך לבעלים גם כן. מנהרה בבעלות האורח משוחזרת על ידי הלקוח של האורח עצמו והמסלולים שהוא כתב. תכנון בבעלות המארח משוחזר על ידי רצף האתחול של המארח, וכללי ההעברה לא שורדים אתחול אלא אם יחידה או משימת אתחול מחילה אותם מחדש. תמונת מצב משוחזרת היא פריסה, לא ביטול, כי היא מחזירה אישורים ישנים ומסלולים ישנים יחד עם הדיסק. לפני שאתם מכריזים שהעבודה נגמרה, ודאו שהבעלים עדיין תואם לשורה שרשמתם, ש-DNS ושתי משפחות הכתובות נפתרים בתוך האורח, שמנהרה מתה משאירה רשת שמישה במקום חור שחור, ושאתחול או שחזור תמונת מצב משחזרים את אותו מצב.