VPN מקונן: איזה מנהרה נושאת את החיבור החיצוני?

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

שלושה תנאים קובעים את הקינון

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

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

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

תנאי ראשון: איזו נקודת קצה זקוקה לאיזה נתיב

ip route get 203.0.113.10 עונה על השאלה הזו ישירות: הוא מדפיס את הנתיב, את כתובת המקור ואת הממשק שהקרנל היה משתמש בו עבור היעד הזה כרגע.

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

תנאי שני: בדקו את הנתיב בכל שכבה

בחירת נתיב היא יותר מהטבלה הראשית בלקוח מודרני. כללי מדיניות יכולים לשלוח חבילות מסומנות לטבלה אחרת, לקוח יכול לקשור את הסוקט שלו לממשק, ולמכולה או למרחב שמות יש טבלאות משלו. ip rule ו-ip route show table all הם הדרך לגלות איזה מהמנגנונים האלה פועל.

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

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

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

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

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

מה השרשרת לא נותנת לכם

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

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