OpenVPN DNSLeak prevention (боремся с утечкой DNS)

Даже несмотря на то, что сервер OpenVPN пушит клиенту список DNS серверов для использования, клиент OpenVPN все равно может пытаться использовать DNS провайдера (или другие, заданные в системе).

Для минимизации риска использования не тех DNS, которые задаются сервером OpenVPN, в конфиг клиента добавляют опцию:

Можете проверить сначала до включения опции — откройте https://dnsleaktest.com. Высока вероятность того, что вы все еще используете DNS вашего провайдера.

Теперь включите вышеуказанную опцию и перезапустите клиент. Вы должны увидеть разницу.

Для Windows 8 и 10

это не совсем так (а что вы хотели?). В этих ОС Microsoft заботится о своих неразумных пользователях, которые, очевидно, не желают использовать именно те настройки, которые они настроили 🙂 А именно, Windows 8 и 10 рассылают dns-запросы по всем возможным интерфейсам в системе и используют самый быстрый ответ, в результате чего вероятность незапланированного использования dns вашего провайдера вместо dns openvpn-сервера весьма высока. Этот момент описан здесь (автор ValdikSS).

Отследить проблему (и возможные варианты решения) можно согласно инструкции так:

Определяем интересующий нас подключенный интерфейс (в данном примере по-английски, на момент написания русской версии не было):

> netsh interface show interface

Очищаем кеш резолвера dns:

Запрещаем dns сервер на этом интерфейсе:

> netsh interface IPv4 set dnsserver «Local Area Connection» static 0.0.0.0 both

Проверяем (например, на https://dnsleaktest.com).

После отсоединения возвращаем настройки dns обратно:

> netsh interface IPv4 set dnsserver «Local Area Connection» dhcp

Снова чистим кеш резолвера:

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

Как вы понимаете, аналогичные проблемы могут быть и при использовании VPN других вендоров. Просто на это можно обращать внимание. А можно и не обращать 🙂

How can I fix a DNS leak?

The solution is to ensure that once connected to the VPN, you are using ONLY the DNS server/s provided by the VPN service.

OpenVPN v2.3.9+

As of OpenVPN version 2.3.9 you can now prevent DNS leaks by specifying a new OpenVPN option. Simply open the .conf (or .ovpn) file for the server that you are connecting to and add the following on a new line. For more information see the OpenVPN manual.

If for any reason you are unable to use the solution above continue reading.

If you are using a version of OpenVPN older than v2.3.9

Please note that as this problem normally only affects windows clients, only solutions for Windows appear here.

3 basic steps to fix the problem;

1. Before connecting to the VPN, set static IP address properties if you are using DHCP
2. After connecting, remove DNS settings for the primary interface
3. After disconnecting, switch back to DHCP if neccessary or reapply original static DNS servers

Solution A — Automatic

If you are using OpenVPN on Windows XP/Vista/7 then a fully automated solution is available.

Download dnsfixsetup.exe — (md5 checksum: f212a015a890bd2dae67bc8f8aa8bfd9)

After installation, when you connect to a VPN server, a batch file will be run executing the 3 steps above.

Three scripts are generated for each OpenVPN configuration file;

1. configfilename_pre.bat — executed when you initiate the connection but before the connection is established — Calls pre.vbs — If any active DHCP adapters exist, switch to static
2. configfilename_up.bat — executed when the connection is established — Calls up.vbs — Clear the DNS servers for all active adapter except the TAP32 adapter
3. configfilename_down.bat — executed after the connection is disconnected — Calls down.vbs — Reconfigure adapters back to their original configuration

Solution B — Manually clearing the DNS

The solution below does not switch the adapter to static if you are using DHCP. If you do not switch to a static IP configuration and your computer renews its IP address whilst connected to the VPN, the DNS settings may be overwritten. It is highly recommended to switch to a static IP configuration.

1. Open the command prompt (cmd.exe) as an administrator.
2. Before connecting identify the name of the connected network interface. In the case below it is «Local Area Connection» netsh interface show interface
3. Connect to the VPN. Once connected proceed to the next step.
4. Flush the DNS resolver cache ipconfig /flushdns
5. Disable the DNS configuration for the Interface identified in step 1 netsh interface IPv4 set dnsserver «Local Area Connection» static 0.0.0.0 both
6. Test for DNS leaks.
7. After disconnecting, reconfigure the adapter to renew the previous DNS settings netsh interface IPv4 set dnsserver «Local Area Connection» dhcp
8. Once again, flush the DNS resolver cache. ipconfig /flushdns
9. Done.

Как защититься от DnsLeak на openvpn?

Всем бодрого духа!

Господа, есть идеи, как защититься от dnsleak при соединении с openvpn?
https://dnsleaktest.com/what-is-a-dns-leak.html

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

OpenVPN умеет запускать скрипты в момент установки соединения. Теоретически, можно попробовать написать скрипт который будет менять таблицу маршрутизации. И при завершении соединения воротать всё взад.
Однако.. а если соединение разорвётся само? Или хост выключится? Или просто гдето прав не хватит или ещё что.

Есть вменяемый метод?

Укажите днс сервер в конфиге сервера и будет счастье.

Однако.. а если соединение разорвётся само? Или хост выключится? Или просто гдето прав не хватит или ещё что.

Поднять на хосте свой DNS-сервер и вертеть там форварды как тебе вздумается

Поднять на хосте свой DNS-сервер и вертеть там форварды как тебе вздумается

Этот мудрый человек прав. Решение универсальное, но требует понимания и настройки.

anc, спасибо за ответ.
Эдак нужно несколько DNS серверов прописать, чтобы заменить все клиентские настройки по DNS серверам, я правильно понимаю?
push «dhcp-option DNS 8.8.8.8 8.8.8.4» или как?

Pinkbyte, Jameson,
ну что вы говорите, это же клиентский хост..

ну что вы говорите, это же клиентский хост..

И что? Никаких религиозных запретов держать на хосте запущенным кеширующий bind с прописанными forward к разным DNS серверам для разных сетей нет, только неумение настоить. Я, например, люблю когда за разрешением интернет адресов bind напрямую к корневым серверам ходит, а forwardы на провайдерский и локальный DNS отвечают за внутрипрововские и локальные ресурсы. При поднятии тоннеля в разные локалки forward к DNS этой локалки добавляется к конфигурации bind автоматически. При поднятии vpn c default route bind делает свои запросы к корневым серверам через этот vpn, и ничего не течёт.

Соответственно у меня в resolv.conf всегда 127.0.0.1, всё остальное разруливает bind.

ну что вы говорите, это же клиентский хост..

У меня на работе на рабочей станции стоит DNS-сервер — обслуживает только 127.0.0.1 и не является авторитетным ни для одной из зон — только форвардит запросы как мне надо на другие DNS-сервера.

Это единственный способ нормально заставить DNS работать например с парой VPN-ов, за которыми свои DNS-зоны.

Предлагаю перестать думать в категориях рабочих станций. Любой настольный Линукс от сервера отличается мелочами и настройками преимущественно. Мысли ширше, как сетевой админ. Например во времена сильно платного исчерпаемого трафика мне был актуален локальный Squid. Ибо кеши у браузеров есть конечно, но браузеров несколько, не считая тех что внутри виртуалок. А тут настроил их всех на локальный прокси и у всех браузеров можно собственный кеш в 0 выставлять.

Это единственный способ нормально заставить DNS работать например с парой VPN-ов, за которыми свои DNS-зоны.

А это собственно и есть основной смысл использования VPN (virtual PRIVATE network). Сценарий, при котором туннель используется для смены точки выхода в интернет не основной, поэтому на нём косяки типа DNS leak и вылезают.

А вообще, правильный VPN провайдер должен снабдить тебя своим DNS, а правильный дистрибутив запихать его в resolv.conf. Если нет, правильный пользователь рабочей станции прописывает в настройках NetworkManager для этого соединения DNS 8.8.8.8 руками, после чего правильный дистрибутив запихивает это опять таки в resolv.conf. После опускания тоннеля всё должено возвращаться назад.

OpenVPN умеет DNSSec.

А ещё мне вспомнился эпичный баг Networknanager https://bugs.archlinux.org/task/47535 , к счастью быстро пофикшенный. Суть в том, что vpn соединение устанавливалось, но default route не менялся, при этом никаких ошибок никуда кроме лога не писалось. В результате юзер пребывал в полной уверенности что он уже работает через vpn, но про факту продолжал светить трафик провайдеру. И формально нёс ответственность, так как софтина ему честно в лог сказала, «тоннель — смогла, маршрут — нет», но ктож эти логи читает? Тоннель взлетел? Взлетел. ЗначОк есть? Есть. Значит всё в поряде 🙂

Эдак нужно несколько DNS серверов прописать, чтобы заменить все клиентские настройки по DNS серверам, я правильно понимаю?

Не распарсил формулировку «чтобы заменить все клиентские настройки»

Господа, я рекомендуя вам вылезти чуть дальше своего сервера на локалхосте (в данном случае это про то что вы писали, а не намек на «админ локалхоста»). Случаев когда нужна именно раздача днс очень много и DNS leak не так уж и смешно как может показаться. А вот пользователям (именно пользователям) раздавать кроме ключей, паролей и т.д. еще и мануалы с инструкциями (под разные ОС) как настроить у себя днс сервер это все-таки перебор.

Уже написали же — запушить юзеру настройки DNS и всё, OpenVPN клиент сам всё пропишет, где надо.

Эммм. это вообще я был 🙂

Господа, видимо, не поняли сути проблемы ввиду моего не совсем ясного изложения.
Юзеры (то биш, виндовс десктопы) массово коннектятся к openvpn серверу. Я пытаюсь понять их защитить от DNSleak.

Чё-то я протормозил.
у меня и так стоит
push «dhcp-option DNS 8.8.8.8»
push «dhcp-option DNS 8.8.4.4»

и от утечки dns это не помогает.

Хм, как определили? В конфиге клиента не запрещено случайно?

Не думаю, что на клиенте что-то запрещено.
вот конфиг клиента:

т.е. вроде как просасываются настройки.

Определили так
https://www.dnsleaktest.com/
Даже быстрый standard test запалил местонахождение.

Походу винда новая, у меня старше семерки нигде нэма, там все работает норм. Вот что в инете есть http://habrahabr.ru/post/268173/
btw судя по нику, автор и здесь присутствует, ValdikSS Ваше творение?

Не понял вопрос(реплику?) про ник, но на всякий случай скажу, что на хабре не зареген, и на этом форуме у меня только один ник.

На винде пока не проверял, проверю вечером, напишу.
Ситуация такая: настраиваю openvpn-сервер на дебиане, хочу обезопаситься от dns leak.
Клиенты предполагается что будут на всех осях и девайсах.
Сам сижу на линукс минте, на нём проверяю.

Так может тебе надо пушить внутренний ip впн сервера, а не гугла?
Тебе об этом в первом же комментарии написали.

Не понял вопрос(реплику?) про ник, но на всякий случай скажу, что на хабре не зареген, и на этом форуме у меня только один ник.

Я написал что ValdikSS есть и здесь на лоре и предполагаю что судя по нику это один и тот же человек.

Клиенты предполагается что будут на всех осях и девайсах.

Да не должно быть проблем, собстно и на винде не было, да вот оказалось, что очередное поделие опять выпендрилось.

Piter_prbg , для начала определитесь, так ли важно для вас защищаться от DNS Leak. На Linux getaddrinfo будет пытаться резолвить хостнейм через следующий (не первый) nameserver только в том случае, если первый не ответил по таймауту. Т.е., в обычном случае, такое случается довольно редко (проблемы с сетью), но, конечно, если сеть контролируется злоумышленником (Wi-Fi хакера, к которой вы подключились), то он сможет произвольно устраивать вам DNS Leak (правда, для вас это будет выглядеть, как тормоза сети).

В Windows до 8 примерно такая же ситуация. Начиная с 8.1, Windows отправляет запросы на все ей известные DNS параллельно, байндясь к интерфейсу. Вот это уже плохо. Для устранения такого поведения можно использовать параметр

Про OS X ничего не могу сказать. На Android DNS Leak нет.

OpenVPN в Linux сам по себе не умеет устанавливать DNS. Если вы запускаете его из консоли, используйте up-скрипт update-resolv-conf (в Debian находится в /etc/openvpn/update-resolv-conf). NetworkManager умеет устанавливать DNS, но, насколько мне известно, в Ubuntu все еще имеется баг из-за использования dnsmasq, он там как-то странно устанавливается. Я рекомендую закомментировать строку: