Во время установки kali linux обнаружена ошибка аппаратной виртуализации

Утечка DNS происходит, когда система, использующая VPN-подключение, делает DNS-запрос с использованием DNS-серверов локального поставщика услуг Интернета вместо передачи DNS-запроса через VPN-туннель на DNS-сервер VPN-провайдера (или к любому другому DNS-серверу. сервер по вашему выбору ).

Если вы просто отбрасываете исходящие DNS-запросы на ваши не -сетевые интерфейсы VPN, ваш доступ к сети с использованием имен хостов может стать неудобно медленным (, так как необходимые DNS-запросы перед каждым новым подключением должны будут истечь по тайм-ауту перед альтернативным DNS-сервер, предположительно настроенный VPN, пробуется )или полностью останавливается (, если ваш локальный преобразователь DNS не получил новые DNS-серверы от VPN-клиента и продолжает повторять попытки только заблокированных вами серверов интернет-провайдера ). ].

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

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

Чтобы узнать, где искать, сначала запустите grep hosts /etc/nsswitch.confи посмотрите на результат. Он будет иметь формат:

hosts:  <some keywords>

Это определяет механизмы, используемые для разрешения имен хостов.

Вместо <some keywords>должно быть как минимум files(, относящееся к/etc/hosts)и либо dns, либо resolve. Могут быть и другие ключевые слова.

dnsозначает стандартную библиотеку преобразователя DNS glibc, которая будет искать конфигурацию в /etc/resolv.conf. В системах, связанных с Debian -(, включая *Ubuntu, Mint и т.п. ), этот файл конфигурации часто управляется инструментом resolvconfвместо непосредственного внесения изменений в /etc/resolv.conf. Инструмент resolvconfотслеживает настройки DNS, связанные с каждым сетевым интерфейсом, как для создания общего /etc/resolv.confв соответствии с настраиваемыми приоритетами сетевых интерфейсов, так и для обеспечения восстановления соответствующих настроек DNS при отключении сетевого интерфейса.

Если в вашей системе используется resolvconf, прочтите man 5 interface-order, а затем проверьте файл конфигурации /etc/resolvconf/interface-order, чтобы убедиться, что ваш VPN-интерфейс будет иметь более высокий приоритет, чем физический интерфейс, поверх которого работает VPN-подключение.

resolveозначает, что используется новый systemd-resolved; запустите resolvectl status, чтобы увидеть его конфигурацию. Обычно это означает, что /etc/resolv.confбудет содержать только строку nameserver 127.0.0.53, перенаправляя любые DNS-запросы, выполненные с использованием старого преобразователя glibc, обратно в systemd-resolved.

Если VPN-клиент не знает о существовании инструмента resolvconfили механизма systemd-resolvedпри использовании одного или обоих из них, результатом будет беспорядок. К сожалению, вам нужно убедиться, что ваш сервис openvpn полностью интегрируется с этими инструментами, если они используются в вашей системе.

Также возможно, что демон NetworkManagerиспользуется для общего управления сетевыми интерфейсами. Этот демон может использовать resolvconfи/или systemd-resolvedили просто обновлять /etc/resolv.confнапрямую, если эти другие компоненты не используются в вашей системе.

Не зная названия и версии вашего дистрибутива Linux и вашей текущей конфигурации, будет сложно дать какой-либо совет.

Если вы хотите получить лучший ответ, отредактируйте свой вопрос, включив в него как можно больше следующей информации:

• Название и версия вашего дистрибутива Linux?
• NetworkManager или нет?
• что говорит строка hosts:в вашем /etc/nsswitch.conf?
• Интегрирована ли ваша служба OpenVPN с NetworkManagerи/или resolvconfили она будет редактировать /etc/resolv.confнапрямую?