MTU או MSS? מה שינוי VPN באמת מתקן

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

שני מספרים, שני אובייקטים

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

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

לאן נופל הכובד החיצוני

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

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

כיווץ MSS, והיכן הוא חל

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

ההשפעה היא על TCP בלבד. אפליקציית UDP, הפעלת QUIC וכל פרוטוקול שבונה דאטגרמים משלו אינם מושפעים.

אבחנו בנתיב קבוע

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

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

מה כל שינוי לא מתקן

הורדת ה-MTU של הממשק אינה משנה את ה-MSS של הפעלה שכבר הוקמה. כיווץ MSS לא עוזר לזרימת UDP ולא מתקן נתיב שבו שגיאות ICMP מסוננות בכיוון אחד בלבד. כל שינוי מתקן סוג אחד של בעיה ומשאיר את השאר בדיוק כפי שהיו.

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