מעבדת VPN ב-VirtualBox: VM שער לעומת רשת מארחת בלבד
בחרו בין VM שער מנותב לבין מקטע מארחת בלבד עבור מעבדת VPN ב-VirtualBox, ואז גרמו לאורח להיכשל סגור כאשר המנהרה נופלת.
עליכם להחליט כמה מכונות מגיעה למעבדת ה-VPN שלכם. VM שער מנותב בין שני מקטעים של VirtualBox משחזר את תרגום הכתובות, את נתיב החזרה ואת מיקום חומת האש שמאחוריה יושב לקוח אמיתי. מקטע יחיד מסוג מארחת בלבד נותן לכם דלת אחת מבוקרת ולא דבר אחר. גרסת השער עולה שלושה אורחים וטבלת ניתוב שאתם מתחזקים; גרסת המארחת בלבד עולה אורח אחד ומדיניות אחת. שלוש שאלות מפרידות ביניהן, והשלישית מחליטה אם הבדיקה שלכם יכולה לעבור בכלל.
ענו על שלוש שאלות לפני שאתם משכפלים משהו
התחילו במה ששרת ה-VPN חייב לצפות בו. אם השרת חייב לראות כתובת מקור שאינה של אורח הבדיקה, משהו חייב לתרגם ביניהן, והמשהו הזה חייב להיות נתב שאתם שולטים בו. רשת מארחת בלבד נותנת למארחת מתאם במקטע של האורח, לא מתרגם. כשהאורח צריך אחר כך להגיע למשהו בחוץ, אתם מחברים מתאם NAT, ומנוע ה-NAT של VirtualBox עצמו כותב מחדש את המקור בלי לשאול אתכם.
אחר כך שאלו אם האורח רשאי להגיע לשום דבר מלבד דרך המנהרה. התשובה הזו בוחרת פנימי או מארחת בלבד, וזו השאלה שרוב תיאורי המעבדה מדלגים עליה. לבסוף שאלו מה חייב לקרות כשהמנהרה נופלת, כי זה קובע מדיניות ולא טופולוגיה, ומעבדה שמוכיחה רק את המסלול המאושר לא בדקה כמעט דבר.
| What the test requires | Routed gateway VM | Host-only guest |
|---|---|---|
| Server sees a translated source address | Yes, from your own MASQUERADE rule | No, VirtualBox NAT does it instead |
| The guest has exactly one egress | Yes, while the second adapter faces the tunnel | Only until a NAT adapter is attached |
| Policy is testable during a tunnel failure | Rules live in one place | Rules live on each guest |
חברו את שלושת התפקידים עם רשתות פנימיות
השתמשו בשלושה אורחים ושני מקטעים בעלי שם, כשהשער הוא המכונה היחידה שיש לה מתאם בשניהם:
VBoxManage modifyvm lab-client --nic1 intnet --intnet1 WAN
VBoxManage modifyvm lab-server --nic1 intnet --intnet1 LAN
VBoxManage modifyvm lab-gw --nic1 intnet --intnet1 WAN --nic2 intnet --intnet2 LANאין שלב יצירה נפרד לרשת פנימית. המחרוזת ב---intnet1 היא המקטע: שתי מכונות חולקות אותו רק אם השם תואם בדיוק, ושום דבר במארחת אינו מחובר אליו. התכונה האחרונה הזו היא הסיבה שהמעבדה חוזרת על עצמה בצורה נקייה, כי הנתיבים של המארחת, לקוח ה-VPN שלה וחומת האש שלה לא יכולים להגיע לאורחים בטעות. למקטע פנימי גם אין שרת DHCP אלא אם תוסיפו אחד, ולכן כתובות סטטיות הן הדרך הקצרה ביותר.
תנו ללקוח רק את כתובת ה-WAN שלו, עם שער ברירת מחדל שמצביע לכתובת ה-WAN של השער. השרת מקבל כתובת LAN ומשתמש בכתובת ה-LAN של השער כשער ברירת המחדל שלו. אורח שמחזיק שתי כתובות במקטע אחד, או שיש לו נתיב תועה למקטע האחר, נמצא על מסלול סביב הנתב, והבדיקות שלמטה ישקרו לכם.
אני מחזיק קובץ טקסט לצד שמות ה-VM עם ארבע הכתובות ושני שמות המקטעים, ומדביק אותו בכל מעטפת. שבועות אחר כך, כששינוי פרופיל שובר משהו, הקובץ הזה הוא ההבדל בין ניפוי הפרופיל לניפוי הזיכרון שלי.
בחרו פנימי או מארחת בלבד למקטע שאסור לו לדלוף
מצב מארחת בלבד יוצר מתאם וירטואלי במארחת עצמה, בדרך כלל vboxnet0, ונותן למארחת כתובת במקטע של האורח. זה נוח לניהול וקטלני לבדיקת בידוד, כי המארחת יכולה כעת להגיע לאורח ישירות וכל שירות בצד המארחת הופך למסלול אפשרי. למצב פנימי אין מתאם מארחת בכלל. קל לבלבל בין שני המצבים בחלונית הגדרות הרשת, לכן בדקו את ההבדל המתועד ולא את התווית (ראו את העמוד פרטי הרשת של VirtualBox).
עבור אורח שחייב להשתמש במנהרה, פנימי הוא ברירת המחדל הבטוחה יותר, כשהשער הוא היציאה היחידה. אם אתם משאירים מארחת בלבד, התייחסו למתאם המארחת כאל מסלול ניהול ואמרו זאת בקול: המארחת רשאית להגיע לאורח, והאורח לא צריך להיות מסוגל להשתמש במארחת כיציאה.
VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0הבידוד שאתם יכולים להוכיח הוא הבידוד שהגדרתם. לאורח עם מתאם פנימי אחד, נתיב ברירת מחדל בשער ובלי מתאם NAT אין שום מסלול שעוקף את השער. לאורח עם מתאם מארחת בלבד ומתאם NAT יש שני מסלולים, ורק אחד מהם הוא זה שרציתם לבדוק.
נתבו ותרגמו בשער, ואז גרמו לו להיכשל סגור
VirtualBox לא מעביר בין מקטעים; האורח עושה זאת. כשה-VM של שרת ה-VPN מאחורי השער, הפעילו העברה ותרגמו את התעבורה של הלקוח כשהיא יוצאת אל השרת:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADEעם הכלל הזה השרת רואה את כתובת ה-LAN של השער במקום זו של הלקוח, וכך נראה לקוח אמיתי מאחורי NAT של ספק מנקודת המבט של ראש הרשת. שמרו את ערך ה-sysctl ב-/etc/sysctl.d/ ואת הכלל בשירות חומת האש שההפצה משתמשת בו, אחרת אתחול יחזיר את המעבדה בשקט למצב מנותב אך לא מתורגם.
העברה אינה הרשאה. תחת מדיניות FORWARD של ACCEPT כברירת מחדל, אורח שנתיב ברירת המחדל שלו מצביע לשער יוצא דרך הממשק שטבלת הניתוב תבחר, עם מנהרה או בלעדיה. אם לשער יש גם מתאם NAT להתקנת חבילות, המתאם הזה הוא יציאה לא מוצפנת עובדת ברגע שהמנהרה נופלת, והבדיקה שלכם ל-VPN בלבד מעולם לא הייתה בדיקה ל-VPN בלבד.
כשהשרת נמצא מרחוק והשער עצמו מסיים את המנהרה, אותה החלטה מצביעה לממשק המנהרה, לא לכרטיס הרשת שמגיע לאינטרנט:
iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTהחזיקו את התעבורה החיצונית של המנהרה ואת מסלול הניהול מחוץ לרצועה בנפרד מהתעבורה המועברת. אם הדרך היחידה לתקן את השער היא דרך המנהרה שאתם מנתחים, המעבדה הופכת לתרגיל נעילה. קונסול טורי, מתאם ניהול מסוג מארחת בלבד או תמונת מצב של מצב תקין ידוע זולים יותר משיקום ידני של נתב שבור.
אמתו את המסלול מהאורח, לא מהמארחת
עבדו כלפי חוץ. ודאו שהלקוח מגיע לכתובת ה-WAN של השער, אחר כך לשרת דרך השער, ואז שחיבור ליציאת ה-VPN יוצא וחוזר. לכידה בשני הממשקים של השער מראה אם התשובה מגיעה ואם היא נזרקת בנתיב החזרה, מה שלכידה בלקוח בלבד אינה יכולה להבחין:
tcpdump -ni eth0 udp port 1194
tcpdump -ni tun0 udp port 1194אחר כך הוכיחו את היציאה. שאלו מהאורח שירות החזרת כתובות איזה מקור הוא רואה והשוו לכתובת היציאה של השער עצמו; אם התשובה תואמת לכתובת המארחת, קיים מסלול סביב המנהרה. בדקו באיזה פותר האורח באמת משתמש, ובדקו IPv6 בנפרד, כי מקטע שבו IPv6 מופעל בזמן שהמנהרה נושאת רק IPv4 דולף לפי תכנון ולא במקרה.
לבסוף, שברו אותו בכוונה. עצרו את המנהרה, או חסמו את היציאה החיצונית שלה, ופתחו חיבור חדש מהאורח. הוא חייב להיכשל, והסיבה חייבת להיות כזו שתוכלו לנקוב בשמה: אין נתיב, יש כלל דחייה או שהפותר מת. הפעילו מחדש את המנהרה ואמתו שהאורח מתאושש בלי לבנות את הרשת מחדש. אם VPN מבוסס רשת כמו Hamachi או ZeroTier חולק את המעבדה, זכרו שמתאם מגושר הולך לפי שם המתאם ולא לפי הרשת, ולכן יש לכוון את הגשר מחדש לאחר שהלקוח מתקין מתאם וירטואלי משלו.
VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>שיתוף המנהרה של אורח עם המארחת משקף את הבעיה. הפניית נתיב ברירת המחדל של המארחת לאורח עובדת, וכך גם פרוקסי בתוך האורח; NAT דרך המארחת אינו נושא את המנהרה של האורח לתעבורה שהמארחת יזמה. שמרו את שמות המקטעים ואת כללי חומת האש במקום אחד, צלמו תמונת מצב של המצב העובד ורשמו את כתובת המקור שהשרת צפה בה. השינוי הבא בפרופיל יעלה אז הרצת סקריפט אחת במקום מעבדה שנבנתה מחדש.