שני קפיצות VPN על Pi אחד: איזה מסלול נושא איזה עמית
שתי כתובות מנהרה על Pi אחד אינן תקלה. כל יעד צריך נושא משלו, הוכחה משלו ותוכנית חלופית מוצהרת כשהקפיצה החיצונית מתה.
שתי כתובות מנהרה על לוח קטן אחד נראות כמו טעות, והרפלקס הוא למחוק אחת. הרפלקס הזה שובר את מה שהוא היה אמור לסדר. מארח הנושא שתי קפיצות מחזיק כתובת אחת לכל חיבור, וכל כתובת נבחרת על ידי מסלול אחר. השאלה ששווה לשאול היא איזה מסלול בוחר איזה נושא לאיזה יעד, ולא כמה כתובות קיימות.
שלושה יעדים שזקוקים לנושאים שונים
שרשרת של שתי קפיצות היא שלושה סוגי יעד מוערמים, וכל אחד נישא על ידי חיבור אחר. יש להגיע לעמית החיצוני דרך הקישור הפיזי. יש להגיע לעמית הפנימי דרך המנהרה החיצונית. יש להגיע ליעד של היישום המכוסה דרך המנהרה הפנימית, שאת התעבורה שלה נושאת החיצונית.
| Destination class | View that names the carrier | Command that proves it | Symptom when the wrong carrier wins |
|---|---|---|---|
| Outer peer, 198.51.100.10 | the main table, by destination | ip route get 198.51.100.10 | the outer handshake never completes |
| Inner peer, 203.0.113.7 | the main table once the outer tunnel is up | ip route get 203.0.113.7 | the inner handshake leaves over the physical link |
| Application destination, 172.30.9.1 | the table the inner client's traffic is selected into | ip route get 172.30.9.1 from 10.8.0.2 | the exit address looks right and the traffic never crossed the outer hop |
| Parallel tunnels, one per source group | one policy per group, not the main table | ip rule show beside a marked test connection | both tunnels are up and one steals the other's traffic |
מלאו את השורות בכתובות האמיתיות של הקורא לפני שנוגעים במסלול, כי הטבלה שימושית רק כשהיא קונקרטית. שרשרת עובדת מספקת את כל ארבע השורות בו זמנית, ושרשרת עובדת למחצה מספקת בדרך כלל אחת מהן עם הנושא הלא נכון. קריאת השורה הלא נכונה בתור התקלה היא מה שהופך בעיית ניתוב לצהריים שלמים של עריכות.
לכתובות יש תפקידים, לא מספר
לינוקס מתיר כמה כתובות על ממשק אחד וכמה מנהרות על מארח אחד, ולכן מספר אינו אומר דבר על נכונות. מה שחשוב הוא איזו כתובת שייכת לאיזה חיבור, והאם המסלול עבור עמית נתון בוחר את החיבור שהתכוונתם אליו. שלוש תצוגות עונות על כך משלושה כיוונים, וכדאי לקרוא אותן באותו סדר בכל פעם.
מלאי הכתובות מראה מה קיים ואיזה חיבור מחזיק בו. טבלת המסלולים עונה על שאלת הנושא עבור תעבורה רגילה ליעדים. תצוגת המדיניות עונה עליה שוב עבור תעבורה שנבחרת לפי מקור או סימון, וזה הסידור הרגיל כששני לקוחות חולקים מארח אחד.
ip -4 addr show
ip -4 route show table all
ip rule showמחיקת כתובת מפני שהרשימה נראית ארוכה עלולה להסיר חלק מהנתיב, ומחיקת מסלול מפני שהוא נראה מיותר עושה את אותו הדבר בשקט רב יותר. אף אחד מהם אינו מייצר שגיאה; העמית פשוט מפסיק להשיב בנתיב שהתכוונתם אליו תוך שהוא נשאר נגיש בדרך אחרת. יישום שמדווח את כתובת היציאה של העמית הפנימי אינו מוכיח שהתעבורה חצתה את המנהרה החיצונית, שכן גישה ישירה מייצרת את אותה תצפית. הפער הזה בין תצפית להוכחה הוא הסיבה לבדיקת הנושא בשכבת הניתוב.
סדר ההפעלה מנצח המתנה קבועה
אם הלקוח הפנימי תלוי בכתובת או במסלול שהלקוח החיצוני מספק, ההפעלה צריכה להמתין למשאב הזה ולא לעיכוב. המתנה קבועה עובדת עד היום שבו המנהרה החיצונית איטית, ואז היא נכשלת לסירוגין באופן שאיש אינו יכול לשחזר. סדר המבוסס על תלות מסיר את הניחוש ולא עולה דבר מלבד תיאור התלות פעם אחת. גם שמות ממשקים אינם מנגנון סדר.
הליבה מחלקת שמות כמו tun0 ו-tun1 לפי סדר היצירה, והסדר הזה יכול להשתנות בין אתחולים או חיבורים מחדש. קשרו את התצורה לזהות שהכלי מספק, או לשם שאתם מקצים במכוון. שם שאתם בוחרים הוא חוזה; שם שהליבה בוחרת הוא מקרה.
החזיקו את התעבורה של כל לקוח מחוץ לנתיב היישום של האחר, והיו מדויקים לגבי ההבטחה האמיתית של אפשרויות הניתוב של OpenVPN 2.6. מנגנון ההפניה מחדש המוגדר כברירת מחדל המתועד משאיר לקוח מסוגל להגיע לעמית המרוחק שלו דרך השער שכבר היה קיים, מה שחותך לולאת רקורסיה מסוימת. הוא אינו הופך לקוח אחד לנושא של אחר, ולכן שאר השרשרת נשארת העיצוב שלכם. היכן שהשרשרת זקוקה למדיניות ולא למסלול, כתבו כלל מקור או סימון מפורש ובדקו אותו עם התעבורה שהוא אמור להתאים לה.
מה קורה כשהקפיצה החיצונית מתה
לפני שהשרשרת נחשבת שלמה, החליטו מה קורה כשהקפיצה החיצונית נעלמת. התעבורה של הלקוח הפנימי מתה איתה, והצעד הבא הוא שאלת מדיניות ולא שאלה טכנית: להיכשל, לנסות שוב, או להתחבר מחדש ישירות דרך הקישור הפיזי. התוצאה השלישית היא זו שכדאי לחשוב עליה. היא הופכת בשקט עיצוב של שתי קפיצות לעיצוב של קפיצה אחת ברגע שבו המשתמש מאמין שהכיסוי עדיין שלם.
אם שתי קפיצות הן חובה, הלקוח הפנימי חייב להיות לא מסוגל להקים נתיב ישיר כשהחיצונית נעלמה, והדרך לדעת היא לשבור את הקפיצה החיצונית ולצפות במה שהפנימית עושה. תוכנית חלופית מאושרת היא תשובה לגיטימית, אבל צריך לכתוב אותה, לבדוק אותה ולדווח עליה. תוכנית חלופית שאיש לא תיעד אינה ניתנת להבחנה מדליפה במהלך סקירת תקרית.
DNS ומשפחת הכתובות האחרת שייכים לאותה החלטה. חיפוש שנוצר מקומית הולך לפי המדיניות של המארח עצמו ולא לפי זו של לקוח מועבר, ולכן המפענח שעובד עבור תעבורה מועברת עשוי שלא להיות זה שהמארח עצמו משתמש בו.
קבלו כל שכבה לפי הסדר שבניתם אותה
בדקו לפי הסדר שבו נבנתה השרשרת: תחילה המנהרה החיצונית לבדה, אחר כך התעבורה של הלקוח הפנימי דרך המנהרה החיצונית, אחר כך היישום דרך המנהרה הפנימית. כל קבלה חייבת להיות חיבור חדש ולא דף שהיה פתוח כבר. אחר כך שברו ושחזרו כל שכבה בנפרד וצפו במה שהבאה עושה.
תוצאת התוכנית החלופית היא התצפית היקרה ביותר כאן, וזו שדף IP ציבורי אינו מראה לעולם. שמרו את נתיבי העמיתים, הכתובות שהם משתמשים בהן ואת התוצאה הזו לצד התצורה, כי המסלול המאושר אינו החלק שנשאל עליו מאוחר יותר.