העתקות קבצים קורסות כשה-VPN מתחבר: ריבוי ערוצים ב-SMB

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

התסמין ממתין לערוץ האיטי ביותר שלו

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

זה לא נכשל. זה ממתין, כי הסשן אינו יכול להסתיים מהר יותר מהערוץ האיטי ביותר שלו.

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

אשרו שקיים ערוץ שני

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

Get-SmbMultichannelConnection
Get-SmbConnection

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

Get-NetIPAddress -IPAddress 10.20.30.44

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

הוציאו את המנהרה מ-SMB ואז מדדו שוב

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

Set-SmbClientConfiguration -EnableMultiChannel $false -Force
Set-SmbServerConfiguration -EnableMultiChannel $false -Force

אשרו את המצב החדש ואז ראו מה השרת מכריז כעת ללקוחות.

Get-SmbClientConfiguration | Select-Object EnableMultiChannel
Get-SmbServerNetworkInterface | Format-List *

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

Get-NetAdapterBinding -Name "OpenVPN Data Channel Offload"
Disable-NetAdapterBinding -Name "OpenVPN Data Channel Offload" -ComponentID ms_server

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

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

Get-NetIPInterface | Sort-Object InterfaceMetric | Select-Object InterfaceAlias, InterfaceMetric
Set-NetIPInterface -InterfaceAlias "OpenVPN Data Channel Offload" -AutomaticMetric Disabled -InterfaceMetric 1000

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

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