ה-VPN של הנתב עובד, אבל לקוחות ה-LAN בלי אינטרנט

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

קראו את הכשל ממארח LAN

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

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

תעבורה מקומית ותעבורה מועברת שונות

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

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

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

גם נתיב החזרה חייב להתקיים

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

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

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

אמתו זרימה אחת מותרת וזרימה אחת חסומה

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

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

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

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