การคัดลอกไฟล์ตกต่ำเมื่อ VPN เชื่อมต่อ: SMB หลายช่องสัญญาณ
สำเนาต้องรอช่องสัญญาณที่ช้าที่สุด การทดสอบแบนด์วิดท์ที่ดูปกติจึงซ่อนสาเหตุไว้ ตรวจสอบช่องสัญญาณของอุโมงค์ ถอดออกจาก SMB แล้ววัดทั้งสองเส้นทาง
การคัดลอกไฟล์ระหว่างเครื่อง Windows สองเครื่องจะเร็วจนกว่าทั้งคู่จะเข้าร่วม VPN เดียวกัน แล้วมันก็ดิ่งลง ในขณะที่การทดสอบอัตราการส่งผ่านคู่เดิมยังรายงานความเร็วใกล้เคียงความเร็วสาย ช่องว่างนั้นคือการวินิจฉัย: ลิงก์ปกติดีและมีบางอย่างกำลังเลือกเส้นทางที่แย่กว่าสำหรับการถ่ายโอนเอง สิ่งนั้นมักคือ SMB3 หลายช่องสัญญาณ ซึ่งทำสิ่งที่ออกแบบมาให้ทำพอดี ถอดช่องสัญญาณส่วนเกินออกไป แล้วสำเนาจะกลับไปใช้ลิงก์กายภาพ
อาการรอช่องสัญญาณที่ช้าที่สุด
หลายช่องสัญญาณช่วยให้เซสชัน SMB หนึ่งเซสชันใช้การเชื่อมต่อ TCP หลายรายการ หนึ่งรายการต่อคู่ที่อยู่ที่เหมาะสมระหว่างไคลเอนต์และเซิร์ฟเวอร์ เมื่อเครื่องทั้งสองอยู่บน LAN และบนอุโมงค์เดียวกัน Windows สามารถจับคู่ที่อยู่ของ LAN กับที่อยู่ของอุโมงค์และถือว่าทั้งสองคู่ใช้งานได้ ในที่สุดเซสชันก็มีช่องสัญญาณมากกว่าที่ลิงก์กายภาพต้องการ และหนึ่งในนั้นช้ากว่ามาก
มันไม่ได้ล้มเหลว มันรอ เพราะเซสชันไม่สามารถเสร็จเร็วกว่าช่องสัญญาณที่ช้าที่สุดของมันได้
นั่นคือเหตุผลที่การทดสอบแบนด์วิดท์อาจดูปกติในขณะที่สำเนาคลาน: การวัดแบบสตรีมเดียวอาจเลือกเส้นทางหนึ่ง ขณะที่การถ่ายโอนกระจายอยู่บนสองเส้นทาง อ่านรายการช่องสัญญาณก่อนเปลี่ยนการตั้งค่าอะแดปเตอร์ใดๆ และอ่านขณะที่สำเนายังทำงานอยู่ เพราะเซสชันที่ไม่ได้ใช้งานไม่แสดงอะไรเลย สิ่งที่คุณจดบันทึกควรระบุอินเทอร์เฟซที่อยู่เบื้องหลังแต่ละช่องสัญญาณ ไม่ใช่แค่ว่าผลลัพธ์รู้สึกช้าแค่ไหน
ยืนยันว่ามีช่องสัญญาณที่สองอยู่จริง
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เลือกเส้นทาง LAN โดยไม่แสร้งว่ามันลบช่องสัญญาณ
เมตริกของอินเทอร์เฟซบอก Windows ว่าควรเลือกเส้นทางใดสำหรับการเชื่อมต่อใหม่ มันไม่ได้ลบช่องสัญญาณที่หลายช่องสัญญาณตัดสินใจจะเปิดแล้ว การเพิ่มเมตริกของอุโมงค์ยังคุ้มอยู่ เพราะมันทำให้ทราฟฟิกที่ไม่เกี่ยวข้องอยู่ห่างจากเส้นทางที่ช้าและทำให้เส้นทางที่ต้องการคาดเดาได้ แต่เป็นการผลัก ไม่ใช่ตัวกรอง
Get-NetIPInterface | Sort-Object InterfaceMetric | Select-Object InterfaceAlias, InterfaceMetric
Set-NetIPInterface -InterfaceAlias "OpenVPN Data Channel Offload" -AutomaticMetric Disabled -InterfaceMetric 1000คัดลอกนามแฝงจากเอาต์พุตนั้นแทนการพิมพ์เอง เพราะการติดตั้งบางแบบแปลชื่ออะแดปเตอร์เป็นภาษาท้องถิ่นและสตริงภาษาอังกฤษจะไม่ตรงกัน
จากนั้นวัดทั้งสองตัวเลขอีกครั้ง: การคัดลอกไฟล์และการทดสอบอัตราการส่งผ่านบนคู่เดิม หากสำเนาฟื้นตัวในขณะที่การทดสอบอัตราการส่งผ่านไม่เคยช้าเลย แสดงว่าหลายช่องสัญญาณเป็นสาเหตุและคุณหยุดได้ หากทั้งคู่ดิ่งลง อุโมงค์คือคอขวด และหลายช่องสัญญาณเพียงขยายมันขึ้นมา หากสำเนายังช้าอยู่ในขณะที่ทั้งสองเส้นทางดูถูกต้อง ปัญหาที่เหลืออยู่ในแชร์ ที่เก็บข้อมูล หรือไดรเวอร์ตัวกรอง ซึ่งเป็นการสอบสวนอีกเรื่องหนึ่ง