Что может привести к тому, что клиентский компьютер с 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, но аутентификация не удалась.
Захватить немного трафика. Пакеты хотят рассказать вам, что происходит... > улыбаться<