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

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

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

השער עונה מהמחסנית של עצמו

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

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

עקבו אחר התזרים עד לגבול הראשון שמפיל אותו

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

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

מסלולי החזרה וחומות האש של המארחים נכשלים בנפרד

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

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

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

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

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

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

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