למה דפי OpenConnect נתקעים עד שתורידו את ה-MTU של המנהרה

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

הפרידו בעיית גודל מבעיית מדיניות

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

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

מדדו את התקרה עם בדיקות do-not-fragment

מדדו את התקרה במקום לנחש אותה. שלחו בדיקות שמסרבות לפיצול והורידו את המטען צעד אחר צעד עד שתשובה חוזרת, החל מפקודה כמו ping -M do -s 1472 host. תשובה שמתלוננת שנדרש פיצול בזמן ש-DF מוגדר פירושה שהערך עדיין גבוה מדי. חזרו על זה ב-1462, אחר כך ב-1452, ועצרו בגודל הראשון שמחזיר תשובה. רשמו את המספר יחד עם המארח שבדקתם, כי התשובה שייכת לנתיב הזה ולא לפרוטוקול בכלל.

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

החילו את הערך על התקן המנהרה

החילו את התוצאה על הממשק שהלקוח יצר, לא על מתאם ה-Wi-Fi. בלקוח לינוקס זה ip link set dev tun0 mtu 1300 ואחריו ip link show tun0 כדי לאשר שהערך התקבל. השתמשו בכל שם התקן שהלקוח מדווח עליו, כי הוא משתנה לפי המימוש ולפי האופן שבו נבנתה המנהרה.

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

השתמשו קודם בבקשות ה-MTU של הלקוח עצמו

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

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

אמתו עם ההעברה שנכשלה, ואז הפכו את זה לקבוע

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

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

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