Копирование файлов проваливается при подключении VPN: многоканальность SMB
Копия ждёт самый медленный канал, поэтому исправный тест пропускной способности скрывает причину. Подтвердите канал туннеля, уберите его из SMB и затем измерьте оба пути.
Копирование файла между двумя машинами Windows идёт быстро, пока обе не подключатся к одной и той же VPN, и тогда оно проваливается, хотя тест пропускной способности по той же паре по-прежнему показывает почти скорость линии. Именно этот разрыв и есть диагноз: соединение в порядке, и что-то выбирает худший путь для самой передачи. Это что-то обычно многоканальность 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Скопируйте псевдоним из этого вывода, а не вводите его вручную, потому что в некоторых установках имя адаптера локализовано и английская строка не совпадёт.
Затем снова измерьте оба числа: копирование файла и тест пропускной способности по той же паре. Если копия восстанавливается, а тест пропускной способности никогда не был медленным, причиной была многоканальность, и можно остановиться. Если проваливаются оба, туннель и есть узкое место а многоканальность только усилила его. Если копия остаётся медленной, а оба пути выглядят правильными, оставшаяся проблема живёт в общем ресурсе, хранилище или драйвере фильтра, и это другое расследование.