Назад | Перейти на главную страницу

Не удается подключиться к общим сетевым ресурсам при подключении к VPN. Ошибка: «не удалось найти имя пользователя»

Я постоянно обнаруживаю, что в локальной сети нашей небольшой компании (7 пользователей, 3 сервера) некоторые серверы становятся «недоступными» для целей обмена файлами. Они отображают сообщение «\ СЕРВЕР недоступен. Возможно, у вас нет разрешения на использование этого сетевого ресурса. Не удалось найти имя пользователя». Но я не знаю, почему «имя пользователя не может быть найдено», поскольку все машины находятся в одном домене, а PDC и BDC, похоже, работают нормально.

РЕДАКТИРОВАТЬ:

Кажется, причина в VPN:

Оказывается, я могу видеть сервер, если использую IP-адрес (\\ 1.2.3.4 \ etc) или имя активного каталога FQ (например, \ server.domainname.local), но не, если я использую имя сервера само по себе или подключенный сетевой диск, изначально созданный из «короткого» имени. Как ни странно, у моей машины нет проблем с разрешением DNS-имени сервера, так как я могу пропинговать имя машины ОК, и он немедленно возвращается с IP, однако nslookup, похоже, не работает.

Кажется, проблема в том, как Windows ищет имена компьютеров при подключении к VPN. Когда я подключаюсь к VPN, кажется, что окна используют DNS, связанный с VPN, а не тот, который установлен на контроллере домена. Такое поведение мне кажется неправильным, поскольку это, безусловно, означало бы, что подключение к любой VPN нарушит любую возможность поиска имен локальных машин для серверов, принтеров и т. Д. Итак, я предполагаю, что реальный вопрос сейчас в том, как я могу заставить мою машину все еще искать локальные Active Directory DNS (PDC) даже при подключении к VPN?

Больше информации в моих комментариях ниже.

Установите UseRasCredentials = 0, как описано здесь: https://www.conetrix.com/Blog/post/Access-Domain-Resources-When-Connected-to-VPN.aspx

При некоторых настройках VPN требуется, чтобы вы проходили через шлюз VPN. Таким образом они поддерживают более безопасную сетевую среду, не позволяя загружать файлы с потенциально опасных сайтов.

Если у вас слабая настройка VPN, вы также можете снять флажок, который использует шлюз VPN по умолчанию, чтобы любые запросы сначала попадали на ваш шлюз (и домен dns), прежде чем попасть на шлюз и DNS VPN.

  • В Windows 7 я щелкаю значок сети, чтобы просмотреть свои подключения, щелкаю правой кнопкой мыши VPN и выбираю «Свойства».
  • Затем щелкните вкладку «Сеть».
  • для каждого IPv6 и IPv4 (если они включены) дважды щелкните элемент, нажмите «Дополнительно», затем снимите флажок «Использовать шлюз по умолчанию в удаленной сети». Дважды нажмите OK и следуйте инструкциям для остальных версий IP.

Отключитесь и снова подключитесь к VPN, если она у вас была активна.

Если вы заметили какие-либо проблемы с подключением, повторно включите шлюзы по умолчанию. Как я уже сказал ранее, для VPN может потребоваться его включение.

Измените порядок привязки так, чтобы физическая сетевая карта была выше, чем интерфейс VPN. Возможно, вам придется вручную (или с помощью сценария) разобраться в вещах дальше, в зависимости от того, что делает программное обеспечение VPN.

Ваш DNS-сервер для клиентов VPN такой же, как DNS-сервер для клиентов Lan?

Я думаю, ваша проблема в том, что клиенты VPN используют свой DNS-сервер от провайдера, а не от DNS вашего VPN. Вы можете заставить VPN-клиент использовать VPN-сервер на следующем шаге:

  • Найдите этот раздел реестра:

    HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Linkage

  • Двойной клик Привязать

  • Шаг "\ Устройство \ NdisWanIp"элемент вверху списка

  • Перезагрузите клиент.

или используйте простой reg-файл:

% systemroot% \ system32 \ reg.exe ДОБАВИТЬ HKLM \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Linkage / f / v Bind / t REG_MULTI_SZ / d \ Device \ NdisWanIp \ 0 ...

Помните сделайте резервную копию вашего реестра прежде чем что-либо делать в нем.

У меня была аналогичная проблема, когда DNS разрешился, но не мог проверить связь или трассировку IP. Я решил свою проблему, перепроверив настройки IP на сервере. Оказывается, у него не было шлюза по умолчанию, и его установка устранила проблему.

Если вы не можете подключиться к общему ресурсу только с использованием «короткого» имени IE NetBIOS, я бы рекомендовал использовать WINS-сервер, поскольку он позволит вам разрешать NetBIOS-имена через VPN, если это позволяет ваш адаптер VPN. вы должны указать WINS-сервер. Для меня наш внутренний DNS-сервер AD также настроен как WINS-сервер, а наш VPN-сервер (Sonicwall) публикует и DNS- и WINS-сервер для наших VPN-клиентов. С помощью этой конфигурации мы можем разрешить как имена NetBIOS, так и полное доменное имя.

Еще вы можете изменить настройки DNS в дополнительных свойствах TCP на вашем сетевом адаптере. Это будет иметь ваше разрешение коротких имен:

  1. WINS
  2. DNS с использованием суффикса 1
  3. DNS с использованием суффикса 2
  4. DNS с использованием суффикса N

надеюсь, это поможет

Я думаю, вам нужно настроить брандмауэр для использования PDC в качестве DNS, чтобы он выдавал этот DNS-сервер клиентам VPN. Или вы можете перенаправить запросы VPN на PDC и сделать его сервером RAS для использования SSTP, чтобы клиенты определенно имели согласованный опыт работы с DNS, будь то в VPN или LAN.

Если вы можете PING удаленного назначения - (попробуйте использовать ip / или его DNS-имя).

Мне пришлось удалить все существующие сетевые диски с помощью следующей команды из командной строки: net use * / delete Затем я перезагрузил компьютер, подключился к vpn и снова подключил сетевой диск, используя другие учетные данные - и вуаля, он работает!

Я обнаружил, что мне пришлось сбросить пароль и выполнить разблокировку учетной записи пользователя изнутри пользователей и учетных записей на сервере.

На рабочей станции не отображаются учетные данные для учетных записей домена.

Каким-то образом пароль был сохранен для пользователя неправильно, когда пользователь вошел в систему с неправильным паролем.

Смена пароля очистила кеш и все работает.