מיתוסים של MTU ב-VPN: למה החבילות שלכם מתכווצות ולאן נעלם המקום

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

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

מיתוס ראשון: ה-MTU של המנהרה הוא ה-MTU של הנתיב

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

גילוי MTU של הנתיב קיים כדי ליישב בין השניים, והוא תלוי במשוב. ב-IPv4, נתב שאינו יכול להעביר חבילה בגודל מלא אמור לשלוח הודעת ICMP "fragmentation needed", והשולח מוריד את ההערכה שלו. ב-IPv6, המקבילה היא הודעת Packet Too Big, ונתבים כלל אינם מפצלים בדרך. כשהמשוב הזה מסונן, השולח ממשיך לייצר חבילות שהנתיב אינו יכול לשאת, ושום דבר לא אומר לו למה.

מיתוס שני: המעטפת עולה כותרת אחת

ספרו את השכבות החיצוניות ביושר. כותרת IP חיצונית היא 20 בייט ב-IPv4 או 40 ב-IPv6. מעטפת UDP למעבר NAT מוסיפה 8. פרוטוקול המנהרה מוסיף כותרת משלו, וקטור אתחול או nonce, ריפוד עד גבול הבלוק או היישור של הצופן, קטע סיום וערך בדיקת שלמות. בהתאם לפרוטוקול ולצופן, הסכום עומד בנוחות בעשרות בייטים לפני שהחבילה הפנימית בכלל מתחילה.

אחר כך הפחיתו שוב את הכותרות של החבילה הפנימית עצמה. מקטע TCP בתוך המנהרה נושא כותרת IP משלו של 20 בייט וכותרת TCP של 20 בייט, וה-MSS של TCP נגזר מה-MTU, לא מהמטען הנומינלי של המנהרה. לכן ping עם מטען קטן יותר יכול להצליח בזמן שהעברת קובץ נתקעת: הכלים בודקים דברים שונים, ורק אחד מהם מפעיל מקטע TCP בגודל מלא.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

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

מיתוס שלישי: PPPoE עדיין נותן לכם 1500 נקי

קישור גישה PPPoE קונבנציונלי אינו נושא חבילת IP של 1500 בייט. כותרת PPPoE יחד עם שדה פרוטוקול PPP תופסים 8 בייטים בתוך מסגרת Ethernet, מה שמשאיר 1492 לחבילת ה-IP. זהו הגבול המסורתי המתואר ב-RFC 2516. אם אתם מריצים VPN על קישור כזה, התקורה של המנהרה באה מאותם 1492, לא מ-1500.

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

למה התקלה נראית סלקטיבית

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

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

מה לשנות, ובאיזה סדר

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

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