למה VPN שעובד עדיין מגיע לפסק זמן בתשובה
הגעת בקשה לשרת פרטי היא רק מחצית החליפין. התשובה שלה חייבת למצוא את לקוח המנהרה דרך השער, הנתיב או התרגום המיועדים.
הבקשה מגיעה, השרת רושם אותה ביומן, והלקוח עדיין מדווח על פסק זמן. השילוב הזה אומר ש התשובה לא מצאה את דרכה חזרה, וזה אחד הכשלים הבודדים שאפשר לאמת משני הקצוות בעת ובעונה אחת. עברו על הבדיקות לפי הסדר ועצרו כשאחת מהן נכשלת.
התחילו מהמקום שאליו הגיעה הבקשה
אמתו שהמנות הגיעה לשירות לפני שתבדקו כל דבר אחר. רשומה ביומן בצד השרת, מונה חיבורים או לכידה מורשית בקצה המרוחק עונים כולם על אותה שאלה, והיעדרם מחזיר אתכם למנהרה במקום קדימה לתשובה. זו הבדיקה שמפרידה בין בעיית העברה לבין בעיית נתיב חזרה.
אם הבקשה מעולם לא הגיעה, עצרו כאן. המנהרה, הניתוב אל התחילית הפרטית או כלל הגישה הם הנושא, ונתיב התשובה עדיין לא רלוונטי. רשמו גם את כתובת המקור שהשרת ראה. זו או כתובת המאגר שניתנה ללקוח או כתובת מתורגמת, וההבדל הזה קובע איזו מהבדיקות המאוחרות חלה.
התשובה צריכה נתיב אל המאגר
לקוח גישה מרחוק מקבל בדרך כלל כתובת ממאגר, והרשת הפרטית צריכה נתיב חזרה אל אותו מאגר. שרת שנתיב ברירת המחדל שלו מצביע אל השער של עצמו מוסר את המנות לאותו שער, שאין לו מושג היכן נמצא המאגר, ולכן התשובה מתה שם. הלקוח רואה פסק זמן מפני ששום דבר לא חזר, וזה אינו ניתן להבחנה מבקשה שלא יצאה מעולם.
בדקו את הנתיב שהשרת בוחר עבור כתובת הלקוח, ולא את הנתיב שבו הוא משתמש עבור תת־הרשת שלו. שתי החיפושים האלה יכולים להניב תשובות שונות, והשנייה היא זו שחשובה כאן. תרגום הוא התכנון החלופי והוא משנה את מה שהשרת רואה. הוא יכול לפשט נתיב חזרה, והוא גם מסיר את כתובת הלקוח המקורית מיומני השרת, מה שמשפיע על כל כלל או דוח שנבנה על השדה הזה.
השוו את הלכידה בשרת ללכידה בשער
השוו את מה שיוצא מהשרת למה שמגיע לשער. לכידה בממשק היציאה של השרת ולכידה בשער המנהרה עונות על חצאים שונים של השאלה, והפער ביניהן מאתר את האובדן.
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
בקשה שהשער עצמו מייצר היא תחליף גרוע לבדיקה מהלקוח, מפני שהיא נובעת מכתובת אחרת ופוגשת כללים אחרים. לכן ping מוצלח מהשער ובקשה כושלת מהלקוח יכולים להיות נכונים שניהם.
כאשר יושבים כמה מנתבים על הנתיב, בדקו כל אחד שזקוק לנתיב אל המאגר. תכנון אתר לאתר דורש לעיתים קרובות שהתחילית המרוחקת תהיה ידועה ביותר ממכשיר אחד, והשער עצמו חייב להעביר בין המנהרה לרשת המקומית; ההערות של strongSwan על העברה מכסות את הצד של sysctl וחומת האש בכך.
רשמו את המאגר, התחילית והאחראי
ארבע עובדות שייכות לרשומה: המאגר שהלקוח קיבל, התחילית הפרטית שהיה צריך, המנתב האחראי לתשובה, וכלל התרגום אם קיים. עם אלה, שינוי שער מאוחר הוא השוואה ולא חקירה.
אחר כך בדקו שוב עם לקוח רגיל ועם חשבון היישום האמיתי. הרחבת הרשאות היישום אינה יכולה לתקן את נתיב החזרה של מנות, ושינוי חשבון שנעשה במהלך האבחון הזה יבלבל את ההשוואה הבאה. אם התכנון נשען על תרגום, תעדו אותו במקום שבו קוראים את יומני השרת. מי שרואה כתובת מקור לא מוכרת בעקב ביקורת לא אמור לגלות מחדש את המיפוי מכרטיס.