Просмотр подключенных сетевых дисков при подключении через VPN

У меня есть пользователи, которые постоянно выезжают за пределы офиса.

Внутри они подключили сетевые диски.

Затем они выходят наружу и подключаются через VPN, которая при подключении соединяет мосты и помещает их в одну подсеть. Они могут без проблем пинговать ресурсы в сети через VPN.

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

Подробности следующие:

Внутренне все работает нормально
Я использую WINS на сервере, к которому они пытаются подключиться.
Этот WINS-сервер предоставляется в опциях DHCP для VPN-клиентов.
DNS предоставляется в опции DHCP для VPN-клиентов Для привязок адаптера
В свойствах сетевого адаптера клиентов Windows 7 я убедился, что удаленные подключения являются наивысшим приоритетом по сравнению с локальными подключениями.
Если используется подключение по IP-адресу, оно работает, но не работает при подключении по имени машины

Какие еще шаги я должен попытаться решить выше?

Соблюдаете ли вы при устранении неполадок то же имя, что и при подключении к общему сетевому ресурсу? Например, вы пингуете:

ping servername.domain

Но подключение к общему ресурсу сервера:

\\servername\share

Если вы можете выполнить ping с помощью fqdn, попробуйте таким же образом настроить сетевые ресурсы пользователя. Раньше я видел проблемы, когда не указывалось имя домена, когда вместо этого VPN пытается получить доступ к локальной сети пользователя.

Мне также любопытно, получаете ли вы внешний IP-адрес при пинге сетевых ресурсов. Я видел VPN-подключения к сети, в которой домен Windows также является веб-сайтом компании, и проверка связи с servername.domain.com приводит к получению результата от веб-сервера для всей почты домена, а не от внутреннего ресурса.

Прежде всего, очевидный факт: есть ли в этом случае значительная потеря пакетов через VPN-соединение? Попробуйте выполнить пинг с увеличенным размером пакета:

ping -l 1200 servername.your.internal.domain

У меня был неудачный опыт даже с незначительной (~ 1-10%) потерей пакетов и множеством повторных передач TCP в соединении, которое несет полезную нагрузку SMB (порты tcp / 445 и tcp / 139 на стороне сервера).

Другой - это разрешение имени: первое решение - попытаться установить сетевое соединение, используя IP-адрес сервера вместо имени. Так пусть кто-нибудь попробует

net use X: \\10.0.1.200\sharename

и посмотрите, пройдет ли это.

Если это «исправляет», внимательно следите за разрешением имен. Не уверен насчет WINS, но, возможно, отключите его и попытайтесь полагаться на DNS. Что такое первичный и вторичный DNS-серверы имен (ipconfig /all)? проверьте, предоставляют ли они оба правильный IP-адрес:

nslookup servername.your.internal.domain 10.0.1.1
nslookup servername.your.internal.domain 10.0.1.2

(10.0.1.1 и 10.0.1.2 будут DNS-серверами)

Может быть, Windows пытается установить соединение через IPv6, но оно автоматически отключается? Попробуйте временно отключить IPv6-протокол на активных адаптерах.

Удачи!

Быстрый и грязный способ исправить это - использовать файл hosts.ini.

Расположение:

\ Windows \ system32 \ drivers \ etc \

Убедитесь, что вы редактируете на машине как администратор.

Начните снизу и добавьте серверы, к которым им нужно подключиться. Введите ЧАСТНЫЙ IP-адрес, нажмите вкладку, затем введите полное доменное имя (FQDN). Затем сохраните.

Теперь пользователь должен иметь возможность подключиться к серверу, используя имя.

Если вы не хотите использовать файл Hosts.ini, проверьте, как удаленный компьютер обрабатывает DNS. Скорее всего, проблема именно в этом.