OpenVPN על PPPoE: להוריד את link-mtu, tun-mtu או mssfix?

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

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

שלושה כפתורים, שלוש שכבות שונות

link-mtu הוא התקציב החיצוני: המטען המוצפן בתוספת כותרת OpenVPN, כותרת UDP וכותרת IP חיצונית. הוא מתאר מה יוצא מהמכונה, ולכן זה המספר שהמסלול הפיזי מגביל.

tun-mtu הוא התקציב הפנימי: הממשק שהתעבורה שלכם רואה. הוא גדול ממה שהמסלול יכול לשאת בדיוק בגודל התקורה של המנהרה, ו-OpenVPN בדרך כלל גוזר אותו במקום לחייב אתכם לקבוע אותו.

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

אם תקבעו את link-mtu במפורש, OpenVPN מחסיר את התקורה שלו כדי לגזור את ה-MTU הפנימי. התקורה הזו אינה קבועה; היא תלויה בצופן ובאימות, ולכן ערך שהועתק מפורום יכול להיות שגוי בפרופיל אחר. קביעה של גם link-mtu וגם tun-mtu נותנת ללקוח שתי הוראות סותרות.

מדדו את המסלול לפני שתבחרו מספר כלשהו

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

בלקוח Linux, ping -M do -s 1472 אוסר פיצול ונכשל אם המנה גדולה מדי. הקטינו את המטען עד שהוא עובר, ואז הוסיפו 28 כדי לקבל את ה-MTU של המסלול. PPPoE עולה 8 בייטים, ולכן 1492 הוא נורמלי ב-DSL. DS-Lite וכמה מסלולים סלולריים עולים 40 או יותר, והתשובה בדרך כלל נמוכה ממה שמהירות הקישור הנומינלית מרמזת.

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

הגבילו את TCP תחילה, כווצו את המנהרה אחר כך

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

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

אל תפנו לאפשרות הפיצול הישנה. היא פיצלה מנות בתוך המנהרה, הוסיפה תקורה, והוצאה משימוש מסיבות טובות; OpenVPN מודרני מצפה לתיאור מדויק של המסלול.

למה בדיקות קטנות ממשיכות לעבוד

שאילתות DNS, הדי ICMP ולחיצות ידיים של TCP כולם הרבה מתחת לגודל שנכשל. לכן המנהרה נראית בריאה בכל בדיקה מהירה בזמן שלחיצות ידיים של TLS ותגובות HTTP נכשלות בשקט. בדיוק השילוב הזה, traceroute שעובד ודפדפן שנתקע בתגובה הגדולה הראשונה, הוא הסימן לחפש. פנו לבדיקה בגודל מלא לפני שתפנו לפרופיל חדש.

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

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