גילוי MTU של הנתיב דרך VPN: קביעת גודל והפער ב-ICMP
מנהרה מקטינה את החבילה שהנתיב יכול לשאת, והגילוי עובד רק אם המשוב חוזר. מדדו, בדקו ואמתו את הנתיב במקום לנחש.
מנהרה מסיימת את לחיצת היד שלה, בקשות קטנות חוזרות, וההעברה הגדולה הראשונה נתקעת. התבנית הזו מצביעה על MTU של הנתיב הרבה לפני שהיא מצביעה על תפוקה. כל חוליה לאורך המסלול מגבילה את גודל החבילה, והכימוס מוציא חלק מהקצבה הזו על כותרות חיצוניות, ולכן החבילה הפנימית חייבת להיות קטנה ממה שהנתיב הגולמי ירמוז. הכשל שקט, וזה מה שהופך אותו ליקר לאבחון.
מה באמת מודד MTU של הנתיב
MTU של הנתיב הוא ה-MTU הקטן ביותר של חוליה במסלול בין שני מארחים, לא ה-MTU שמודפס בממשק המקומי שלכם. הערך המקומי הוא נקודת ההתחלה של האומדן, והנתיב קובע היכן הוא חייב להסתיים. זו הסיבה שאותה מנהרה יכולה לעבוד ברשת גישה אחת ולהיתקע באחרת: המסלול השתנה, לא התצורה. מדידה חד-פעמית והנחה גורפת הן הטעות שמשאירה את הבעיה הזו בחיים.
במנהרה, המספר החשוב הוא ה-MTU הפנימי, שהוא הקצבה של הנתיב החיצוני פחות מה שהכימוס צורך. WireGuard מוסיף כותרת IP חיצונית וכותרת UDP; תעבורות אחרות מוסיפות משלהן. קבעו גודל פנימי גבוה מדי וכל חבילה בגודל מלא תזדקק לפיצול שאולי לעולם לא יקרה.
למה מנהרה מקטינה את החבילה השמישה
אם ממשק המנהרה שומר על ה-MTU של החוליה הפיזית, כל חבילה גדולה תלויה במישהו בהמשך המסלול שיסכים לפצל אותה. IPv4 מאפשר זאת בעקרון, אבל נתב שנאמר לו לא לפצל מחזיר שגיאה במקום. נתבי IPv6 לעולם אינם מפצלים בתעבורה, ולכן אותה הגדרה מתנהגת אחרת לפי משפחת הכתובות. כך או כך, השולח לא לומד דבר עד שמשהו מדווח בחזרה.
התוצאה המעשית היא גודל שמתאים ללחיצת היד ולא למטען. TLS ClientHello או שאילתת DNS קטנים מספיק כדי לחצות נתיב מצומצם בלי פגע, בעוד העברה בכמות גדולה אינה כזו. לכן התסמינים מתקבצים סביב פעולות מסוימות ולא סביב מארחים מסוימים.
הגילוי עובד רק כשהמשוב מגיע
גילוי IPv4 נשען על ביט don't-fragment: נתב שאינו יכול להעביר את החבילה מחזיר ICMP fragmentation-needed עם ה-MTU של הקפיצה הבאה, והשולח מוריד את האומדן שלו. IPv6 משתמש בהודעות Packet Too Big במקום, כי נתבים אינם מפצלים בתעבורה. שתי המנגנונים מניחים שההודעה תמצא את דרכה חזרה לשולח, דרך המנהרה ומעבר לכל חומת אש במסלול החזרה. כשההנחה הזו נכשלת, השולח ממשיך לנסות שוב ושוב גודל שהנתיב אינו יכול לשאת.
חומת אש שמתירה echo request ו-echo reply לא בהכרח התירה את סוגי השגיאה האלה. ICMP הוא משפחה, והדברים החשובים כאן הם השגיאות, ולא זוג ההד. בדקו את מדיניות תעבורת הבקרה בשני קצוות המנהרה ובמסלול שביניהם, ופעלו לפי ההנחיות הנתמכות של הפלטפורמה במקום להתיר כל סוג ICMP בכל מקום.
אותו סינון יכול לשבת בתוך המנהרה. אם הנתיב הפנימי מפיל את השגיאה אבל הנתיב החיצוני נושא אותה, השולח עשוי להתאים את עצמו למגבלה שהתעבורה העטופה אף פעם לא באמת רואה.
בדקו את הנתיב במקום לנחש מספר
השאירו את היעד, רשת הגישה והמנהרה קבועים, ושנו רק את גודל החבילה. בדיקת don't-fragment שנכשלת עם רמז MTU נותנת לכם את מגבלת הקפיצה הבאה; חזרו על הבדיקה עד שגודל עובר, ורשמו גם את הגודל וגם את משפחת הכתובות.
ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10פינג שמתאים אינו מוכיח שהסגמנטים בגודל מלא של יישום אמיתי מתאימים, ולכן חזרו על הבדיקה עם ההעברה שנכשלה באמת. השוו את הבדיקה הגדולה ביותר שעבדה ל-MTU של המנהרה שהגדרתם, והשאירו את שני המספרים בנפרד בהערות שלכם. אם הם נבדלים בבערך כותרת אחת, מצאתם את תקורת הכימוס ולא תקלה.
PLPMTUD, המתואר ב-RFC 4821, בודק כלפי מעלה ומשתמש באישורי תעבורה במקום לסמוך על שגיאות שנמסרו. הוא עוזר בנתיבים שמסננים ICMP, אבל התמיכה משתנה לפי מחסנית ולפי יישום. זרימת TCP עשויה להתאושש מעצמה בעוד יישום UDP עם גודל דאטגרם קבוע ממשיך להיכשל.
בחרו ערך ותעדו את הנימוק
הורדת ה-MTU של המנהרה היא גם אבחון וגם תיקון לגיטימי ברגע שאתם מכירים את הנתיב. היא אינה תחליף לידיעה איזה נתיב ואיזה מנגנון משוב היו מעורבים, כי ערך שמכוונן לקישור נייד יהיה קטן מדי שלא לצורך בחיבור סיבים. תעדו את הגודל שנבחר, את הבדיקה שהצדיקה אותו ואת שלב הנסיגה.
מנגנון IPv4 מתואר ב-RFC 1191 והנחיית הפקטות של IPv6 ב-RFC 8201; אזכור שניהם מונע מהמהנדס הבא לגזור מחדש את ההנחה. אם ההעברה עדיין נתקעת בגודל שבחרתם, הפסיקו להוריד את המספר והסתכלו בשכבה הבאה. נתיב שנכשל בכל גודל אינו בעיית MTU.