היפרוויזר של מעבדת הבית אינו נגיש דרך VPN: היכן לחפש

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

התחילו במקטע הניהול

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

ואז שני הנתיבים. לקוח ה-VPN זקוק לנתיב אל רשת הניהול, שבדרך כלל פירושו שה-AllowedIPs של הלקוח או הנתיבים הנדחפים כוללים את תת-הרשת הזו. ההיפרוויזר, או שער ברירת המחדל שלו, זקוק לנתיב חזרה אל מאגר כתובות הלקוחות, אלא אם התכנון מתרגם את המקור בכניסה במכוון. אלו שתי עובדות נפרדות והיעדר של אחת מהן יוצר את אותו פסק זמן. בדקו אותן בנפרד: ip route get 192.168.10.20 בלקוח, ולכידה במארח ההיפרוויזר שמראה אם החבילה הגיעה בכלל.

אפשרו את מנהל המערכת המרוחק האמיתי

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

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

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

בדקו חיבורים משניים

תכונות מסוימות משתמשות בחיבורים שדף האינטרנט אינו משתמש בהם. הפעלת קונסולה, העלאת ISO, פרוקסי VNC או SPICE וערוץ העברה יכולים כל אחד להשתמש בפורט אחר או בכתובת מארח אחרת. כשהדף נטען ותכונה אחת נכשלת, קראו את הדרישה של אותו מוצר במקום לפתוח כל פורט במארח.

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

שמרו דרך חזרה לפני שאתם נוגעים ברשת

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

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

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

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

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