Что может привести к тому, что клиентский компьютер с Windows 7 не сможет подключиться к общему сетевому ресурсу по IP-адресу?

У нас есть файловый сервер Nexenta, который использует аутентификацию домена для пользователей. Все машины с Windows 7 в нашей сети могут без проблем подключаться и использовать общие ресурсы, используя \XX.YY.ZZ.AA\share или \fileserver\share.

Мы добавили новый компьютер с Windows 7 в наш домен, и по какой-то причине я не могу получить доступ к файловому серверу, используя \XX.YY.ZZ.AA\share или \fileserver\share. Я могу пропинговать и подключаться к веб-интерфейсу файлового сервера с нового компьютера, но не могу подключиться к общим ресурсам, даже если подключен к этому новому компьютеру с учетной записью пользователя, которая может получить доступ к общему ресурсу с других работающих компьютеров с Windows 7.

Когда я пытаюсь подключиться по IP-адресу, я получаю сообщение об ошибке:

Проверьте правильность написания имени. В противном случае может возникнуть проблема с вашей сетью. Чтобы попытаться выявить и устранить проблемы с сетью, нажмите "Диагностика".

Когда я пытаюсь подключиться по имени машины, я получаю сообщение об ошибке:

\ fileserver \ share недоступен. Возможно, у вас нет разрешения на использование этого сетевого ресурса. Свяжитесь с администратором этого сервера, чтобы узнать, есть ли у вас права доступа.

Невозможность подключиться к общему ресурсу по номеру IP кажется мне очень странной.

Новая информация (1) Еще один лакомый кусочек информации. Пока подключение работало на моей машине с Windows 7, я запустил ipconfig /flushdns, и он вдруг перестал работать. Не могу подключиться к нему по IP или по имени.

Новая информация (2) Чтобы прояснить новую информацию (1), файловый сервер имеет два IP-номера, один из которых он использует только для подключения к своей сети SAN, а другой - для подключения к общей сети. Когда я не могу подключиться к нему, я могу пинговать его без каких-либо проблем: т.е. я вижу:

ping fileserver Pinging fileserver.domain.com XXX.XXX.XXX.XX с 32 байтами данных: ответ от XXX.XXX.XXX.XXX: байт =32 время<1 мс TTL=254

Если я запускаю ipconfig /flushdns, он иногда выбирает IP-адрес интерфейса SAN для этого имени. Теперь, когда я пингую файловый сервер, я не могу добраться до него (как и ожидалось)

ping fileserver Pinging fileserver.domain.com ГГГГГГ.ГГГ.ГГГ с 32 байтами данных: время ожидания

НО, а вот странная вещь. Теперь я могу подключиться к ресурсу \fileserver.

Мне бы очень хотелось, чтобы MS предоставил вам лучший способ включить вход в ОС. У меня такое ощущение, что происходящее связано с тем, что клиент пытается найти имя сервера с помощью DNS и пытается подключиться, и что, когда это невозможно (поскольку DNS возвращает IP-адрес интерфейса SAN, я не могу достичь), что он возвращается к NETBIOS, что по какой-то причине заставляет его работать.

1 ответ

Я бы начал со сравнения настройки LMCompatiblityLevel между нерабочими и рабочими машинами. У меня возникает ощущение, что что-то не так с согласованием протокола NTLM между клиентом и сервером.

Если вы можете, получайте пакетный трафик между клиентом и сервером для каждой описанной вами попытки. Нет ничего лучше, чем увидеть, что происходит с битами на проводе.

Редактировать:

Мне трудно придумать DNS как проблему. Это не объясняет сообщение, которое вы видите, когда пытаетесь получить доступ к машинам по IP-адресу, который, похоже, не устанавливает TCP-соединение. Я мог видеть, что DNS (Kerberos и доменное имя в SPN, в частности) был вовлечен, если это было похоже на соединение TCP, но аутентификация не удалась.

Захватить немного трафика. Пакеты хотят рассказать вам, что происходит... > улыбаться<

Другие вопросы по тегам