טבלת ניתוב מול חיפוש בפועל: לאן הולך תנועת VPN

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

טבלה היא קבוצת מועמדים, לא החלטה

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

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

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

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

החיפוש עובר קודם כללים, ואז טבלאות

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

ip rule show
ip route show table all | head -40
ip route show table 100

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

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

מה לקוח ה-VPN מתקין

לקוחות בדרך כלל לא מחליפים את ברירת המחדל של המסלול, משום שזה ישבור את המסלול החיצוני של המנהרה עצמה. הם מתקינים משהו ספציפי יותר שמנצח לפי אורך הקידומת: זוג חצאי-ברירת-מחדל שמכסים 0.0.0.0/1 ו-128.0.0.0/1 הוא התחבולה הקלאסית, שכן שניהם קידומות ארוכות יותר מ-0.0.0.0/0 ויחד הם מכסים את כל המרחב. אחרים מתקינים קידומות פרטיות ספציפיות בתוספת כלל מדיניות, וחלק מוסיפים סימן כך שרק תעבורה נבחרת נלכדת.

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

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

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

המסלול החיצוני חייב גם הוא לשרוד

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

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

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

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

מה פלט הניתוב לא יכול לספר לכם

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

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

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