दोनों पीसी एक ही VPN से जुड़ते हैं तो SMB कॉपी धीमी क्यों हो जाती है

गीगाबिट LAN पर दो Windows मशीनों के बीच फ़ाइल कॉपी, दोनों के एक ही VPN से जुड़ते ही रेंगने लगती है, जबकि उसी जोड़ी के बीच थ्रूपुट परीक्षण अब भी लगभग लाइन दर बताता है। समस्या लिंक में नहीं है, और डिस्क में भी नहीं। SMB3 Multichannel ने चुपचाप एक दूसरा TCP कनेक्शन जोड़ दिया है जो टनल से होकर जाता है, और कॉपी सबसे धीमे चैनल का इंतज़ार करती है। SMB से वह रास्ता हटाने पर LAN की गति लौट आती है।

एक शेयर कई TCP कनेक्शनों पर चल सकता है

Multichannel क्लाइंट को एक सर्वर से स्वतंत्र कनेक्शन खोलने देता है, हर उपयुक्त पता-जोड़ी के लिए एक। सादे LAN में शायद एक ही जोड़ी हो, इसलिए कुछ हैरान करने वाला नहीं होता। दोनों मशीनों पर VPN एडाप्टर जोड़ें और Windows दूसरी जोड़ी देखता है, टनल पता बनाम टनल पता, और उस पर एक चैनल खोलता है।

वह चैनल एन्क्रिप्टेड है, टनल के साथ CPU साझा करता है और बाकी सब की तरह उसी WAN लिंक से गुज़रता है। जो कॉपी अकेले LAN का उपयोग करती, उसके सेट में अब एक धीमा सदस्य है, और SMB उसे चुपचाप छोड़ता नहीं।

LAN पते पर बँधा थ्रूपुट परीक्षण अब भी स्वस्थ दिखता है, और ठीक इसी कारण दोनों मापन इतने तीखे रूप से अलग होते हैं।

कुछ भी बदलने से पहले साबित करें कि टनल चैनल मौजूद है

कॉपी चलते समय क्लाइंट पर क्वेरी चलाएँ, क्योंकि चैनल सूची तभी दिलचस्प होती है जब वह जीवंत हो।

Get-SmbMultichannelConnection | Where-Object Selected -eq $true | Format-Table ServerName, ClientIPAddress, ServerIPAddress
Get-SmbConnection | Format-Table ServerName, Dialect, NumOpens

एक ही सर्वर के लिए एक से अधिक चयनित पंक्ति वही पुष्टि है जो आपको चाहिए। संदिग्ध पंक्ति के क्लाइंट पते को किसी इंटरफ़ेस में हल करें। यदि वह उपनाम VPN एडाप्टर है, तो चैनल वास्तविक है, पुरानी प्रविष्टि नहीं।

Get-NetIPAddress -IPAddress 10.8.0.6 | Format-List IPAddress, InterfaceAlias

पते हर मशीन पर अलग होते हैं, इसलिए ऊपर के उदाहरण टाइप करने के बजाय वे पढ़ें जो आपका अपना आउटपुट बताता है।

SMB से टनल निकालें और दोनों छोर फिर से शुरू करें

Multichannel बंद करना क्लाइंट और सर्वर दोनों पर बदलाव है, और केवल एक तरफ करने से दूसरा पक्ष इंटरफ़ेस पेश करता रहने के लिए स्वतंत्र रहता है। मौजूदा चैनल सेटिंग के बाद भी बने रहते हैं, इसलिए अगली कॉपी के अलग व्यवहार की उम्मीद करने के बजाय रीस्टार्ट की योजना बनाएँ।

Set-SmbClientConfiguration -EnableMultiChannel $false -Force
Set-SmbServerConfiguration -EnableMultiChannel $false -Force
Get-SmbClientConfiguration | Select-Object EnableMultiChannel

रीबूट के बाद, सर्वर SMB के लिए जो इंटरफ़ेस पेश करता है उन्हें सूचीबद्ध करें। टनल एडाप्टर उस सूची से गायब होना चाहिए। यदि वह अब भी मौजूद है, तो सेटिंग गलत एंडपॉइंट पर पहुँची है या कोई पुराना सत्र अब भी खुला है।

Get-SmbServerNetworkInterface | Format-List Name, InterfaceAlias, LinkSpeed

जब लक्ष्य हर जगह Multichannel बंद करने से अधिक संकीर्ण हो, तो सर्वर घटक को टनल एडाप्टर से अनबाइंड करना उसके ज़रिए शेयरिंग रोक देता है जबकि बाकी VPN अछूता रहता है।

Get-NetAdapterBinding -Name "<vpn adapter>" -ComponentID ms_server
Disable-NetAdapterBinding -Name "<vpn adapter>" -ComponentID ms_server

LAN को प्राथमिकता दें और एक ही तरह से दो बार मापें

इंटरफ़ेस मीट्रिक चैनल नहीं हटाता, लेकिन नए कनेक्शनों को भौतिक लिंक की ओर मोड़ता है और असंबंधित ट्रैफ़िक को टनल से दूर रखता है। उपनाम को टाइप करने के बजाय आउटपुट से कॉपी करें, क्योंकि कुछ इंस्टॉल पर यह स्थानीयकृत होता है।

Get-NetIPInterface | Sort-Object InterfaceMetric | Select-Object InterfaceAlias, InterfaceMetric
Set-NetIPInterface -InterfaceAlias "<vpn adapter>" -AutomaticMetric Disabled -InterfaceMetric 9000

फिर दोनों मापन दोहराएँ: फ़ाइल कॉपी और सिंगल-स्ट्रीम थ्रूपुट परीक्षण। यदि कॉपी सुधर जाती है जबकि थ्रूपुट परीक्षण अपरिवर्तित रहता है, तो टनल कभी अवरोध नहीं था। यदि दोनों धराशायी हो जाएँ, तो VPN मार्ग ही सीमा है और Multichannel ने उसे केवल दृश्यमान बनाया। VPN जुड़ने से पहले ली गई कॉपी से तुलना करें, क्योंकि वही एकमात्र आधार-रेखा है जो बदलाव को अलग करती है।

Multichannel बंद करने पर उन सर्वरों पर थ्रूपुट की कीमत चुकानी पड़ती है जो वास्तव में कई तेज़ मार्ग देते हैं, इसलिए जब VPN दृश्य से हटे तो उसे फिर चालू करें। लिख लें कि आपने कौन-सा एडाप्टर बदला, क्योंकि अगला व्यक्ति सेटिंग पाएगा, कारण नहीं।