NAT או רשת VM מגושרת: מה נושא את תעבורת ה-VPN?

אורחי NAT שואלים את המנהרה של המארח רק אם הלקוח מנהר לפי מסלול; אורחים מגושרים מנתבים בעצמם. בדקו את האורח ואז בחרו את המצב המתאים.

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

NAT משאיר את האורח מאחורי קוד ההיפרבייזר, היכן שמסלולי המארח חלים

ב-VirtualBox אורח NAT יושב על 10.0.2.0/24 עם שער וירטואלי ב-10.0.2.2, פרוקסי DNS ב-10.0.2.3, ובלי מסלול משל עצמו לרשת הפיזית. חבילות יוצאות נלקחות על ידי מנוע ה-NAT, נכתבות מחדש כך שהמקור הוא המארח, ומועברות למחסנית ה-IP של המארח. משם התעבורה של האורח היא זרימה של המארח, וחיפוש המסלול הוא לפי יעד: לקוח מנהרה מלאה שמתקין 0.0.0.0/1 ו-128.0.0.0/1 על המארח לוכד אותה בלי לדעת אי פעם שקיימת VM. הפרק של Oracle על רשתות ב-VirtualBox מפרט את ברירות המחדל האלה אם אתם רוצים לאמת את הכתובות בבנייה שלכם.

רשת ברירת המחדל של libvirt מגיעה לאותו מקום מ-192.168.122.0/24, שם dnsmasq מחלק חכירות והמארח עושה masquerade לתת-הרשת, כך שהחבילות של האורח מגיעות שוב להחלטת הניתוב של המארח. היוצא מן הכלל הוא לקוח שבוחר תעבורה לפי תהליך ולא לפי מסלול. אם רשימת המנהרה המפוצלת מכילה רק את הדפדפן שלכם ושום דבר אחר, מנוע ה-NAT לא נמצא ברשימה הזו, והאורח יוצא מהמכונה בלי מנהרה בעוד הדפדפן של המארח עדיין נראה מכוסה. אותה תת-רשת, תוצאה הפוכה.

גישור נותן לאורח מקום משלו ב-LAN הפיזי

אורח מגושר מקבל כרטיס רשת וירטואלי המחובר למתאם אמיתי, מקבל כתובת MAC משל עצמו ולוקח חכירת DHCP מהרשת הפיזית. שער ברירת המחדל שלו הוא נתב ה-LAN, לא ההיפרבייזר, והמסגרות שלו יוצאות לכבל דרך המתאם הזה. מסלולי המנהרה של המארח חיים בטבלה של המארח ולא נשאלים לעולם, כי המסגרות של האורח לא נכנסות אף פעם למחסנית ה-IP של המארח.

זה חותך לשני הכיוונים. mDNS וגלישה ב-SMB מתחילים לעבוד כי האורח רואה תעבורת שידור של ה-LAN, והאורח נעשה נגיש ממכונות אחרות באותו קטע בלי חומת אש של המארח באמצע. גישור גם אינו דרך לדחוף אורח דרך מנהרה קיימת: חיבור VM לממשק ה-WireGuard או ה-OpenVPN של המארח אינו משהו ש-VirtualBox או libvirt עושים בשבילכם. אם אורח מגושר חייב לעבור במנהרה, המנהרה חייבת להסתיים איפשהו באותו LAN.

הבדיקה שמסיימת את הוויכוח

הריצו את אותן בדיקות בשני המצבים וכתבו את התשובות:

  • במארח, curl -s https://ifconfig.me נותן את כתובת ה-v4 הציבורית.
  • באורח, אותה פקודה, ועוד ip route בלינוקס או Get-NetRoute -DestinationPrefix 0.0.0.0/0 ב-Windows עבור שער ברירת המחדל.
  • זהות הפותר: resolvectl status או cat /etc/resolv.conf באורח, כדי לראות אם הוא מצביע ל-10.0.2.3 או לשרת ב-LAN.
  • משפחת כתובות: ip -6 addr show scope global ובקשה אחת של v6, כי מנהרת v4 לא אומרת דבר על כתובת v6 גלובלית שאולי יש לאורח.

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

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

איזה מצב מתאים לעבודה

המצב הוא החלטת ניתוב, אז בחרו אותו לפי הדרישה ולא לפי הרגל:

RequirementMode that fits
Every guest flow must exit through the host tunnelNAT, with a host client that tunnels by route, verified from inside the guest
The guest needs its own VPN account or profileBridged, or NAT with a client running inside the guest, not both
The guest must serve SSH, SMB, or a dev server to the LANBridged; NAT needs a port forward, which does not change the outbound path
The guest must stay invisible to the LANNAT; a bridged guest is another host on the segment
The guest needs a real public IPv6 addressBridged; VirtualBox NAT mode has no IPv6 forwarding
Isolation from the LAN with access to the hostHost-only adapter, not NAT

השורה הראשונה היא המקום שבו אנשים נתפסים: NAT ועוד לקוח מנהרה מלאה במארח אכן מכסה אורח, אבל רק כל עוד הלקוח מנהר לפי מסלול והקישור העליון של המארח הוא המנהרה הזו. העבירו את הלקוח לרשימת היתר לדפדפן בלבד והכיסוי נעלם בלי שום שגיאה בשום מקום. השורה הרביעית היא הטעות ההפוכה: אורח שגושר מטעמי נוחות ומתחיל בשקט לענות ל-SMB או ל-SSH ב-LAN של המשרד.

כשלים שמטילים על ה-VPN

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

גישור ל-Wi-Fi הוא הקלאסיקה האחרת. נקודות גישה ממעטות להעביר מסגרות עם MAC מקור זר, כך שגשר ל-wlan0 או נכשל לגמרי או עובד עד שבידוד לקוחות בנקודת הגישה מתחיל להפיל אותו. VirtualBox עדיין יציע את המתאם האלחוטי ברשימה שלו. אם המארח על Wi-Fi והאורח חייב להיות מגושר, תכננו לבדוק את זה במקום להניח.

MTU הוא השלישי. אורח מגושר שומר על MTU של 1500 בתים של ה-LAN, ואם הוא מריץ לקוח WireGuard משלו על 1420, לחיצות ידיים גדולות של TLS נתקעות בזמן שבקשות קטנות מצליחות. תחת NAT, ה-MTU של מנהרת המארח הוא הבעיה של המארח, אבל האורח עדיין מאמין ב-1500, ו-UDP עם ביט ה-don't-fragment מופעל נעלם באותה דרך.

רשמו את המצב ובדקו שוב אחרי כל שינוי מתאם

רשמו את המצב, את ממשק המארח שהגשר משתמש בו, את שער ברירת המחדל של האורח, את הפותר שלו ואת כתובות היציאה v4 ו-v6 שלו. הרישום הזה הוא מה שהופך את הכשל הבא לזול: כשמחשב נייד עובר מהעגינה ל-Wi-Fi, אורח מגושר עוקב אחרי הגשר למתאם פיזי אחר ועלול לחכור מחדש בתת-רשת אחרת, בעוד אורח NAT שומר על כתובת 10.0.2.x שלו ויורש בשקט קישור עליון אחר.

לפני סגירת הפנייה, אשרו כל אחד מאלה:

  • כתובת היציאה של האורח שונה מכתובת היציאה של המארח, כך שהוא לא במנהרה של המארח.
  • הפותר הוא פרוקסי 10.0.2.3 או שרת ב-LAN, ואתם יודעים מי ענה.
  • אין כתובת v6 גלובלית באורח אם תכנון המנהרה הוא v4 בלבד.
  • כשהמנהרה של המארח למטה, האורח מפסיק לגלוש, או שאתם יודעים עכשיו שהוא מעולם לא היה תלוי בה.
  • האורח לא רואה תעבורת שידור של ה-LAN שלא נוגעת לו.

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