מנות גדולות נעלמות מעל IPsec בעוד שפינגים קטנים ממשיכים לעבוד
בדיקות קטנות עונות והעתקות קבצים נתקעות, וזה הסימן של החלטת גודל שמתקבלת לפני ההצפנה. גלו איזה צד מפצל את המנה ולמה.
מעטפות מרוחקות ממשיכות להגיב, בדיקות קטנות עונות, ואז העתקת קובץ זוחלת ונתקעת בלי שום שגיאה שאפשר להצביע עליה. פינג עם מטען גדול יותר משחזר את זה מיד, ואותה העברה עובדת מהרשת המקומית. שום דבר בהצפנה אינו איטי; מנות מסוימות פשוט לא מגיעות. שני פיצולים שונים יכולים לייצר את הסימן הזה, והם משאירים ראיות שונות.
שני מקומות שבהם אפשר לפצל מנה
לפני ההצפנה, הנתב יכול לפצל מנה פנימית גדולה מדי ולהגן על כל חלק בנפרד. אחרי ההצפנה, מה שמתפצל הוא המנה החיצונית המוגמרת, והצד המרוחק צריך להרכיב אותה מחדש לפני שהוא מפענח משהו. אותו סימפטום, עבודה אחרת למקבל וכפתורים אחרים בשבילכם.
ההבחנה חשובה כי תיקון שמכוון לצד הלא נכון משנה מספר בלי להזיז את התקלה. מנה שנדחית בממשק לעולם לא הופכת למנה חיצונית, ולכן שום הגדרה בצד החיצוני לא יכולה להציל אותה.
איפה החלטת הגודל באמת מתקבלת
ממשק מנהרה נושא IP MTU, והערך הזה יכול לדחות מנה פנימית גדולה מדי הרבה לפני ששלב IPsec רואה אותה. הצבת סיבית בכותרת החיצונית לא בוחנת מחדש את ההחלטה הקודמת, כי המנה כבר נדחתה. לכן העלאת ה-MTU הפנימית לפעמים מחמירה את המצב במקום לשפר אותו. קראו את ערך הממשק ואת ההתנהגות החיצונית לפני שתשנו מי מהם, כי העריכה הזולה יותר היא בדרך כלל זו שמסבירה את הסימפטום.
בדקו קודם את ערך הממשק, אחר כך את ההתנהגות החיצונית. שני מספרים, שני שלבים, ובדרך כלל רק אחד מהם אחראי.
התקציב החיצוני אינו התקציב הפנימי
כל עטיפה מוציאה בתים על כותרות, והכמות תלויה בתחבורה, במשפחת הכתובות ובשאלה אם מעבר NAT נמצא במשחק. מנה פנימית שמתאימה לקישור המקומי עדיין יכולה לייצר מנה חיצונית שלא מתאימה לנתיב שמעבר לו. מדדו את התוספת במקום להניח אותה, כי כל כותרת אופציונלית מתווספת לחשבון. מנהרה עם מעבר NAT משלמת יותר מאחת עירומה, וההפרט מספיק כדי לשבור העברה שעבדה אתמול.
כשהמנה החיצונית נושאת את סיבית אי-הפיצול, קפיצה שלא יכולה להעביר אותה מפילה אותה ואמורה להחזיר הודעת ICMP. אם ההודעה הזו מסוננת במקום כלשהו, השולח ממשיך לנסות והמשתמש רואה עצירה בלי הסבר. ההפלה השקטה הזו היא הסיבה הרגילה לכך שבעיית גודל מדווחת כבעיית מהירות.
IPv6 מסיר אחת מהאפשרויות
נתבי IPv6 אינם מפצלים בתעבורה, ולכן המנה החיצונית או מתאימה או נעלמת עם הודעת Packet Too Big. ההודעה הזו הופכת לערוץ המשוב היחיד, וחסימתה שוברת את גילוי הנתיב לכל העברה גדולה שתבוא אחריה. נתבי IPv4 עשויים לפצל מנה גדולה כשהסיבית נקייה, מה שמסתיר את התקלה עד שמשהו אחר מגדיר את הסיבית.
במערכת מעורבת, אותה מנהרה יכולה להתנהג אחרת לשתי המשפחות, ולכן בדיקה אחת מעל IPv4 לא מכריעה תלונה על IPv6. בדיקה שמפעילה משפחה אחת משאירה חצי מהתשובה בלי מדידה.
מדיניות מקטעי TCP אינה תשובה כללית
הגבלת גודל המקטע המרבי עוזרת לזרימות TCP, והיא בקרה לגיטימית כשהבעיה מוגבלת אליהן. אין לה שום השפעה על UDP, שנושא DNS, כמה פרוטוקולי קול וחלק גדל מהתעבורה ברשת.
החילו אותה, ואז בדקו את עומס העבודה שנכשל. אם מקרה UDP עדיין נכשל, מדיניות המקטעים מעולם לא הייתה התשובה ותקציב הממשק עדיין זקוק לתשומת לב. זהו קודם את הפרוטוקול של העומס שנכשל, ואז בחרו את הבקרה שמתאימה לו.
סדר העבודה
רשמו את המטען הגדול ביותר ששורד, אחר כך את MTU הממשק, אחר כך אם המנה החיצונית נושאת את סיבית אי-הפיצול, ולבסוף אם משוב ICMP מגיע לשולח. הרצף הזה מצמצם את התקלה בלי לנחש. שמרו כל תצפית עם חותמת זמן ונקודת קצה, כי כל ארבעת המספרים זזים כשהנתיב משתנה.
שנו ערך אחד, בדקו שוב את ההעברה המקורית ושמרו את התוצאה. מנהרה שעוברת בדיקה גדולה אך עדיין נתקעת ביישום עברה לבעיה אחרת, וזו התקדמות ששווה לרשום. האדם הבא יעדיף את המספרים על פני המסקנה.