Git נתקע ב-WSL2 מאחורי VPN: MTU של הממשק או של המסלול?

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

שלושה סימנים מפרידים בעיית גודל ממשהו אחר

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

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

השוו את שני הממשקים לפני החלטה

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

netsh interface ipv4 show subinterfaces
wsl -d Ubuntu -- bash -lc 'dest=$(getent ahostsv4 github.com | awk \'NR==1{print $1}\'); ip -br link show; ip route get "$dest"'

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

החליטו אם המספר צריך להיות קטן יותר

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

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

ip -br link show dev eth0
sudo ip link set dev eth0 mtu 1380
ip -br link show dev eth0

החליטו היכן ההגדרה צריכה לחיות

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

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

מה שיש להימנע ממנו הוא המיקום המפתה: פקודת רשת בעלת הרשאה בקובץ האתחול של כל מעטפת אינטראקטיבית, או sudo ללא סיסמה לכל קובץ ה-ip הבינרי כדי שסקריפט יוכל להריץ שורה אחת. שניהם הופכים אבחנה לחשיפה קבועה והופכים את הבעיה המקורית לקשה יותר לראות בהמשך.

אמתו אחרי התחלה נקייה ואז החזירו

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

ip -br link show dev eth0
ip route get "$(getent ahostsv4 github.com | awk 'NR==1{print $1}')"

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