SSH נתקע מעל OpenVPN? מדדו קודם את MTU הנתיב
ההד עובד, ואז רשימה מקפיאה את הסשן לתמיד. בדקו את התקרה משני הצדדים לפני שתשנו את mssfix, fragment או את MTU הממשק.
SSH מתחבר, ההנחיה מופיעה, והסשן מת ברגע שפקודה מחזירה משהו גדול. ההד ממשיך לעבוד זמן קצר, ואז החיבור פג תוקף בעוד הלקוח עדיין מציג את המנהרה כפעילה. סשן שתקין עד להגעת נתונים נתקל בדרך כלל במגבלת גודל ולא בפגם ב-SSH. הבדיקות שלהלן מסודרות כך שההסבר הזול ביותר ייפסל ראשון.
קראו את צורת הכשל לפני שנוגעים בפרופיל
מנות קטנות עוברות וגדולות לא. הנחיה, באנר או לחיצת מקש אחת נכנסים בקלות; רשימת תיקייה, הורדה או בלוק מודבק לא. הגודל שבו ההתנהגות משתנה הוא הרמז, ולא העובדה ש-SSH הוא התוכנית המעורבת.
המנגנון הוא גילוי MTU הנתיב, שתלוי במשוב. TCP בוחר גודל מקטע, וכאשר נתב בדרך אינו יכול להעביר את המנה הנוצרת, הוא אמור לומר זאת בהודעת ICMP. הכימוס הופך את המנה החיצונית לגדולה מהפנימית, ולכן הגודל השמיש בתוך מנהרה תמיד נמוך מהקישור הפיזי. סננו את הודעות ה-ICMP האלה בכל מקום והשולח לעולם לא יקבל את התיקון, ימשיך לשלוח מקטעים מלאים, והמנה החיצונית תיזרק בלי הודעה.
מדדו את התקרה משני הצדדים
השוו את ה-MTU של המנהרה לקישור הפיזי לפני שתשנו אחד מהם. מנהרה שהעתיקה את הערך הפיזי כבר אמרה לכם היכן נמצא אי-ההתאמה.
בדקו מתוך המנהרה בבקשה שאוסרת פיצול, תוך הורדת המטען עד שתשובות חוזרות. ארגומנט הגודל סופר רק את המטען, ולכן המספר שעובד תמיד נמוך מ-MTU של הממשק. הוסיפו בחזרה את גדלי הכותרות אם אתם צריכים את מספר הממשק.
ip link show tun0
ping -M do -s 1380 10.9.0.1חזרו על הבדיקה מול הכתובת הציבורית של השרת מבחוץ למנהרה. אם בדיקות גדולות נכשלות גם שם, המגבלה נמצאת בדרך לשרת ואף אפשרות של מנהרה לא תזיז אותה. ההשוואה הזאת חוסכת מכם כיוונון של לקוח שמעולם לא היה הבעיה. רשמו את שתי התוצאות לפני שתפתחו קובץ תצורה.
mssfix ו-fragment עושים עבודות שונות
mssfix מגביל את גודל המקטע שחיבורי TCP בתוך המנהרה מכריזים עליו בזמן לחיצת היד. זה המנוף הנכון ל-SSH, ל-HTTPS ולהעתקת קבצים, ולכן התקיעה נעלמת לעתים קרובות ברגע שהוא מוגדר. הוא לא נוגע במטעני UDP כלל.
מנהרה שנושאת גם שירות UDP עלולה להמשיך להיכשל אחרי תיקון SSH, והתוצאה הזאת מבלבלת כל מי שמניח שאפשרות אחת מכסה הכול.
fragment הוא המנגנון האחר וכלי שונה. הוא מפצל מנות גדולות מדי לפני הכימוס, חל רק על תעבורת UDP, מוסיף תקורה לכל דטה-גרם ומתועד כאמצעי אחרון לגילוי שבור. שתי ההגדרות חייבות להתאים אצל העמיתים שמסיימים את המנהרה. קצה אחד שמגביל והשני שמפצל מייצרים אזהרות ביומן והתנהגות שאיש לא יכול לחזות מהקבצים.
הורדת MTU של הממשק היא האפשרות הגסה
הקטנת MTU של הממשק בשני הקצוות היא הכלי הגס. היא אומרת לכל שולח פנימי מספר קטן יותר, וזה עובד, והיא מטילה את העלות הזאת על כל התעבורה במקום על זרמי ה-TCP שזקוקים לה.
בחרו בה כשהמנהרה נושאת תעבורה שאינכם יכולים להגביל, או כשהלקוח הוא מכשיר שאינכם שולטים בפרופיל שלו. הפעילו אותה באופן סימטרי ורשמו את הערך לצד הפרופיל. שינוי שהופעל למחצה גרוע מאשר כלום, מפני שהוא נראה כמו תיקון.
בדקו שוב עם ההעברה שנתקעה
התחברו מחדש כדי שההגדרות ייטענו, פתחו חיבור חדש וחזרו על הפקודה שקפאה. גודל המקטע נקבע בזמן לחיצת היד, ולכן סשן ששרד את ההתחברות מחדש עדיין נושא את הערך הישן. פינג הוא בדיקה גרועה כאן, מפני שכל הכשל הוא שמנות קטנות עוברות. השתמשו ברשימה, בהורדה או בהדבקה שנשברה.
אם התקיעה נמשכת בגודל קטן יותר, הסתכלו במקום אחר: חומת אש עם מצב שמפוגגת את הזרם, כתובת כפולה, או מסלול שמשתנה בהתחברות מחדש. רשמו את גודל הבדיקה שנכשל ואת ההגדרה ששיניתם, מפני שהצמד הזה הוא מה שעושה את הדוח הבא לשימושי.