התשובה יוצאת דרך ה-LAN, לא דרך המנהרה: למה ואיך

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

מה באמת קובע חבילה יוצאת

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

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

למה רשת המשנה המקומית מנצחת

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

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

כיסוי העמיתים אינו זהה לנתיבים מותקנים

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

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

בחר את הטבלה לפי כתובת המקור

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

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

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

אשר את הנתיב, ואז את השירות

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

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

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

מה זה לא מתקן

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

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

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