למה traceroute מת בכיוון אחד דרך מנהרת VPN

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

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

כוכבית היא תשובה חסרה, לא קפיצה חסרה

traceroute מתקדם החוצה על ידי שליחת בדיקות שה-TTL שלהן פג בנתב אחד רחוק יותר בכל סבב. נתב שמשליך בדיקה שפג תוקפה אמור להחזיר הודעת ICMP Time Exceeded שמציינת את עצמו, והכלי מדפיס את השם הזה. מה שהכלי באמת ממתין לו הוא שההודעה הזו תגיע בתוך פרק זמן. אם הנתב עונה מכתובת מקור אחרת, מגביל את תדירות יצירת השגיאות או משליך את הבדיקה בלי מילה, הסבב לא מפיק דבר שניתן להדפיס.

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

שיטת הבדיקה קובעת באיזה מסנן תפגשו

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

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

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

נתיב החזרה הוא נתיב בפני עצמו

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

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

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

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

traceroute -I -n -w 2 203.0.113.40
traceroute -T -p 443 -n -w 2 203.0.113.40
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 5 http://203.0.113.40:8080/health
ss -tan state established

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

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