ניתוב תעבורת VM ברשת host-only דרך שרת TUN OpenVPN

מתאמי host-only יוצרים רשת וירטואלית מקומית, ומנהרות TUN מנותבות נושאות חבילות IP בין כתובות. אף אחד מהם אינו גשר אל השני, ולכן תצורה שעובדת חייבת לומר מי מעביר ומי הבעלים של נתיב החזרה. אם שני התפקידים האלה מתחלפים, האורח עונה למנהרה עם מקור שהלקוח של המנהרה מעולם לא ביקש. התכנון שלמטה שומר על שתי התחיליות נפרדות ועושה את נתיב החזרה מפורש.

שתי רשתות, שתי תחיליות

תנו לבריכת המנהרה ולרשת host-only תחיליות שונות ואל תשתמשו באחת למען השנייה. בדוגמה הזו בריכת ה-VPN היא 10.44.0.0/24 ורשת host-only היא 192.168.99.0/24, כשהמארח ב-192.168.99.1 ואורח ב-192.168.99.20. הקצאת אותה תחילית גם להתקן TUN וגם למתאם host-only אינה מחברת ביניהם. היא יוצרת שתי תביעות על טווח כתובות אחד, וטבלת הניתוב עונה אז לזו שבמקרה נשארה.

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

המארח כבר מחזיק בנתיב

הסתכלו במה שקיים לפני שמוסיפים משהו. למארח יש ממשק ברשת host-only ונתיב לתחילית הזו, שניהם נוצרו כשהמתאם עלה.

ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forward

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

דחפו את הנתיב, ואז סננו את מה שהוא משיג

השרת יכול לספק את תחילית host-only ללקוחות שמקבלים נתיבים דחופים, וזה אותו מנגנון שמשמש לכל תת-רשת אחרת מאחורי המנהרה.

push "route 192.168.99.0 255.255.255.0"
iptables -A FORWARD -i tun0 -o vboxnet0 -d 192.168.99.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vboxnet0 -o tun0 -s 192.168.99.20 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

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

האורח צריך דרך חזרה

אורח שאליו מגיעים מ-10.44.0.x חייב לשלוח את תשובותיו לכתובת ה-host-only של המארח, או שהמארח חייב לתרגם את המקור. קבלת כתובת מ-DHCP של VirtualBox לא אומרת דבר על אף אחד משני הסידורים.

ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15

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

התקן TUN נושא חבילות IP, ולכן הוספת שער ברירת מחדל בתוך אורח אינה הופכת את המנהרה למקטע Ethernet עם מתאם host-only. גישור TAP הוא תכנון אחר עם תמיכת לקוחות ובעלות כתובות משלו, וערבוב שתי התיאורים מוביל לתצורות שלעולם אינן מתכנסות.

אמתו, ואז עשו שזה ישרוד אתחול

בדקו שירות אחד בלתי מזיק מלקוח מרוחק רגיל, בדקו את נתיב החזרה של האורח, ואשרו ששירות שלא התרתם נדחה ולא איטי.

ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20

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