מנות פנימיות וחיצוניות בלכידת VPN: מדוע הגדלים שונים

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

שתי נקודות מבט והמנה שכל אחת מציגה

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

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

החליטו על השכבה לפני שמתחילים בלכידה

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

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

מה באמת מכיל הפרש הגודל

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

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

קריאת offload אל תוך המספרים

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

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

היכן הלכידה מפסיקה להיות ראיה

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

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

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