Не вдається підключитися до спільних ресурсів локальної мережі, коли підключено до VPN. Помилка: "ім'я користувача не вдалося знайти"

Я постійно констатую, що в нашій невеликій локальній мережі (7 користувачів, 3 сервери) деякі сервери продовжують ставати «недоступними» для цілей обміну файлами. У них відображається повідомлення "\ SERVER недоступний. Ви можете не мати дозволу на використання цього мережевого ресурсу. Ім'я користувача не вдалося знайти". Але я не знаю, чому "ім'я користувача не вдалося знайти", оскільки всі машини знаходяться в одному домені, і PDC та BDC, здається, ведуть себе нормально.

Редагувати:

Здається, причиною є VPN:

Виявляється, я бачу сервер, якщо використовую IP-адресу (\\ 1.2.3.4 \ тощо) або ім'я активного каталогу FQ (наприклад, \ server.domainname.local), але ні, якщо я використовую ім'я сервера самостійно або картографічний мережевий накопичувач, створений спочатку з "короткого" імені. Як не дивно, але на моїй машині не виникає проблем з вирішенням імені DNS сервера, оскільки я можу пінговувати ім’я машини ОК, і воно негайно повертається з IP, однак nslookup, здається, не працює.

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

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

Налаштування UseRasCredentials = 0, як описано тут: https://www.conetrix.com/Blog/post/Access-Domain-Resources-When-Connected-to-VPN.aspx

Для деяких налаштувань VPN потрібно пройти через шлюз VPN. Саме тому вони підтримують безпечніше мережеве середовище, не дозволяючи завантажувати матеріали з потенційно загрозливих сайтів.

Якщо у вас налаштовано слабке налаштування VPN, ви можете також зняти прапорець, який використовує шлюз за замовчуванням VPN, тому будь-які запити спочатку потрапляють на ваш шлюз (і домен dns), перш ніж потрапляти на шлюз VPN та DNS.

• У Windows 7 я натискаю піктограму мережі, щоб переглянути свої з'єднання, клацніть правою кнопкою миші VPN та виберіть "Властивості".
• Далі натисніть на вкладку "Мережа".
• для кожного IPv6 та IPv4 (якщо вони включені), двічі клацніть елемент, натисніть "розширено", а потім зніміть прапорець "Використовувати шлюз за замовчуванням у віддаленій мережі". Клацніть ОК двічі та виконайте кроки для решти версій IP.

Відключіть і підключіться до VPN, якщо він був активним.

Якщо ви помітили будь-які проблеми з підключенням, повторно ввімкніть шлюзи за замовчуванням. Як я вже говорив раніше, VPN може вимагати, щоб це було ввімкнено.

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

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

• Знайдіть цей ключ реєстру:

  HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Зв'язок

• Двічі клацніть Прив’язати
• Перемістіть елемент " \ Device \ NdisWanIp " на верхню частину списку
• Перезапустити клієнта.

або використовувати простий файл рег:

% systemroot% \ system32 \ reg.exe ДОДАТИ HKLM \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Linkka / f / v Прив’язати / t REG_MULTI_SZ / d \ Пристрій \ NdisWanIp \ 0 ...

Запам’ятайте резервну копію свого реєстру, перш ніж робити що-небудь в ньому.

Змініть порядок прив’язки, щоб фізичний NIC був вищим, ніж інтерфейс VPN. Можливо, вам доведеться вручну (або за допомогою скрипту) копати речі далі, залежно від того, що робить програмне забезпечення VPN.

У мене була подібна проблема, коли DNS вирішував, але не міг пінг або простежити IP-адресу. Я вирішив свою проблему шляхом повторної перевірки налаштувань IP на сервері. Виявляється, у нього не було шлюзу за замовчуванням, і налаштування його вирішило проблему.

Якщо ви не в змозі підключитися до спільного доступу, використовуючи "коротке" ім'я, ім'я IE NetBIOS, то я б рекомендував використовувати сервер WINS, оскільки це дозволить вам вирішувати імена NetBIOS через VPN, доки ваш адаптер VPN дозволяє вам потрібно вказати сервер WINS. Для мене внутрішній сервер DNS AD також налаштований як WINS-сервер, а наш VPN-сервер (Sonicwall) публікує і DNS, і WINS-сервер для наших VPN-клієнтів. За допомогою цієї конфігурації ми можемо вирішити як імена NetBIOS, так і FQDN.

Інше, що ви можете зробити, - це змінити ваші DNS-адреси, достатньо заздалегідь властивості TCP на вашому мережевому адаптері. У цьому розділі буде розміщено ваше ім'я для коротких імен:

1. ПЕРЕГЛЯД
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 і знову відмітив мережевий диск за допомогою різних облікових даних і voilà, він працює!

Я виявив, що мені потрібно скинути пароль і зробити розблокування для акаунта користувача з боку користувачів та облікових записів на сервері.

Робоча станція не відображає облікових даних для облікових записів домену.

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

Зміна пароля очистила кеш і все працює.