האם נתיבי DHCP יכולים להוציא את התעבורה שלך מחוץ למנהרת ה-VPN?

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

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

שתי דרכים שבהן רשת יכולה להשפיע עליך

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

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

expected:  app -> tunnel device -> encapsulation -> internet
observed:  app -> wlan0        -> plaintext     -> internet

מאין יכול להגיע נתיב לפני שהמנהרה קיימת

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

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

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

בדוק את הדרך שהליבה באמת בוחרת

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

ip route get 203.0.113.10
ip route show table all | grep -E '^(default|203\.0\.113)'
ip rule show
resolvectl query example.com

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

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

החלט היכן האכיפה צריכה לחיות

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

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

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