איך להבחין בין מסלולים שנדחפים על ידי VPN לבין מסלולים סטטיים ב-Linux

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

שלב 1: תנו שם למנגנון שמתקין קידומות

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

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

שלב 2: השוו את הטבלה לאורך חיבור

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

לכדו אותה עם ip route show table main > /tmp/route-down.txt, התחברו ולכדו שוב. עשו את אותו דבר עבור ip -6 route אם האתר משתמש ב-IPv6, כי קידומת חסרה שם מייצרת כשלים שנראים לא קשורים לניתוב.

שלב 3: קראו את המדד, לא רק את הנוכחות

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

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

שלב 4: מצאו את הרשומות ששורדות את המנהרה

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

בדקו את הצד הקבוע במקום שבו ההפצה שלכם משתמשת בו, בין אם יחידת systemd-networkd, פרופיל NetworkManager או סקריפט בתיקיית up של הלקוח. תיקון הטבלה החיה עם ip route del מחזיק רק עד החיבור הבא. התייחסו למחיקה הזו כמבחן של ההשערה ולא כתיקון.

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

שלב 5: אשרו את נתיב החזרה לפני שאתם מאשימים את הלקוח

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

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

שלב 6: בדקו את המשאב, לא את ה-ping

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

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