לקוח VPN על שרת LAN: מדוע התשובות יוצאות בדרך הלא נכונה

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

תשובה היא מקטע חדש, לא היפוך

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

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

שמרו שני תתי-רשתות בראש בזמן קריאת השאר. האחת היא מאגר כתובות ה-VPN שממנו מגיעים הלקוחות המרוחקים, בדוגמה זו 10.64.0.0/24. השנייה היא ה-LAN שחייב להמשיך לעבוד, 172.16.24.0/24 עם הנתב שלו ב-172.16.24.1. הבאג הוא שהתעבורה ביניהם נקבעת על ידי נתיב ברירת המחדל.

הוכיחו זאת באמצעות הלכידה והחיפוש

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

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

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

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

התקינו את הנתיב הצר ביותר שמנצח את המנהרה

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

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

השתמשו ב-replace ולא ב-add, כי לקוח שמתחבר מחדש כבר התקין רשומה משלו, ו-add נוסף נכשל בשגיאת נתיב קיים שנקראת כמו בעיית הרשאות. במארח Windows המקבילה היא route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, שבה -p שומר על הרשומה בין אתחולים, שכן הלקוח עשוי לבנות מחדש את הטבלה כשהמנהרה חוזרת. במארח Windows מודרני המקבילה הנתמכת היא New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, כשהפקודה הוותיקה route נשמרת כצורה מדור קודם.

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

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

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

חומת אש עם מצב עדיין יכולה להביס נתיב נכון. אם הלכידה מראה כעת שהתשובה יוצאת דרך eth0 והלקוח עדיין מקבל פסק זמן, בדקו אם המארח זורק את המקטע לפני השליחה. סינון קפדני של הנתיב ההפוך ו-net.ipv4.conf.all.rp_filter שמוגדר ל-1 זורקים מקטעים שהמקור שלהם לא היה מנותב חזרה דרך הממשק שבו הגיעו, וזה בדיוק המקרה האסימטרי שיצרתם זה עתה ותיקנתם, ומצב conntrack מספר את אותו סיפור על יציאות שהועברו הלאה.

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