בדקו את ניתוב המדיניות של לינוקס לפני עריכת נתיב ברירת המחדל

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

הסדר חשוב: קודם הכללים, אחר כך הטבלה שכל כלל בוחר.

קראו את הכללים לפי סדר עדיפות

הריצו ip rule show וקראו מלמעלה למטה. מספר העדיפות קובע את סדר ההערכה, ומספר קטן יותר נבדק קודם. כלל ברירת המחדל ב-32766 הוא בדרך כלל האחרון שחשוב. אם הרשימה ארוכה, שמרו אותה בקובץ לפני שתשנו משהו.

לכל כלל, רשמו את העדיפות, את ההתאמה (מקור, סימון, ממשק או יעד) ואת הטבלה שאליה הוא מפנה. כלל ללא טבלה שמישה הוא מבוי סתום, לא נתיב.

עשו אותו דבר ל-IPv6 עם ip -6 rule show. מדיניות שקיימת רק במשפחת IPv4 משאירה את המשפחה האחרת בטבלה הראשית.

קראו את הטבלה שכל כלל בוחר

השתמשו ב-ip route show table <name or number> לכל טבלה מוזכרת. השוו את הנתיבים שלה לממשק ולקפיצה הבאה שאתם מצפים לה. טבלה ריקה או חלקית מסבירה כשל שהטבלה הראשית לא יכולה.

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

חפשו את שם הטבלה ב-/etc/iproute2/rt_tables אם המספר אינו מוכר. החיפוש הזה לוקח שנייה ומונע עיקוף ארוך.

גלו מי התקין את הכלל

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

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

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

בדקו את הקשר המקור שחשוב

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

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