У нас есть клиенты Windows XP SP2, на которых работает клиент Cisco VPN 3000 (3030) при беспроводных подключениях. При отключении от VPN клиенты получают свои DNS-серверы от DHCP (они определенно не настраиваются статически). В некоторых случаях клиенты продолжают попытки поговорить с этим DNS-сервером даже после того, как они подключились к VPN, даже если VPN-концентратор выдает другие адреса DNS-серверов.
Кто-нибудь это видел?
Спасибо
Я считаю, что это связано с порядком подключения сетевых адаптеров на ваших машинах XP. Ваше беспроводное соединение имеет более высокий приоритет, чем ваше VPN-соединение, и использует настроенные там DNS-серверы, прежде чем использовать DNS-серверы, настроенные в вашем VPN-соединении. Чтобы проверить это:
1) откройте окно сетевых подключений
2) Перейдите в Расширенное меню, Расширенные настройки ...
3) В верхней части этого окна перечислены ваши сетевые подключения в порядке доступа. Поместите свое VPN-соединение в начало списка, и они должны начать использовать правильные DNS-серверы, пока они находятся в VPN.
Возможно, что настройки вашего DNS-сервера, которые выдает ваш концентратор VPN, не охвачены разделенными туннельными сетями, о которых упоминает GregD. Если ваша область VPN DHCP выдает DNS-серверы, а они НЕ покрываются разделенными туннельными сетями, клиент попытается связаться с DNS-серверами через свой шлюз по умолчанию, который будет локальным маршрутизатором, к которому они подключены.
Я должен не согласиться с утверждением, что полная VPN более безопасна - вы действительно не хотите, чтобы ваш трафик просмотра веб-страниц маршрутизировался через корпоративную WAN через VPN, особенно если клиент не управляется компанией, и вы не имеете никакого контроля через AV, исправление и т. д. - вы можете передавать в свою корпоративную сеть всевозможные плохие вещи.
Я не видел этого конкретно, но пробовали ли вы команду ipconfig /flushdns ... если да, то решает ли она проблему, даже временно?
Обычно для этого есть только одна причина: вы используете раздельное туннелирование, а не полное туннелирование. В первом случае вы разрешаете им доступ к локальной сети или Интернету, а также предоставляете им доступ к VPN, две интерфейсные карты будут отображаться в ipconfig.
При полном туннелировании весь трафик должен проходить через VPN-туннель, что с точки зрения безопасности является наиболее желательной настройкой.
Один из обходных путей, который может подойти пользователям, которые в основном не работают в корпоративной сети, - это включить вход через VPN перед входом в Windows в параметрах клиента Cisco VPN. Это должно помочь сохранить домашние диски и разрешить сценарии входа в систему. Конечно, это больше раздражает пользователей, которые в основном входят в систему в офисе.
Еще одно предложение, которое я слышал, заключается в том, что конкретное приложение может кэшировать свои попытки разрешения имен даже после того, как вы очистили кеш преобразователя DNS, так что открытое окно проводника может полагать, что serverx недоступен, пока вы не перезапустите проводник, хотя я не был смог подтвердить это.
Я столкнулся с этой проблемой, устранять неполадки неприятно, потому что пользователи по определению находятся вне офиса, когда они сталкиваются с этим. Другой фактор, который усложняет конфигурацию раздельного туннеля, заключается в том, что если ваш внутренний домен - company.com, у вас вполне может быть внешний общедоступный DNS для www.company.com и т. Д. - когда ваш пользователь пытается разрешить внутренний fileserver.company.com, они Я получу достоверный ответ от внешнего DNS о том, что "файлового сервера" не существует.