Я использую MacBook с Mac OS X 10.8.2 и подключаюсь к сети моей компании через VPN. Все отлично работает при установлении VPN-подключения через локальную сеть или WLAN. Однако при использовании коммутируемого соединения (Huawei HSDPA USB Stick) имена хостов не разрешаются правильно в приложениях (например, в веб-браузере). Инструменты командной строки, такие как host name
, правильно разрешат IP-адрес, ping name
не разрешат.
Используя scutil --dns
я сбросил настройки DNS при подключении через WLAN против коммутируемого доступа. Есть заметная разница в порядке поиска:
connecting using WLAN:
resolver #1
nameserver[0] : 192.168.80.10
nameserver[1] : 192.168.80.24
if_index : 6 (ppp0)
reach : Reachable,Transient Connection
order : 100000
resolver #2
nameserver[0] : 192.168.80.10
nameserver[1] : 192.168.80.24
if_index : 6 (ppp0)
reach : Reachable,Transient Connection
order : 200000
resolver #3
domain : local
options : mdns
timeout : 5
order : 300000
resolver #4
domain : 254.169.in-addr.arpa
options : mdns
timeout : 5
order : 300200
resolver #5
domain : 8.e.f.ip6.arpa
options : mdns
timeout : 5
order : 300400
resolver #6
domain : 9.e.f.ip6.arpa
options : mdns
timeout : 5
order : 300600
resolver #7
domain : a.e.f.ip6.arpa
options : mdns
timeout : 5
order : 300800
resolver #8
domain : b.e.f.ip6.arpa
options : mdns
timeout : 5
order : 301000
DNS configuration (for scoped queries)
resolver #1
nameserver[0] : 192.168.1.1
if_index : 4 (en0)
flags : Scoped
reach : Reachable,Directly Reachable Address
resolver #2
nameserver[0] : 192.168.80.10
nameserver[1] : 192.168.80.24
if_index : 6 (ppp0)
flags : Scoped
reach : Reachable,Transient Connection
Соединение ppp0 является VPN-соединением. Как видите, два сервера подключены, и они правильно отвечают в командной строке и в приложениях.
Connecting via UMTS:
resolver #1
nameserver[0] : 139.7.30.126
nameserver[1] : 139.7.30.125
if_index : 6 (ppp0)
reach : Reachable,Transient Connection
order : 100000
resolver #2
nameserver[0] : 192.168.80.10
nameserver[1] : 192.168.80.24
if_index : 7 (ppp1)
reach : Reachable,Transient Connection
order : 100000
resolver #3
nameserver[0] : 192.168.80.10
nameserver[1] : 192.168.80.24
if_index : 7 (ppp1)
reach : Reachable,Transient Connection
order : 200000
resolver #4
domain : local
options : mdns
timeout : 5
order : 300000
resolver #5
domain : 254.169.in-addr.arpa
options : mdns
timeout : 5
order : 300200
resolver #6
domain : 8.e.f.ip6.arpa
options : mdns
timeout : 5
order : 300400
resolver #7
domain : 9.e.f.ip6.arpa
options : mdns
timeout : 5
order : 300600
resolver #8
domain : a.e.f.ip6.arpa
options : mdns
timeout : 5
order : 300800
resolver #9
domain : b.e.f.ip6.arpa
options : mdns
timeout : 5
order : 301000
DNS configuration (for scoped queries)
resolver #1
nameserver[0] : 192.168.80.10
nameserver[1] : 192.168.80.24
if_index : 7 (ppp1)
flags : Scoped
reach : Reachable,Transient Connection
resolver #2
nameserver[0] : 139.7.30.126
nameserver[1] : 139.7.30.125
if_index : 6 (ppp0)
flags : Scoped
reach : Reachable,Transient Connection
На этот раз ppp1 - это соединение VPN, а ppp0 - это соединение UMTS. Из времени ответа команд (используя несуществующее имя хоста foo.bar.local
) я делаю вывод, что ping
используется первая цепочка распознавателя, где as host
используется конфигурация запроса с областью действия. ping
требуется 5 секунд, чтобы вернуть «Неизвестный хост», host
возвращается немедленно. Я предполагаю, что ping работает в течение 5 секунд тайм-аута решателя mdns.
Чтобы исправить мою проблему со сломанным поиском DNS при наборе номера через VPN через модем, мне нужно изменить порядок распознавателей. До сих пор я не нашел способ сделать это.
Любые идеи приветствуются.
Я нашел обходной путь: ваш VPN DNS будет по-прежнему игнорироваться, и будет использоваться только DNS-ключ 3G, но простое добавление вашего VPN DNS в список в интерфейсе 3G делает свое дело ... Основная проблема заключается в том, что менеджер 3G-соединений перезаписывает конфигурацию каждый раз Вы нажимаете кнопку «Подключиться», и вам нужен диспетчер подключений, чтобы включить радио на ключе 3G… поэтому я совместил оба решения в одном:
Подключитесь к VPN и запишите свой DNS (у меня 2 в списке). Вы можете проверить это в Предпочтения сети → Дополнительно → вкладка DNS. Отключи VPN. Вам нужно подключиться к VPN, потому что DNS назначается динамически при подключении…
Подключитесь к своему 3G и сделайте то же самое: напишите DNS на бумаге. Затем отключите 3G.
Перейдите в «Настройки сети» → нажмите «Интерфейс 3G» → «Дополнительно» → «Вкладка DNS», а в разделе «Таблица DNS» (которая обычно будет пустой, поскольку вы не подключены), нажмите «+». Добавьте все DNS-серверы (сначала из 3G, а затем добавьте VPN). Нажмите ОК и Применить.
С этого момента, чтобы подключиться к 3G, просто подключите USB и подождите, пока у вас не будет покрытия 3G (вам нужно будет открыть диспетчер подключений 3G), но не используйте прилагаемый диспетчер подключений для подключения. И если он автоматически подключается, перейдите в настройки и снимите этот флажок. Этот менеджер нужен только для включения радио на USB-ключе, ничего больше.
Если вы нажмете «подключиться» в вашем 3G-менеджере, он перезапишет конфигурацию вашего 3G-интерфейса, и вам нужно будет повторить шаг 3 снова.
Перейдите в Сеть → Настройки и нажмите на интерфейс 3G. Затем нажмите подключиться. Он подключится к вашему 3G через настроенные DNS-серверы (вместо динамически получаемых), которые включают в себя как «общедоступный» DNS, так и VPN-DNS.
Подключитесь к вашему VPN. Это будет работать как ожидалось.
Просто знайте, что:
Если ваш VPN DNS меняется, вам нужно изменить его вручную. Это легко проверить в разделе «Сеть» → «Интерфейс VPN» w «Дополнительно» → вкладка «DNS», поскольку DNS VPN по-прежнему динамически назначается интерфейсу (хотя в OS X это игнорируется).
Если ваш 3G DNS-сервер изменится (маловероятно), вам также придется изменить его вручную. Если что-то идет не так, и вы не можете ориентироваться, вам нужно пройти через свой менеджер 3G-соединений, нажмите «Подключиться» и посмотрите, какие DNS-серверы назначаются динамически… Для этого вам потребуется вернуться к шагу 3 и перенастроить его.
источник
У меня была такая же проблема долгое время, но теперь у меня было время найти решение, которое работает для меня. Я не изменил порядок DNS-сервера, но я постоянно использую DNS-сервер за VPN.
Подключайтесь через модем.
Подключите VPN-подключение и скопируйте IP-адреса DNS-сервера и домен поиска из VPN-подключения → Дополнительно → DNS.
Отключите соединение VPN.
Пинг
<name>
или<hostname>
вашего VPN сервера и запишите IP.Отключите модемное соединение.
Дублируйте подключение удаленного доступа (например, назовите его «3G для VPN»).
Введите IP-адреса и домен поиска на вкладке DNS коммутируемого соединения. Они будут храниться и использоваться постоянно.
Подключитесь через новое коммутируемое соединение.
Теперь у вас нет доступа к серверам имен (потому что они защищены VPN) - вам нужно отредактировать адрес сервера VPN-соединения. Замените хост на IP.
Подключитесь через VPN-соединение, и вы сможете его использовать.
Примечание. Обычно имена хостов не меняются, но IP-адреса могут. Так что, если он не работает когда-нибудь, сделайте шаги снова ...
источник
то, что вы сказали, подсказало мне, поэтому я добавил dns ip в соединении vpn в список днс в основном соединении (ничего особенного, просто используя графический интерфейс для сетевых настроек). Я не уверен, что вы имеем дело с другим, но у меня это сработало.
источник
Это все еще происходит в 10.13.0
Я открыл отчет об ошибках с Apple. Это не нормально, что «ping internalhostname» работает, но «hosthosthostname» или «nslookup internalhostname» терпит неудачу с VPN с разделенным туннелем (на основе Cisco IPSec или IKEv2).
Кроме того, как некоторые заметили, соединения Cisco IPsec, а также соединения IKEv2 не могут иметь приоритета с «Установить порядок обслуживания» в отличие от L2TP / IPsec, который может.
Еще одно замечание, которое я хотел бы затронуть, это то, что VPN с раздельным туннелем Cisco IPSec или IKEv2 не показывают DNS-серверы или домены поиска в своих расширенных настройках, даже если эта информация отображается с помощью «scutil --dns». L2TP / IPsec VPN действительно показывает эту информацию просто отлично.
Что-то должно дать, и Apple должна предоставить какое-то объяснение / исправить.
источник
scutil --dns
выше команды, и кажется, что DNS из VPN всегда последний и не используется для поискового домена, даже если он настроен правильно.Не работает в Lion / Mountain Lion из-за ошибки, из-за которой локальный DNS-сервер всегда используется вместо DNS-сервера удаленной сети, даже если в VPN-маршрутизаторе правильно настроен Split DNS.
Однако, если вы используете маршрутизатор Cisco ASA IPSEC, вы можете принудительно использовать удаленные DNS-серверы всякий раз, когда вы устанавливаете VPN-соединение:
При использовании Cisco ASDM выберите Конфигурация> Доступ к сети (клиенту)> Групповые политики> (ваша группа vpn для OSX / iPhone)> Дополнительно> Разделенное туннелирование
Там установите: DNS-имена (снимите флажок «наследовать» и определите внутренние доменные имена DNS, например, myoffice.local). Отправьте все DNS-запросы через туннель Throug: установите в YES (это важный параметр)
Сохраните его и не забудьте сохранить во флэш-памяти для дальнейшего использования.
Если вы используете командную строку IOS, установите:
источник
Это можно исправить, изменив порядок обслуживания сетевых подключений. Переместите VPN в верхнюю часть списка, и порядок разрешения будет следовать.
http://support.apple.com/kb/PH14006
источник