לקוח ה-VPN מוחק את הנתיב שהוספת? השתמשו בטבלת מדיניות

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

המנטר מסביר את הנתיב החסר

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

ip route show
ip route add 192.168.2.0/24 dev enp0s31f6
sleep 5; ip route show

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

טבלה שנייה היא בלתי נראית למנטר

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

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

בנו את החריגה ואז תנו לה לנצח

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

ip rule add to 192.168.2.0/24 table 110 pref 30010
ip route add 192.168.2.0/24 dev enp0s31f6 table 110
ip route get 192.168.2.50

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

צורות אחרות של אותו רעיון

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

ip rule add iif wlan0 table 10
ip route add default dev tun0 table 10

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

התייחסו לכלל כאל חד-פעמי

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

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

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