ניתוב מקור לשני מאגרי VPN: מה הכלל שלכם מפספס
כלל מהצורה from מתאים לכתובת הלקוח לפני ש-SNAT כותב אותה מחדש, ובדיקה מהשער אינה מתאימה לאף אחד מהם. הריצו את החיפוש לכל מאגר וקראו במקום זאת את העדיפויות.
שני מאגרי לקוחות, שער אחד, והתוכנית נראית טריוויאלית: כלל אחד מוציא את המאגר הראשון בקישור העולה המהיר, כלל אחר מוציא את המאגר השני דרך מנהרת שותף. ואז הכללים במקום והמאגר השני עדיין יוצא בנתיב ברירת המחדל. הכלל לא שבור. מקור החבילה אינו מה שהמחבר ציפה לו ברגע החיפוש, משום שהתרגום והחיפוש מתרחשים בנקודות שונות במסע של אותה חבילה, והסדר הפוך מהתרשים המנטלי שרוב האנשים מציירים.
החיפוש מתרחש לפני שהמקור נכתב מחדש
עבור חבילה המועברת מלקוח VPN, הגרעין מבצע רצף קבוע. היא מגיעה בממשק המנהרה, עוברת ב-prerouting שבו חיים conntrack ו-DNAT, אחר כך מתקבלת החלטת הניתוב, אחר כך ההעברה, אחר כך postrouting שבו SNAT מוחל אחרון. כלל מהצורה from נבדק במהלך אותה החלטת ניתוב, כלומר הוא רואה את כתובת המקור של הלקוח, לא את המתורגמת.
לכן הוספת כלל masquerade אינה משנה איזו מדיניות מתאימה לזרם היוצא. מה שהיא משנה הוא מה רואה הצד הרחוק, ולכן איזה נתיב חזור קיים. אלו שתי תוצאות שונות, וסקירות שינויים מבלבלות ביניהן כל הזמן. הפרידו ביניהן והתכנון בדרך כלל מתבהר בתוך דקה.
בכיוון התשובה הכתובת המתורגמת מופיעה בכללים. חבילה החוזרת לשער ממוענת לכתובת המתורגמת, ואם יש לכם כללי מדיניות המבוססים על היעד או על הממשק שממנו הגיעה, זה הערך שתתאימו. אותו חיבור, מקור אמת אחר בכל כיוון.
| Stage | Source the kernel sees | What it means for your rule |
|---|---|---|
| Prerouting | Client address, 172.31.7.42 | Where marks and DNAT are applied |
| Routing decision | Still 172.31.7.42 | This is where from rules match |
| Postrouting | Becomes 198.51.100.9 | What the far end and its return route see |
לכן שני מאגרים עם מקורות שונים אכן זקוקים לטבלאות שונות, והתכנון תקין. מה שהטבלה למעלה שוללת הוא קיצור הדרך לאיתור תקלות בכך שמסתכלים על מה שקיבל האתר המרוחק ומסיקים ממנו את הכלל.
בדיקה מהשער אינה בדיקה של המאגר
תעבורה שהשער עצמו מייצר לעולם אינה עוברת ב-prerouting, משום שהיא לא הגיעה דרך ממשק. היא מנותבת בנתיב ה-output, כשכתובת השער עצמו היא המקור, וכלל from המבוסס על טווח לקוחות לא יתאים. כל קריאה בתחום הזה שאומרת שזה עובד מהמכונה אבל לא מהלקוח היא רק אותה עובדה מנוסחת אחרת.
דמו את הלקוח במקום לקרב אותו. ניתן לשאול את חיפוש הניתוב ישירות, עם מקור וממשק כניסה:
ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201הריצו אותו פעם אחת לכל מאגר. אם שתי הפקודות מחזירות את אותו ממשק, הכללים אינם מפרידים בין המאגרים, והסיבה היא או כלל חסר או כלל בעדיפות גבוהה יותר שמתאים לשניהם. אם הן מחזירות ממשקים שונים אך הלקוח עדיין נכשל, התקלה נמצאת אחרי החיפוש ואפשר להפסיק להסתכל על כללים.
עדיפות, לא מיקום בקובץ
כללים נבחנים בסדר עדיפות עולה, והמספר הוא שקובע, לא הסדר שבו הקלדתם אותם. טבלת local נמצאת בעדיפות 0, טבלת main ב-32766 וכלל ברירת המחדל ב-32767, ולכן כלל שנוסף בעדיפות ברירת המחדל נוחת קרוב לסוף הרשימה ומפסיד כמעט להכול.
ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201עדיפות מפורשת הופכת את הסדר המבוקש לגלוי בקובץ ובסקירה. היא גם מונעת מתוספת מאוחרת לדלג בשקט לפני כלל קיים, וזו הסיבה הנפוצה ביותר לכך שמדיניות עובדת מפסיקה לעבוד אחרי שינוי לא קשור.
כלל מתאים שמצביע על טבלה חלקית הוא המלכודת האחרת. אם טבלה 201 מכילה נתיב ברירת מחדל אך אין בה נתיב ליעד, החבילה נזרקת או נשלחת למקום הלא נכון, והכלל נראה נכון לחלוטין בבידוד. קראו את הטבלה, לא רק את הכלל. כלל הוא מצביע, וטבלה ריקה היא מצביע לשום מקום.
נתיב החזור עדיין חייב להתקיים
מדיניות מקור בוחרת יציאה. היא אינה יוצרת נתיב חזור. אם המאגר השני יוצא דרך מנהרת שותף, השותף חייב לדעת איך להגיע אל 172.31.8.0/24, או בנתיב חזרה אל השער או בקבלת כתובות מתורגמות שהוא כבר מכיר.
הבחירה בין השניים היא החלטת תכנון עם השלכות גלויות. ניתוב טווח הלקוחות חזרה משמר את הזהות של כל לקוח אצל השותף ומחייב אותו לקבל את הקידומת שלכם. התרגום מסתיר את המאגר מאחורי כתובת אחת ומחייב את השותף לקבל רק את הכתובת הזו, במחיר שללוגים שלכם ושלו כבר לא מסכימים מי התחבר.
מה שתבחרו, כתבו את זה לצד הגדרת המאגר. נתיב חזור שקיים רק בזיכרון של מישהו הוא בדיוק סוג הדבר ששורד עד שהשותף משנה חומת אש, ואז לוקח יום לשחזר.
אל תתפסו את המנהרה של השער עצמו במדיניות
הכללים שאתם כותבים ללקוחות חלים גם על תעבורה שהשער מייצר, אלא אם תחריגו אותה. כלל רחב המבוסס על סימון או על ממשק היציאה יכול לתפוס את החיבור של השער עצמו לשותף, ואז המנהרה שנושאת את המדיניות מנותבת על ידי המדיניות. זה יוצר לולאה או הפסקה שנראית כמו תקלת ספק.
הגבילו כל כלל בצורה צרה ככל שהתכנון מאפשר: קידומת מקור, ממשק כניסה והיכן שנתמך סימון שרק חבילות לקוח נושאות. אחר כך בדקו את הקישוריות של השער עצמו אחרי כל שינוי כלל, משום שהתקלה היא בהתייחסות עצמית ואינה מופיעה בבדיקה מהלקוח.
עמוד המדריך של ip-rule מתעד את הסמנטיקה של הבורר והעדיפות. שלבו אותו עם בדיקת חיפוש לכל מאגר והתכנון נעשה ניתן לבדיקה, וזה ההבדל בין ניתוב מדיניות שמחזיק שנה לבין כזה שכולם חוששים לגעת בו.