У нас возникли проблемы с Windows Server 2003, который подключен к нашей сети через VPN.
Похоже, что с этим сервером все работает нормально, кроме загрузки файлового ресурса на локальные машины.
На локальных машинах работает Windows XP. Подключения удаленного рабочего стола к одному серверу работают отлично. Загрузка в общие файловые ресурсы также работает приемлемо. (Это удивительно, потому что сеть между нами на самом деле оценивается выше для загрузки, чем для загрузки.)
При перетаскивании файлов в локальную систему существует задержка> 10 секунд перед любой активностью индикатора выполнения. Скачивание файлов через командную строку имеет те же характеристики. Задержка возникает для каждого передаваемого файла, а не один раз для всего соединения. я пытался ping address -f -l 1472 чтобы убедиться, что это не проблема "маршрутизатора черной дыры" http://support.microsoft.com/kb/314825. Одна и та же задержка независимо от того, используется ли подключенный диск или UNC-путь, или выполняется ли соединение путем указания IP-адреса вместо имени хоста. Отключение «NetBIOS через TCP / IP» тоже не помогло. В реестре нет никаких дополнительных настроек TCP / IP (например, MTU), отличных от значений по умолчанию. Я попытался уменьшить MTU в реестре, и это тоже не помогло.
Любые идеи? Кроме того, по возможности были бы весьма признательны за обходные пути, которые включают настройку конфигурации локальной машины XP вместо конфигурации LAN / WAN или сервера.
Понюхайте трафик между клиентом и сервером и посмотрите, что происходит. Нет лучшего способа разобраться в проблеме протокола, чем посмотреть, что компьютеры говорят друг другу.
Протокол SMB - это общий собака при работе в скрытой сети. Я также подозреваю, что вы раньше видите активность «индикатора выполнения» при загрузке из-за артефактов реализации оболочки Windows, а не потому, что данные фактически передаются раньше. Я предполагаю, что одни и те же вещи происходят при каждой передаче файлов. Задержка для каждого файла придает некоторую достоверность такому выводу.
В прошлой жизни мы исправляли проблемы с передачей файлов (в частности, через VPN), уменьшая MTU. Ping-тесты с использованием пакетов размером около порогового значения MTU не были полезны; это правда, что вы исключаете черные дыры, но если бы у вас была черная дыра, вы, вероятно, не смогли бы сделать ничего полезного через VPN.
Наши проблемы были конкретно с передачей файлов SMB, я полагаю, из-за фрагментации пакетов. Значительно помогло уменьшение MTU до диапазона 1400-1420. Помните, что инкапсуляция VPN добавляет больше заголовков к каждому пакету (это было давно, поэтому я забыл о деталях, и мне лень гуглить сегодня вечером), но 1472 + ESP + AH + Ethernet намного больше, чем 1500 (при условии, что вы с использованием IPSec / ESP + AH). По моему опыту, чрезмерная фрагментация - это не проблема черного или белого; Тот факт, что определенные тесты проходят в определенное время, не означает, что вы можете исключить это позже.
Поскольку сервер отправляет данные в этом случае, вы можете посмотреть, можете ли вы установить MTU на сервере. Это также обычная точка, к которой подключаются все клиенты SMB, поэтому изменение MTU однажды может устранить необходимость устанавливать MTU для всех клиентов (поскольку MTU пути согласовывается между конечными точками).
Кроме того, тем, кто говорит ему запустить wirehark - что конкретно вы посоветуете ему искать? Я не уверен, что это «ошибка протокола» - SMB, вероятно, сбрасывает свое соединение из-за задержки и / или отбрасывания пакетов, поэтому технически SMB выполняет свою работу (это просто хрупкий протокол) - и я Я не уверен, что tcpdump / sniffer / wirehark укажет им на решение. Я люблю отслеживать сетевые сетевые разговоры так же сильно, как и следующий CCNP, но в чужих руках скальпель бесполезен / опасен. Он уже сказал, что не администратор сети ...