למה net.ipv4.conf.default.forwarding משאיר את tun0 בשקט

הגדרתם net.ipv4.conf.default.forwarding=1, הפעלתם מחדש את ה-VPN, והמנהרה עדיין מפילה מנות שהשער אמור לנתב. ההגדרה נראית נכונה בקובץ, והממשק עדיין מדווח שהעברה קדימה מושבתת. שום דבר לא שבור: שיניתם את הערך שממשקים עתידיים יורשים, לא את זה שהמנהרה הפעילה משתמשת בו.

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

קראו את שלושת הערכים יחד

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

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

תוצאה נפוצה היא ip_forward = 0, default.forwarding = 1 ו-tun0.forwarding = 0. השניים הראשונים לא מסכימים לגבי תפקיד המארח, והשלישי מראה מה הממשק באמת עושה. השילוב הזה מתאים למארח שמעולם לא הוגדר כנתב, אלא רק קיבל ערך מתבנית. שלושת המספרים אינם סותרים זה את זה; הם עונים לשלוש שאלות שונות. גם כתיבת ערך התבנית לא מכריעה את תפקיד המארח.

למה דווקא המתג הגלובלי הוא זה שזז

net.ipv4.ip_forward הוא הבקרה ברמת השער. שינוי שלו מעדכן את הגדרות ההעברה קדימה לכל ממשק כחלק מאותה פעולה, ולכן כתיבה אחת יכולה לגרום למנהרה קיימת להתחיל להעביר קדימה. default.forwarding זורע רק ממשקים שמאותחלים אחר כך, ולכן מנהרה שכבר הייתה קיימת שומרת על הערך שאיתו נולדה.

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

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

הפכו את ההגדרה לקבועה במקום הנכון

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

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

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

אל תתקנו את זה בכלי הלא נכון

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

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

הפרידו את מקרה IPv6

כאן הכול IPv4. להעברה קדימה של IPv6, להודעות נתב ולהתנהגות accept_ra יש בקרות משלהן, והעתקת מסלול ipv4 לתוך הגדרת ipv6 מייצרת קובץ שנראה סביר ולא עושה דבר מועיל. שער עם מחסנית כפולה צריך את שתי הקבוצות מוגדרות בכוונה.

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