תשובות ה-VPN של לינוקס נעלמות? בדקו rp_filter ואת הנתיב

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

מה אימות המקור מחליט

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

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

קראו את המצב בפועל, לא שדה אחד

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

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

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

מצאו את אי-ההתאמה לפני שתשנו את הבדיקה

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

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

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

התאמה סלקטיבית שאפשר להגן עליה

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

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

הפרידו בין IPv4 ל-IPv6

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

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