MTU לכל נתיב ב-Linux: שלושה בקרי גודל, נתיב אחד
MTU של הממשק, MTU של הנתיב ומגבלת MSS פועלים בשכבות שונות. הצמידו תקציב לנתיב שמנצח בחיפוש, והשאירו את השינוי הפיך.
שלושה הגדרות בלקוח Linux נשמעות כולן כמו «הפוך את החבילות לקטנות יותר», והן פועלות בשכבות שונות. ה-MTU של הממשק מגביל כל חבילה שההתקן שולח. MTU של נתיב מגביל חבילות שמשתמשות באותו נתיב, וזה לעתים קרובות מה שאתם באמת רוצים ליעד VPN אחד. מגבלת TCP MSS משנה את מה ששני הקצוות מנהלים משא ומתן עליו, והיא לא עושה דבר ל-UDP.
שלושה בקרים שנראים כמו אותו כפתור
הניחו אותם זה לצד זה לפני הבחירה, כי בחירת השורה הלא נכונה מסבירה את רוב העצות שלא עובדות:
| Control | Scope | What it cannot fix |
|---|---|---|
| Interface MTU | Every packet the device sends | Nothing, but it over-constrains unrelated traffic |
| Route MTU | Packets using that route | A send that the lookup never routes there |
| MSS clamp | TCP handshake on that path | UDP payload sizes and ICMP |
הורדת MTU של Ethernet עבור כל המכונה היא הגרסה הגסה של התיקון הזה. זה עובד, וזה גם מעניש כל יישום אחר במארח, כולל אלה שהנתיבים שלהם היו תקינים. ערך לכל נתיב מבטא את אותה כוונה בלי העלות הנלווית.
ההשוואה תקפה רק לתעבורה שהמארח עצמו מייצר. העברת חבילה עבור לקוח אחר כוללת את הנתיב שלו עצמו ואת התקציב החיצוני של המנהרה, ומדד נתיב במארח הזה לא מגיע מעבר לגבול הזה.
הצמידו את התקציב לנתיב שמנצח בחיפוש
רשומת נתיב IPv4 להמחשה נראית כך:
ip -4 route get 10.60.0.20
ip -4 route add 10.60.0.0/16 dev tun-office src 10.90.0.2 mtu 1380קראו את הרשומה כתיאור כוונה, לא כערך להדבקה. הקידומת, ההתקן והמקור המועדף חייבים להתאים לתצורה האמיתית, ו המספר חייב לבוא מראיות על הנתיב העטוף, לא מפוסט בבלוג. ה-MTU של הנתיב מגביל את חבילת ה-IP הפנימית, וזה לא אותו דבר כמו מטען TCP של 1380 בייט או חבילה חיצונית מוצפנת של 1380 בייט.
בדקו היכן החיפוש באמת נפתר לפני שמוסיפים משהו. מארח עם כללי מדיניות יכול לנתב יעד נתון דרך טבלה שאינה main, ומדד שקיים רק ב- main אינו נראה לבקשה הזאת. השוו ip -4 route show table all עם התשובה מ- ip route get, כולל הקשר הסימון או מרחב השמות כשהכללים משתמשים בהם. אם השניים לא מסכימים, הטבלה שענתה היא זו שזקוקה למדד, לא זו שנראית מסודרת יותר.
mtu אינו mtu lock
כברירת מחדל הגרעין עדיין יכול לעדכן את MTU הנתיב ממשוב ICMP, ולשם כך קיימת גילוי MTU נתיב. הוספת lock עוצרת זאת. זו החלטה אחרת, לא דרך חזקה יותר לשמור את אותו מספר, וב-IPv4 היא משנה את הטיפול המתועד בסיבית «אל תפצל».
נעילה סבירה כשמדדתם את הנתיב ורוצים שהערך יישאר במקום בלי קשר למה שמגיע. זו ברירת מחדל גרועה כשהרשת שולחת משוב גודל לגיטימי, כי הגרעין לא יכול עוד להתאים והכשל עובר לסימפטום אחר.
אם ICMP מסונן במקום כלשהו לאורך הנתיב, שום הגדרת נתיב לא מתקנת את זה. התיקון שייך למסנן, ו-MTU קטן יותר הוא עקיפה שמסתירה את התקלה האמיתית עד השינוי הבא בנתיב.
תוכנת מנהרה מוסיפה בקרי גודל משלה
OpenVPN- mssfix מתאים את גודל מקטע ה-TCP למקרה מנהרת ה-UDP המתועד שלו. הוא פועל על שיחת ה-TCP, ולכן אינו איות אחר של MTU הנתיב של מערכת ההפעלה, והוא לא יכול לעזור לשירות UDP שמתעלם ממשא ומתן.
אל תערמו MTU נתיב, שינוי MTU ממשק ומגבלת MSS בחלון שינוי אחד. אם הבעיה תיעלם לא תדעו מה היה חשוב, ואלה שתשאירו יגבילו תעבורה שנים בלי סיבה שמישהו זוכר.
הפכו אותו להפיך, ואז הוכיחו
הבעלים האמיתי של הנתיב מחליט אם השינוי שורד התחברות מחדש. לקוח VPN שמתקין את הנתיב באופן דינמי יבנה אותו מחדש בדרך כלל בלי המדד שלכם, ופקודת ip route add ידנית תיראה אז כמו תיקון שנכשל יום לאחר מכן. שימו את הערך בתצורת המנהל, ואם אתם צריכים ניסוי זמני, תעדו קודם את הנתיב המקורי.
בדקו בחיבור חדש שמבצע את הפעולה שנתקעה, ואז אשרו שהנתיב הפרטי המיועד עדיין מנצח ויעדים לא קשורים לא השתנו. חברו מחדש את המנהרה וקראו את הנתיב שוב, כי ערך שנעלם בהתחברות מחדש אינו תיקון.
אם הראיות לא תומכות בשינוי, הסירו את העקיפה דרך המנהל שלה והחזירו את מאפייני הנתיב המקוריים במקום למחוק את הנתיב. אחר כך רשמו מה מדדתם ובאיזה נתיב, כדי שהאדם הבא יבחין בין שיפור אמיתי לניסוי שהושאר פועל.