בדיקת בעיית MTU חשודה ב-VPN בלי לנחש ערכים
קבעו את הנתיב, רשמו את הערכים המקוריים, ואז שנו פרמטר גודל אחד והשוו. בדיקה שנכשלה יכולה להיות סינון ICMP ולא מגבלת MTU.
לנסות רשימה של ערכי MTU של האינטרנט עד שאחד מרגיש מהיר יותר אינו מבחן, זו חיפוש בלי כלל עצירה. השיטה שעובדת משנה תנאי גודל מבוקר אחד ומשווה את התוצאה לאותו נתיב. התחילו מכשל חוזר ובלתי מזיק ושמרו את התצורה העובדת שמאפשרת לבטל את הניסוי. כל מה שלהלן מניח את המשמעת הזו, כי בלעדיה נשארים עם מספר שאי אפשר להגן עליו.
קבעו את הנתיב לפני שתשנו מספר
רשמו את ההתקן, קו הגישה, פרוטוקול המנהרה, נקודת הקצה, היעד ומשפחת הכתובות לפני שאתם נוגעים בהגדרה. שש העובדות האלה הן הנתיב, ובדיקה שמכוונת לנתיב אחר מודדת בעיה אחרת. הן גם הופכות את התוצאה לחזרתית, וזה מה שמבדיל מבחן מבילוי אחר הצהריים בלישון. החזיקו את ההערה לצד המסוף ולא בראש.
התחילו במבחן הצר ביותר שמותר לכם להריץ. שינוי בצד השרת מגיע לכל משתמש של נקודת הקצה ההיא, ולכן הוא שייך לסוף החקירה ולא להתחלה.
בדקו בגודל שאתם שולטים בו
ב-Linux הבדיקה נראית כך: ping -M do -s 1400 host, וב-Windows כך: ping -f -l 1400 host. בשני המקרים אתם מגדירים את המטען ולא את גודל החבילה, כי כותרות IP ו-ICMP מתווספות מעל.
קראו את התיעוד של המערכת שלפניכם במקום להעתיק דגל מהודעה בפורום. בחרו יעד שאתם שולטים בו, כך שתגובה חסרה תהיה אות ולא תעלומה. רשמו את הפקודה המדויקת ואת הגודל המדויק באותה הערה כמו הנתיב. תוצאה בלי גודל היא אנקדוטה. אם תשנו שני דברים בהרצה אחת, לא תדעו איזה מהם הניב את התוצאה.
בדיקה שנכשלה אינה הוכחה למגבלת MTU
בדיקה שנפלה יכולה להיות סינון ICMP ולא מגבלת גודל, והטעות הזו מכניסה אנשים לכוונון ערך שמעולם לא היה הבעיה. השוו את הבדיקה ליישום האמיתי, ולהודעת שגיאה שקשורה לגודל או ללכידה מוגבלת, לפני שתשנו משהו. גם פינגים קטנים מוצלחים לא מוכיחים דבר, כי הם יכולים לשבת בנוחות מתחת למגבלה. שתי תצפיות בלתי תלויות הן המינימום לפני שתצורה זזה.
אם היישום נכשל בעוד הבדיקה מצליחה, יש לכם ראיה שזו אינה מגבלת גודל פשוטה בנתיב הזה. רשמו זאת, כי זה מסיר ענף שלם של שינויים אפשריים.
כווננו פרמטר אחד שהלקוח כבר תומך בו
שנו את ההגדרה שהלקוח מתעד עבור הפרוטוקול הזה והשאירו את נקודת הקצה ואת היעד ללא שינוי, אחרת שיניתם שני דברים בבת אחת. הגבלת MSS של TCP אינה מכסה כל עומס UDP, ולכן דפדפן שמתחיל לעבוד יכול להשאיר את פרוטוקול המנהרה בדיוק באותה שבירה. IPv4 ו-IPv6 הם כאן נתיבים נפרדים, כי הכותרות שונות עוד לפני שניתוב כלשהו עושה משהו.
בדקו את שתי המשפחות אם אתם מפרסמים את שתיהן, כי תוצאה מאחת לא אומרת דבר על השנייה. ערך שעבד בנתיב הזה הלילה הוא נתון ולא MTU לכל ה-VPN. אל תקדמו אותו להגדרה גלובלית על סמך העברה מוצלחת אחת. רשמו את הערך לצד הנתיב שממנו הגיע.
לבטל, לאמת ולתעד
החזירו את הערך המקורי אם ההשוואה אינה תומכת בהשערה. בדקו שמנהל רשת לא שמר במקום אחר עקיפה מתמשכת, כי כך ניסוי הופך למדיניות. התחברו מחדש ונסו יישומים רגילים, לא רק את זה שבדקתם. אחר כך תעדו את התסמין, את הנתיב האפקטיבי, את הערך הישן והחדש ואת מידת החזרתיות של התוצאה.
שמרו את התיעוד הזה עם בקשת השינוי לפני שמישהו מרחיב את השינוי. מנגנון גילוי MTU של הנתיב ב-RFC 1191 מסביר למה ערך קטן יותר יכול להציל נתיב אחד ולא לעשות דבר לאחר, ורשימת מספרים אינה מחליפה את המודל הזה. הבדיקה מסתיימת כשאתם יכולים לנקוב בשם הנתיב, הגודל, התצפית והערך שהחזרתם.