VirtualBox - гостевая Ubuntu теряет DNS, когда хост подключается к VPN

У меня есть гостевая ОС Ubuntu в VirtualBox с использованием NAT по умолчанию для eth0.

Хорошо работает в офисе и дома, за исключением случаев, когда в офисе VPN из дома.

Когда хост-ОС (Windows 7) подключена к VPN, поиск DNS не работает в гостевой системе Virtualbox. DNS-запросы в порядке на хосте. В Virtualbox я могу пинговать IP-адреса напрямую как внутри VPN, так и снаружи, так что это не проблема подключения.

Похоже, что гость Ubuntu использует localhost в качестве точки входа DNS, в соответствии с /etc/resolv.conf а также nslookup, Таким образом, похоже, что что-то локально отправляется в другой базовый DNS.

Как мне устранить это?

Источник

2 ответа

Решение

По какой-то причине это сработало

C:\...\VirtualBox\VBoxManage modifyvm "VM name" --natdnshostresolver1 on

Я подозреваю, что это потому, что когда VPN активен, хост делает что-то особенное для поиска DNS, помимо простой пересылки запросов на указанные DNS-серверы, которые VirtualBox обнаружил из конфигурации Windows.

Источник

TL;DR:

  • перезагрузите виртуальную машину, убедившись, что статус VPN (подключен или отключен) хоста за это время не изменится;
  • пусть механизм NAT VirtualBox перехватывает DNS-запросы и перенаправляет их преобразователю хоста, то есть использует DNS API хоста для запроса информации и возврата ее гостю. Вы устанавливаете это:

VBoxManage modifyvm "VM name" --natdnshostresolver1 on

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

  1. виртуальная машина создается на хосте, подключенном к VPN, и в определенный момент VPN отключается;
  2. виртуальная машина создается на хосте, не подключенном к VPN, и в определенный момент VPN подключается

1)VPN-подключен -> VPN-отключен

В этом случае виртуальная машина, вероятно, получит DNS-адрес, который является частью сети поставщика VPN. Обычно это внутренний частный IP-адрес. Проверить содержание cat /etc/resolv.conf. В моем случае я получаю следующее:

nameserver 10.8.8.1 <--- Это внутреннее по отношению к сети поставщика VPN

nameserver 192.168.178.1 <--- Это мой домашний шлюз (роутер)

Теперь отключите хост от VPN-соединения:

  • конфигурация DNS на виртуальных машинах не меняется -> виртуальная машина по-прежнему будет отправлять DNS-запросы на IP-адрес назначения 10.8.8.1, который не может быть достигнут, поскольку хост больше не подключен к VPN

Более подробно:

  • пакет будет отправлен на def GW, определенный сетью VirtualBox NAT, исходный NATTed (с IP-адресом хоста) и, наконец, обработан таблицей маршрутизации хоста, которая перенаправит его на ваш домашний шлюз.
  • Здесь пакет будет отброшен, так как ваш домашний шлюз не имеет записи для 10.8.8.1 на стороне LAN (частные адреса) и не может пересылать его на стороне WAN (публичные адреса), поскольку это частный адрес.

2)VPN-отключен -> VPN-подключен

В этом случае виртуальная машина не получит DNS-адрес, который является частью поставщика сети VPN, поскольку хост не был подключен к VPN при запуске виртуальной машины. Проверить содержание cat /etc/resolv.conf. В моем случае я получаю следующее:

nameserver 192.168.178.1 <--- Это мой домашний шлюз (роутер)

Теперь подключите хост к VPN-соединению:

  • конфигурация DNS на виртуальных машинах не меняется -> виртуальная машина по-прежнему будет отправлять DNS-запросы на IP-адрес назначения 192.168.178.1, который не может быть достигнут (пинг до него все еще работает), поскольку теперь DNS-запрос от виртуальной машины обрабатывается интерфейс VPN Tap, который будет пересылать пакеты в сеть VPN, где 192.168.178.1 (IP-адрес вашего внутреннего домашнего шлюза) недоступен.

Более подробно:

  • пакет будет отправлен на def GW, определенный сетью VirtualBox NAT, отправлен на интерфейс VPN Tap, который изменит IP-заголовок, заменив IP-адрес источника виртуальной машины IP-адресом, назначенным хосту сетью VPN, а пункт назначения адрес остается адресом DNS 192.168.178.1.
  • затем этот пакет будет инкапсулирован во внешний IP-заголовок, который будет иметь IP-адрес хоста в качестве источника (этот, кстати, позже будет заменен исходным NAT на домашнем шлюзе) и VPN-сервер в качестве адреса назначения.
  • когда пакет достигает сети VPN, он декапсулируется. IP-адрес назначения теперь снова является DNS-адресом 192.168.178.1, который сеть поставщика VPN не имеет возможности достичь (если только это не исключительный случай, когда это точно такой же IP-адрес, который используется вашим поставщиком сети VPN для своего DNS-сервера).
Источник

У меня была очень похожая ситуация с Lubuntu 16.04 (должна быть идентична в других Ubuntus), но это исправление не улучшило ситуацию. По крайней мере, с 16.04 проблема заключается в том, что NetworkManager использует локальный DNS-прокси (dnsmasq), и это плохо работает с VPN-соединениями, по крайней мере, в конфигурации по умолчанию.

Комментирование / удаление dns=dnsmasq в /etc/NetworkManager/NetworkManager.conf

[main]
plugins=ifupdown,keyfile,ofono
# dns=dnsmasq

Вероятно, есть способ настроить dnsmasq, но это дает (мне) эквивалентный доступ к хосту (dns и т. Д.), Поэтому я не исследовал. YMMV.

Источник
Другие вопросы по тегам