VPN של האורח ו־VPN של המארח: איזה מסלול באמת מנצח

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

תעדו קודם את החיבור של האורח

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

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

עקבו אחרי נקודת הקצה של האורח החוצה

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

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

השוו תיעוד לפני ואחרי

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

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

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

שמרו על בעלות ברורה לאורך אתחולים

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

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