OpenVPN mssfix: מדוע לקוח אחד נתקע בהעברות גדולות

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

מה האפשרות כותבת מחדש

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

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

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

ההיקף הוא TCP בתוך המנהרה

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

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

המספר ומילת המפתח אינם ניידים

גרסת הקהילה של OpenVPN 2.6 מקבלת מילת מפתח אופציונלית אחרי הערך. עם mtu, המספר מתאר את גודל המנה החיצונית כולל כותרות IP ו-UDP; בלעדיה, הארגומנט עוקב אחרי מוסכמת חשבונאות אחרת. לכן שורה שהועתקה בין גרסאות אינה מתארת את אותו תקציב מנות. בדקו את עמוד המדריך שמגיע עם הבנייה שאתם מריצים בפועל, ולא מדריך לגרסה אחרת.

התחביר נראה כך:

mssfix 1400 mtu

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

אשרו קודם בלקוח האחד

מדדו את הנתיב מהמכונה שנכשלת לפני שאתם משנים משהו. מטען שהנתיב יכול לשאת בלי פיצול הוא המספר שאתם מחפשים:

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

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

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