מה ניתוב מדיניות משנה בתעבורת VPN, ומה לא

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

כללים בוחרים את הטבלה, ואז הטבלה בוחרת את הנתיב

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

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

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

קראו את מערך הכללים כרצף, לא כרשימה

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

ip rule show
ip route show table all | sed -n '1,60p'
ip route get 198.51.100.20 from 10.8.0.2
ip route get 198.51.100.20 from 10.8.0.2 mark 0x1

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

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

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

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

עקבו אחר הבעלות לפני שמוסיפים כלל נוסף

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

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

הוכיחו את ההיקף בשני זרמים, לא באחד

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

ip route get 198.51.100.20 from 192.0.2.44
ip route get 198.51.100.21 from 192.0.2.44
tcpdump -ni any host 198.51.100.21 and port 443

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

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