האם מטמון נתיבי VPN מסתיר את השינוי שלך? בדקו שלושה דברים

ריקון מטמון הנתיבים הוא האינסטינקט הראשון כששינוי אינו נכנס לתוקף, ובלינוקס מודרני זה מאמץ מבוזבז: מטמון נתיבי IPv4 הגלובלי הוסר לפני שנים, ולכן ip route show cache אינו מדפיס דבר ואין מה לנקות. המצב שמטעה אותך חי שכבה אחת למעלה: ב-socket, במיפוי NAT, בפותר או במנהל רשת שהחיל מחדש את הפרופיל הישן. שלוש שאלות מפרידות בין המקרים האלה: האם הנתיב השגוי מגיע מזרימה חדשה או מחיבור ישן, האם הפלטפורמה שלך שומרת נתיבים במטמון בכלל, והאם המצב בניתוב או מעליו. ענו עליהן לפני שאתם מאפסים ממשק.

בדיקה אחת: האם הנתיב הישן מגיע מזרימה חדשה?

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

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

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

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

בדיקה שתיים: האם הפלטפורמה שלך שומרת בכלל מטמון נתיבים?

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

פלטפורמות אחרות שונות, וכאן העתקת עצות משתבשת. Windows שומר מטמון יעד שאפשר לנקות עם netsh interface ip delete destinationcache. BSD ו-macOS חושפים חיפושים לפי יעד דרך route -n get, והמטמונים שלהם פגים לפי לוח הזמנים שלהם. פקודה שעובדת באחת מהן לא עושה דבר בלינוקס, ולכן אותו תיקון נראה כושל אצל מחצית מהאנשים שמנסים אותו.

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

בדיקה שלוש: האם המצב בניתוב, או מעליו?

קראו את החיפוש הנוכחי לפני כל דבר אחר: ip route get ליעד, אחר כך אותה פקודה עם from וכתובת המקור, אחר כך ip rule show. אם שלושתם תואמים למה שהתכוונתם, הניתוב אינו השכבה לתקן, והתצפית המיושנת הגיעה ממקום אחר.

שלושה חשודים נפוצים יושבים מעל הניתוב. מנהל רשת יכול להתקין מחדש נתיב מפרופיל שמור שניות אחרי שמחקתם אותו, כך שהשינוי שלכם נראה כאילו הוא חוזר; בדקו את nmcli connection show --active ואת מצב היחידה לפני עריכת הטבלה שוב. מטמון פותר מחזיר כתובת ישנה, מה שנראה כמו כשל ניתוב עד שאתם שואלים את אותו שם בכלי שעוקף את המטמון. מאגר החיבורים של אפליקציה מחזיק socket עובד ליעד הישן ולעולם אינו מבקש מהקרנל החלטה חדשה.

מה שלוש התשובות מאפשרות לכם להסיק

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

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

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

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

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

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