למה נתיב מנהרה מלא מנתק את השרת שנושא אותו

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

נתיב שאוכל את התעבורה של עצמו

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

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

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

התקינו את החריגה לפני ברירת המחדל

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

רוב הלקוחות עושים זאת בלי בקשה. OpenVPN מחפש את הכתובת המרוחקת ומצמיד אותה לפני שהוא כותב מחדש את שער ברירת המחדל, ואפשרות route-delay שלו קיימת לפלטפורמות שבהן הרצף הזה מתחרה. wg-quick הולך בדרך אחרת לגמרי, בסימון חבילות ובהתייעצות עם כלל מדיניות במקום להוסיף חריגה. מנגנונים שונים, דרישה אחת: החבילה החיצונית חייבת להימלט מהמנהרה שהיא יוצרת.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

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

התמונה המקבילה בשרת

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

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

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

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

חריגות שהמנהרה ממשיכה לגנוב

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

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

חריגה שאיש לא כתב אותה היא חריגה שהבנייה מחדש הבאה תפיל בשקט.

הוכיחו את זה אחרי חיבור מחדש, לא לפניו

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

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

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