למה מסלול VPN שנמחק חוזר אחרי התחברות מחדש

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

מי התקין את המסלול

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

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

קראו את הטבלה לפני עריכה

הביטו בתצוגה של הליבה עצמה ולא בקובץ שמור. עמודת הפרוטוקול מראה מה התקין כל רשומה:

ip route show
ip route show table all
ip rule show

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

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

ip route get 10.20.5.7

שנו את הבעלים, לא את הסימפטום

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

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

התחברו מחדש ואמתו את שני הנתיבים

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

ip route get 10.20.5.7
ip route get 198.51.100.20

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

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