תיעוד של מנהרה מפוצלת זקוק לכלל DNS לצד כל נתיב
נתיב מחליט לפי כתובת, פותר מחליט לפי שם. תעדו את שני הבוררים לכל זרימה, כל אחד עם בדיקה אחת, אחרת ההערה נכשלת כשמ-DNS זז.
הערה על מנהרה מפוצלת שאומרת "תעבורת המשרד עוברת דרך ה-VPN" תיעדה החלטה אחת ורמזה על שלוש נוספות. בשכבת החבילות טבלת ניתוב בוחרת ממשק לפי כתובת היעד; בשכבת השמות פותר בוחר שרת לפי שאילתה, ושתי הבחירות נעשות באופן בלתי תלוי. לכן קידומת מתועדת נכון עדיין יכולה ליצור מכונה שפותרת שם פנימי לכתובת ציבורית, או שאינה פותרת דבר בזמן שהנתיב נראה מושלם.
שני בוררים, ניסיון חיבור אחד
כאשר יישום מתחבר אל files.corp.example, מתרחשות שתי חיפושים לפני שקיים חבילה. הפותר מחליט איזה שרת יקבל את השאילתה, באמצעות דומיינים לחיפוש, דומיינים לניתוב לפי קישור או כלל פרופיל מפורש. לאחר מכן טבלת הניתוב מחליטה לאן הולכת הכתובת המתקבלת, באמצעות ההתאמה הארוכה ביותר של קידומת ליעד.
שום דבר אינו מחבר את שתי ההחלטות. אזור פרטי יכול להשיב עם 10.20.4.11 בעוד טבלת הניתוב שולחת את 10.20.0.0/16 אל המנהרה, והחיבור עובד. הפכו אחד מהם והוא נכשל באופן שנראה כמו האחר: מדיניות DNS נכונה בתוספת נתיב חסר נותנת שם פתור ופסק זמן, בעוד נתיב נכון בתוספת פותר ציבורי נותן כתובת שמנותבת נקי למקום הלא נכון.
DNS עם אופק מפוצל מחדד את זה. אותו שם יכול להחזיר כתובת פרטית מהפותר הפנימי וכתובת ציבורית מהפותר הפונה לאינטרנט, לכן הערה שמתעדת רק את הקידומת אינה יכולה לחזות איזו כתובת הלקוח ישתמש בה בפועל. כתבו את נתיב הפותר או שהכתובת היא ניחוש.
מה הערה של נתיב בלבד מחסירה
רשומה של נתיב בלבד חסרת תועלת לכשל הנפוץ ביותר של מנהרה מפוצלת: שמות. המשתמש מדווח ש הרשת הפנימית לא נטענת, המנהרה פעילה והקידומת קיימת. מי שלוקח את הפנייה אין לו רשומה איזה פותר היה אמור להשיב, אין לו דרך להבחין בין סיומת חיפוש שגויה לבין שרת חסום, ואין לו קו בסיס להשוואה.
ההשמטה השנייה היא רשימת החריגים. עיצוב של מנהרה מפוצלת מוגדר באותה מידה על ידי מה שנשאר מחוץ למנהרה כמו על ידי מה שנכנס אליה, והטווחים המוחרגים הם בדרך כלל אלה שנשברים ראשונים, מפני שנתיב מקומי ספציפי יותר או מסנן בצד הלקוח יכול לעקוף את הכוונה בלי לגעת בפרופיל.
השלישית היא הצד הרחוק של המנהרה. נתיב לקוח רק שם את החבילה על החוט; השער עדיין צריך להעביר אותה ולהחזיק נתיב חזרה. המדריך של strongSwan ל העברה מזכיר שכללי העברה וחומת אש בשער הם חלק מהתכונה, לא חלק מהאינסטלציה שאפשר להניח.
השדות שהופכים את ההערה לניתנת לביצוע
שורה לכל זרימה, וזרימה היא יעד ועוד שם ועוד בעלים. אלה השדות ששורדים מפגש עם תקרית אמיתית:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
השורה "איפה זה חי" היא זו שאנשים מדלגים עליה. קידומת שנדחפת על ידי השרת, נתיב שנוסף על ידי פרופיל לקוח ונתיב שהוקלד במעטפת נבדלים במי יכול לשנות אותם ובאם הם שורדים התחברות מחדש. בלי השדה הזה, המהנדס הבא לא יכול לדעת איזה משלושת אלה הוא רואה.
בדיקה אחת לכל כלל, לא אחת לכל מנהרה
כל שורה זקוקה לשתי בדיקות בלתי מזיקות: אחת שמפעילה את הנתיב ואחת שמפעילה את השם. לנתיב, בקשו משהו שחייב לחצות את המנהרה ואשרו את המסלול ולא את הנגישות, למשל tracert -d 10.20.4.11 ב-Windows או ip route get 10.20.4.11 ב-Linux. לשם, שאלו את השם הפרטי ותעדו איזה שרת השיב, באמצעות resolvectl query files.corp.example או dig files.corp.example מול הפותר שההערה מציינת.
הוסיפו גם ציפייה שלילית: מה אמור לקרות כשהמנהרה למטה. יישום מוחרג במכשיר Android או iOS עם חסימה בלי VPN מופעלת עשוי שלא להיות לו חיבור כלל, ולקוח שולחני יכול להשאיר את אותו יישום עובד בזמן שהמנהרה מתחברת מחדש. תיעוד התשובה המיועדת הופך את "ה-VPN שבר לי את היישום" לאמירה ניתנת לבדיקה.
שמרו את הרשומה עם התצורה
אחסנו את ההערה לצד הפרופיל שהיא מתארת ותנו לה גרסה עם אותו פרופיל. מסמך בוויקי שאיש אינו מעדכן הוא שמועה; טבלה באותו מאגר כמו הנתיבים הנדחפים ומדיניות הפותר ניתנת לבדיקה באותו שינוי.
כשמשהו נשבר, השוו את הנתיב המיושם ואת הפותר האפקטיבי לרשומה לפני שמוסיפים חריג נוסף. שניים משלושת הגורמים הנפוצים — כלל מרחב שמות ישן ותהליך עזר מחוץ למדיניות היישום — נראים בדיוק כמו תקלת VPN ואינם נראים אם ההערה מפרטת רק קידומות.
לפני שאתם מכריזים שההערה מוכנה, אשרו שהיא משיבה בכתב לאלה: איזו קידומת, לאיזו משפחת כתובות; איזה מרחב שמות פרטי, באיזה פותר נענה; אילו שמות נשארים ציבוריים במכוון; היכן כל כלל מוגדר ומי הבעלים שלו; והפקודה האחת שמוכיחה את הנתיב והאחת שמוכיחה את השם. אם משהו מהם חסר, התקרית הבאה תאובחן מאפס.