מכונת Vagrant נעלמת כשה-VPN מתחבר: של מי הנתיב שנשבר

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

הביטו בנתיב, לא במכונה

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

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

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

ip -4 route get 192.168.56.10
ip -brief addr show
ip route show table main | head -20

קראו את טבלת המארח לפני ואחרי

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

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

Get-NetAdapter | Select-Object Name, InterfaceIndex, InterfaceMetric
Get-NetRoute -DestinationPrefix 192.168.56.0/24
route print -4 | Select-String '192.168.56'

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

כשטווח ה-NAT של האורח הוא ההתנגשות

VirtualBox NAT משתמש כברירת מחדל ב-10.0.2.0/24, ומנהרה שדוחפת את אותו טווח גורמת לאורח לשלוח את התעבורה הזו לשער ה-NAT שלו במקום ליעד האמיתי. החבילה לא עוזבת את המארח לעולם, ולכן שום יומן חומת אש בצד השני לא יראה אותה. ל-Docker Machine יש אותה מחלקת קונפליקט בתוכנית המארח בלבד שלו, ושינוי התוכנית הזו עשוי לדרוש יצירה מחדש של המכונה יחד עם האישורים שלה.

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

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

VBoxManage modifyvm devbox --natnet1 10.77.0.0/24
vagrant reload devbox --provision
vagrant ssh devbox -c 'ip route get 10.20.0.15'

שחזרו את הנתיב בלי להילחם בלקוח

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

כתבו את הבדיקה כסקריפט ולא כחיבור מחדש עיוור באתחול. סקריפט קטן שמדפיס את הנתיב של קידומת האורח אחרי כל חיבור הופך תעלומה לשורה ביומן.

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

בדקו את התיקון בשני הצדדים

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

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

ip -4 route get 192.168.56.10
traceroute -n -m 4 10.20.0.15
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

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