Acrylic dns proxy настройка
Да вот так и есть и проблема в том, что уже давно есть ПО, которое тоже умеет параллельно слать запросы на несколько серверов для ускорения, да и вообще представляет из себя навороченный, пусть и ориентированный на кэширование DNS, но решение при этом полностью настраиваемое, т. е. оно шлёт запросы не абы куда, а только на те адреса, которые прописаны в конфиге. Называется Acrylic DNS Proxy.
Использовать странные dns сервера в организации вообще не есть гуд. А для домашнего пользователя 8.8.8.8 вполне нормально.
В win7 и меньше как раз было проблемой то, что отвечал только один DNS, и если например нужно обратиться к внутренним ресурсам, не публикующимся наружу, была проблема что внешний DNS не мог их резолвить, а внутренний DNS мог не резолвить что-то другое снаружи.
А если один из DNS отвечает что сервер не найден, к другому уже и не обращается — мне всегда казалось, что это неправильно.
Сейчас стало логичнее. Хотя было бы лучше поведение dns клиента при ошибках настраивать гибче.
Я тоже так думал и довольно долго им пользовался, но очень часто разные сайты были недоступны — я грешил на сами сайты, пока вдруг несколько раз я не смог попасть на сайт Гугла, в то время как у всех остальных сайт Гугла был доступен. Сменил DNS на провайдерский, и проблемы исчезли. Возможно, 8.8.8.8 и 8.8.4.4 просто не справлялись с нагрузкой, не знаю.
Было такое, то перестает отвечать днс провайдера, то днс гугла, фигня какая то. То ли провайдер специально блочит днс гугла, то ли что, не знаю. Перешел на днс от яндекс. Проблема исчезла.
Google где-то писал, что эти адреса не для внешнего использования, они не рассчитаны на какую-либо нагрузку. А один из открытых проектов (dnsmasq?) использует их по умолчанию, поэтому нагрузка на них всегда есть.
Вообще то нет.
Но фраза типа одна бабка сказало, это хорошо.
В конце концов wikipedia
Хотя, это еще тот источник знаний.
Моя статистика показывает, что DNS сервера домашних мелких провайдеров глючат горазо чаще, чем гугловский.
Кстати, не очень понял за что заминусовали. Я считаю, что если один DNS сервер вернул ошибку, это еще не повод, что сайта действительно нет, и во многих случаях я бы хотел больше управлять поведением днс клиентом.
Он собственно и в Линукс себя также ведет — второй ДНС сервер опрашивает только в том случае, если первый ДНС не отвечает.
В нескольких крупных компаниях (200+ тыс.человек), где необходимо разделать внутренние и внешние ресурсы, проблема ресолва парочки адресов решилась исключительно через hosts файл, что неудобно. А было бы можно настроить поведение при ошибке, можно было бы просто два DNS сервера разных указать.
Провайдеры могут подменять DNS, и подменяют. Не пользуйтесь DNS провайдеров — это, кажется, прописное.
Ну и если ваше оборудование автоматом цепляется за любой вайфай без пароля с dhcp… При таком уровне безопасности утечка dns не самая критичная уязвимость имо.
Так что в нормальной сети проблем не будет, кмк. А там где будут — там и без этого дыра на дыре.
Дело не в DNS провайдеров, и не в автоматическом подключении к сетям. Даже если вы дома на роутере настроили сторонние DNS, но этот же роутер поднимает кеширующий DNS (как это обычно бывает) на интерфейсе локальной сети, вы же не будете прописывать эти DNS еще и на компьютере, ведь от этого, во-первых, пострадает кеширование, да и вообще, какой смысл тогда настраивать на роутере, верно? И вы ожидаете, что все в порядке, подключаете VPN, и — бах — все ваши DNS-запросы идут не так, как вы ожидаете.
Та же ситуация с Wi-Fi в кафе. Подключаетесь к Wi-Fi, используя DNS, предоставленный по DHCP, сразу подключаетесь по VPN и надеетесь, что все в порядке, а на деле, все ваши DNS-запросы могут быть подменены злоумышленником.
Провайдеры могут подменять DNS, и подменяют. Не пользуйтесь DNS провайдеров — это, кажется, прописное.
На самом деле, всё ещё хуже. Они не только запросы к себе подменяют, но и к любым другим. У нас например, провайдер нагло изменяет все ДНС пакеты в которых упомянуты запрещённые имена. Даже 8.8.8.8 тут не поможет. (Зато через VPN всё как надо)
Вот Билайн так точно делает. Какое-то время назад столкнулся с проблемой, что 8.8.8.8 и тот же самый через VPN возвращают абсолютно разные данные.
И есть ли какое-нибудь решение? Сгодится и технический вариант (юзабелен ли сейчас DNSCrypt на Linux?), и юридический (выдать дружных люлей за модификацию трафика, хотя вряд ли получится).
А вообще провайдер должен быть трубой в пространство IP/IPv6. Всё остальное его не касается.
Убивая историю и возможность перехода назад? Плюс отлуп о подмене сертификата вместо более понятного разрыва соединения? Спасибо, не нужно.
Хотел сказать «поднимите локальный ресолвер и закройте iptables всем, кроме него доступ к dns», но понял, что не знаю как это всё называется в виндах.
Алсо, в линуксах есть resolv.conf и nsswitch.conf, управляющие порядком ресолвинга. В виндах аналогичного нет?
Ну так в windows можно указать несколько ДНС, проблема же в другом. Оно тут и описана, что винда кладет болт на это и делает по своему.
У меня стойкое ощущение, что это всё таки баг 10, а не фича и настройку для отключения либо потеряли, либо изменили, но нормально не задокументировали.
Алсо, в линуксах есть resolv.conf и nsswitch.conf, управляющие порядком ресолвинга. В виндах аналогичного нет?
nsswitch точно есть, и аналог resolv.conf через реестр можно сделать, но это все костыльно и неудобно, к сожалению.
Понятное дело, что локальный резолвер решает проблему, но нужно всегда помнить о необходимости убирать DNS на других интерфейсах, т.к. в Windows они привязаны к интерфейсам.
то есть для линукса можно настроить nsswitch что-то типа:
dns [NOTFOUND=continue] nis
и если первый dns сервер из resolv.conf не нашел домен, оно будет запрашивать остальные по очереди?
Насколько я знаю, как раз строго нет, от чего страдают всякие любители «альтернативных DNS через vpn», когда хочется, чтобы «не нашёл один — спроси у другого».
Вот у нас похожая проблема.
По vpn подключаемся к сети заказчика, внутри которой есть свой DNS, резолвящий эти внутренние ресурсы.
Но многие внешние ресурсы он не резолвит, и учитывая локацию заказчика сильно лагает. А если таких заказчиков со своими DNS-ами два, то уже совсем никак. Поэтому возможность опроса нескольких серверов удобно.
Единственное, что в статье действительно не описали что будет, если win10 делает запрос, и самый быстрый сервер отвечает отказом. Дождется ли оно ответа от других серверов, или сразу отлуп?
Нет. Если DNS не нашел запись, ломиться в nis. А DNS опрашиваются по очереди из resolv.conf. Если первый не ответил — идем ко второму. Но если первый сказал, что записи нет (именно ответил «фигвам», а не отвалился по таймауту), то дальше опрос не проводится.
ValdikSS правильно ли я понимаю, что на примере OpenVPN директива конфига:
push "redirect-gateway def1 bypass-dhcp"
тоже не решает проблему? И даже при добавлении принудительного:
push "route 0.0.0.0 0.0.0.0"
push "dhcp-option DNS xxx"
должен быть добавлен.
проблема останется? То есть верно ли я понимаю, что суть бага в том, что резольвер напрямую привязывает адреса DNS к интерфейсам, при этом полностью игнорирует правила маршрутизации?
Чья идея изначально — роутить только половину интернета? Вы вкурсе же, что 0.0.0.0/1 это не 0.0.0.0/0?
Почему половину-то? Добавляются два маршрута — 0.0.0.0/1 и 128.0.0.0/1, так что маршрутизируется весь интернет.
Ну да, но зачем два маршрута то добавлять? Я не про этот комментарий сейчас. Просто встречал много OpenVPN серверов и документаций где маршрут указывают 0.0.0.0/1, а потом страдают, что только половина работает.
Затем, что если в Windows добавить default route и удалить старый, то старый через какое-то время (во время следующего DHCP renew) опять появится, причем с метрикой ниже, и весь ваш трафик чудным образом пойдет не через VPN, а в обход. Больше причин, в общем-то, нет, наверное.
И где вы такую документацию встречали, кстати? Обычно нигде не пишут добавлять маршруты вручную, а используют redirect-gateway def1, который как раз добавляет два маршрута.
>> было проблематично для злоумышленника, т.к. ОС бы использовала подмененный ответ только в том случае, если не удалось получить правильный ответ от предпочитаемого DNS-сервера
Вот это раньше была безопасность т.е. стоит отвлечься основному DNS и на тебе дыра в безопасности. Если вы так беспокоитесь о безопасности, то у вас вообще не должны быть прописаны DNS, которым вы не доверяете.
>> не может ответить в отведенный ему таймаут (1 секунда по умолчанию)
2 секунды таймаут по умолчанию.
P.S. В групповых политиках настройка доступна здесь:
Computer Configuration -> Administrative Templates -> Network -> DNS Client -> Turn off smart multi-homed name resolution
If no response is received after 1 second, client queries the second DNS server of the list and at the same time queries again the first DNS server
Acrylic is a local DNS proxy for Windows which improves the performance of your computer by caching the responses coming from your DNS servers and helps you fight unwanted ads through a custom HOSTS file optimized for handling hundreds of thousands of domain names and with additional support for wildcards and regular expressions.
When you browse a web page a portion of its loading time is dedicated to name resolution (usually from a few milliseconds to 1 second or more) while the rest is dedicated to the transfer of the web page contents and resources to your browser. What Acrylic does is to reduce the time dedicated to name resolution for frequently visited addresses closest to zero possible. It may not seem such a great optimization but in a few weeks of Internet browsing you will probably save an hour or so, which is definitely not such a bad thing. Furthermore Acrylic's sliding expiration caching mechanism, simultaneous forwarding to multiple DNS servers and support for background DNS updates are able to improve your browsing experience independently of the browser.
With Acrylic you can also gracefully overcome downtimes of your DNS servers without disrupting your work, because in that case you will at least be able to connect to your favourite websites and to your email server.
Another good thing is that Acrylic is released as open source, which means that it's free and its source code, written with Borland Delphi, is freely available to anyone under the GNU General Public License.
How do I download Acrylic?
Version 2.1.0
Released on June 30, 2021
Step 3
Access the properties of your Internet connection (by right-clicking on it and selecting the Properties menu item).
Step 2
From the Network and Sharing Center click on the Change adapter settings item.
Step 1: Installation
- Launch the Acrylic.exe file and click on the "Next" button.
- Read and (if you like it) accept the license agreement by clicking on the "I Agree" button.
- Choose the installation folder (the default is "Program Files\Acrylic DNS Proxy") and click on the "Install" button.
Step 4
In the Networking tab access the properties of the Internet Protocol Version 4 (TCP/IPv4) item by selecting it and clicking on the Properties button.
7. Смотрим отчеты
Только сегодня написал первую версию программы по просмотру отчетов из БД — 3proxystat.
Пока можно строить отчеты на глубину «Все время», «1 час» и «за сегодня»
По типам отчетов:
«Как есть в логах» — RAW
и отчет по самым активным клиентам -Traffic by Clients
Если перед построение RAW отчета указать IP-адрес клиента в соответствующем текстовом поле, то RAW-статистика будет выбрана только по этому клиенту.
Под таблицей формируется сводная статистика по выборке.
Все отчеты можно экспортить в CSV совместимый с Excel (табуляция в качестве разделительного символа).
Под проект 3proxystat сделана отдельная страница /3proxystat Все обновления утилиты и инструкции будут там
Step 2: Configuration
Upon installation Acrylic is preconfigured to point to the Google Public DNS servers.
You can change that by selecting the "Open Acrylic Configuration" menu item of the Acrylic UI desktop application or by opening the AcrylicConfiguration.ini file with a text editor. You can also change the contents of Acrylic HOSTS file by selecting the "Open Acrylic Hosts" menu item of the Acrylic UI desktop application or by opening the AcrylicHosts.txt file with a text editor.
Be aware that in order to use Acrylic you need to configure your network interface so that the DNS servers to be contacted for name resolution are no more your ISP's but Acrylic. The details of how to do it depend on the version of your OS:
For more information about the syntax of the Acrylic HOSTS file have a look at the Hosts page.
4. Антивирус
Step 5
Select the Use the following DNS server addresses option and set the value of the Preferred DNS server field to 127.0.0.1. Then click on the OK button.
How do I uninstall Acrylic?
Just select the "Uninstall" Start menu item inside the "Acrylic DNS Proxy" folder.
The uninstall process will take care of stopping the service and deleting all traces of Acrylic from your computer.
1. Установка винды
How do I contact the author?
If you have questions please first have a look at the Frequently Asked Questions page.
If you have improvements to suggest, problems to report or whatever you can contact me at msmfbn [AT] gmail [DOT] com.
In order to use Acrylic you have to tell your computer that the DNS servers to be contacted for name resolution is no more your ISP's but Acrylic. How to do it for Windows 10 is explained in the steps below.
How do I upgrade Acrylic?
Since a specific upgrade path is not provided for Acrylic the best way to upgrade is simply to uninstall the old version and install the new one.
Before uninstalling the old version I suggest you to make a backup of your AcrylicConfiguration.ini and AcrylicHosts.txt files, because they will be deleted by the uninstall process.
Note: On Windows 10, while trying to install the new version, you might see a "The service has been marked for deletion" error. This usually happens when Process Explorer by Sysinternals, the Task Manager or the Microsoft Management Console are open while uninstalling the old version. In this case close all the aforementioned applications (which should trigger the removal of the service by the OS) and retry installing the new version again.
Step 7
Select the Use the following DNS server addresses option and set the value of the Preferred DNS server field to ::1. Then click on the OK button.
Шифрование трафика между вашим устройством и DNS-сервисом помешает посторонним лицам отслеживать трафик или подменить адрес
Смерть сетевого нейтралитета и ослабление правил для интернет-провайдеров по обработке сетевого трафика вызвали немало опасений по поводу конфиденциальности. У провайдеров (и других посторонних лиц, которые наблюдают за проходящим трафиком) уже давно есть инструмент, позволяющий легко отслеживать поведение людей в интернете: это их серверы доменных имен (DNS). Даже если они до сих пор не монетизировали эти данные (или не подменяли трафик), то наверняка скоро начнут.
«Открытые» DNS-сервисы позволяют обходить сервисы провайдеров ради конфиденциальности и безопасности, а кое в каких странах — уклоняться от фильтрации контента, слежки и цензуры. 1 апреля (не шутка) компания Cloudflare запустила свой новый, бесплатный и высокопроизводительный DNS-сервис, предназначенный для повышения конфиденциальности пользователей в интернете. Он также обещает полностью скрыть DNS-трафик от посторонних глаз, используя шифрование.
Названный по своему IP-адресу, сервис 1.1.1.1 — это результат партнёрства с исследовательской группой APNIC, Азиатско-Тихоокеанским сетевым информационным центром, одним из пяти региональных интернет-регистраторов. Хотя он также доступен как «открытый» обычный DNS-резолвер (и очень быстрый), но Cloudflare ещё поддерживает два протокола шифрования DNS.
Хотя и разработанный с некоторыми уникальными «плюшками» от Cloudflare, но 1.1.1.1 — никак не первый DNS-сервис с шифрованием. Успешно работают Quad9, OpenDNS от Cisco, сервис 8.8.8.8 от Google и множество более мелких сервисов с поддержкой различных схем полного шифрования DNS-запросов. Но шифрование не обязательно означает, что ваш трафик невидим: некоторые службы DNS с шифрованием всё равно записывают ваши запросы в лог для различных целей.
Cloudflare пообещал не журналировать DNS-трафик и нанял стороннюю фирму для аудита. Джефф Хастон из APNIC сообщил, что APNIC собирается использовать данные в исследовательских целях: диапазоны 1.0.0.0/24 и 1.1.1.0/24 изначально были сконфигурированы как адреса для «чёрного» трафика. Но APNIC не получит доступ к зашифрованному трафику DNS.
Для пользователей подключить DNS-шифрование не так просто, как изменить адрес в настройках сети. В настоящее время ни одна ОС напрямую не поддерживает шифрование DNS без дополнительного программного обеспечения. И не все сервисы одинаковы с точки зрения софта и производительности.
Как работает DNS
Есть много причин для лучшей защиты DNS-трафика. Хотя веб-трафик и другие коммуникации могут быть защищены криптографическими протоколами, такими как Transport Layer Security (TLS), но почти весь трафик DNS передаётся незашифрованным. Это означает, что ваш провайдер (или кто-то другой между вами и интернетом) может регистрировать посещаемые сайты даже при работе через сторонний DNS — и использовать эти данных в своих интересах, включая фильтрацию контента и сбор данных в рекламных целях.
Как выглядит типичный обмен данными между устройством и DNS-резолвером
«У нас есть проблема “последней мили” в DNS, — говорил Крикет Лю, главный архитектор DNS в компании Infoblox, которая занимается информационной безопасностью. — Большинство наших механизмов безопасности решают вопросы коммуникаций между серверами. Но есть проблема с суррогатами резолверов на различных операционных системах. В реальности мы не можем их защитить». Проблема особенно заметна в странах, где власти более враждебно относятся к интернету.
Наиболее очевидный способ уклонения от слежки — использование VPN. Но хотя VPN скрывают содержимое вашего трафика, для подключения к VPN может потребоваться запрос DNS. И в ходе VPN-сеанса запросы DNS тоже могут иногда направляться веб-браузерами или другим софтом за пределы VPN-тоннеля, создавая «утечки DNS», которые раскрывают посещённые сайты.
Однако эта опция защиты недоступна массовому пользователю. Ни один из этих протоколов нативно не поддерживается ни одним DNS-резолвером, который идёт в комплекте с ОС. Все они требуют установки (и, вероятно, компиляции) клиентского приложения, которое действует как локальный «сервер» DNS, ретранслируя запросы, сделанные браузерами и другими приложениями вверх по течению к безопасному провайдеру DNS по вашему выбору. И хотя две из трёх данных технологий предлагаются на роль стандартов, ни один из проверенных нами вариантов пока не представлен в окончательном виде.
Поэтому если хотите погрузиться в шифрование DNS, то лучше взять для DNS-сервера в домашней сети Raspberry Pi или другое отдельное устройство. Потому что вы наверняка обнаружите, что настройка одного из перечисленных клиентов — это уже достаточно хакерства, чтобы не захотеть повторять процесс заново. Проще запросить настройки DHCP по локальной сети — и указать всем компьютерам на одну успешную установку DNS-сервера. Я много раз повторял себе это во время тестирования, наблюдая падение одного за другим клиентов под Windows и погружение в спячку клиентов под MacOS.
Сообщество DNSCrypt пыталось сделать доступный инструмент для тех, кто не обладает навыками работы в командной строке, выпустив программы DNSCloak (слева) под iOS и Simple DNSCrypt (справа) под Windows
Для полноты картины в исторической перспективе начнём обзор с самой первой технологии шифрования DNS — DNSCrypt. Впервые представленный в 2008 году на BSD Unix, инструмент DNSCrypt изначально предназначался для защиты не от прослушки, а от DNS-спуфинга. Тем не менее, его можно использовать как часть системы обеспечения конфиденциальности — особенно в сочетании с DNS-сервером без логов. Как отметил разработчик DNSCrypt Фрэнк Денис, гораздо больше серверов поддерживают DNSCrypt, чем любой другой вид шифрования DNS.
«DNSCrypt — это немного больше, чем просто протокол, — говорит Фрэнк Денис. — Сейчас сообщество и активные проекты характеризуют его гораздо лучше, чем мой изначальный протокол, разработанный в выходные». Сообщество DNSCrypt создало простые в использовании клиенты, такие как Simple DNSCrypt для Windows и клиент для Apple iOS под названием DNS Cloak, что делает шифрование DNS доступнее для нетехнических людей. Другие активисты подняли независимую сеть приватных DNS-серверов на основе протокола, помогающего пользователям уклониться от использования корпоративных DNS-систем.
«DNSCrypt — это не подключение к серверам конкретной компании, — сказал Денис. — Мы призываем всех поднимать собственные сервера. Сделать это очень дёшево и легко. Теперь, когда у нас есть безопасные резолверы, я пытаюсь решить задачу фильтрации контента с учётом конфиденциальности».
Для тех, кто хочет запустить DNS-сервер с поддержкой DNSCrypt для всей своей сети, лучшим клиентом будет DNSCrypt Proxy 2. Старая версия DNSCrypt Proxy по-прежнему доступна как пакет для большинства основных дистрибутивов Linux, но лучше загрузить бинарник новой версии непосредственно с официального репозитория на GitHub. Есть версии для Windows, MacOS, BSD и Android.
Опыт сообщества DNSCrypt по защите конфиденциальности воплощён в DNSCrypt Proxy. Программа легко настраивается, поддерживает ограничения по времени доступа, шаблоны для доменов и чёрный список IP-адресов, журнал запросов и другие функции довольно мощного локального DNS-сервера. Но для начала работы достаточно самой базовой конфигурации. Есть пример файла конфигурации в формате TOML (Tom's Obvious Minimal Language, созданный соучредителем GitHub Томом Престоном-Вернером). Можете просто переименовать его перед запуском DNSCrypt Proxy — и он станет рабочим файлом конфигурации.
По умолчанию прокси-сервер использует открытый DNS-резолвер Quad9 для поиска и получения с GitHub курируемого списка открытых DNS-сервисов. Затем подключается к серверу с самым быстрым откликом. При необходимости можно изменить конфигурацию и выбрать конкретный сервис. Информация о серверах в списке кодируется как «штамп сервера». Он содержит IP-адрес поставщика, открытый ключ, информацию, поддерживает ли сервер DNSSEC, хранит ли провайдер логи и блокирует ли какие-нибудь домены. (Если не хотите зависеть от удалённого файла при установке, то можно запустить «калькулятор штампов» на JavaScript — и сгенерировать собственный локальный статичный список серверов в этом формате).
Для своего тестирования DNSCrypt я использовал OpenDNS от Cisco в качестве удалённого DNS-сервиса. При первых запросах производительность DNSCrypt оказалась немного хуже, чем у обычного DNS, но затем DNSCrypt Proxy кэширует результаты. Самые медленные запросы обрабатывались в районе 200 мс, в то время как средние — примерно за 30 мс. (У вас результаты могут отличаться в зависимости от провайдера, рекурсии при поиске домена и других факторов). В целом, я не заметил замедления скорости при просмотре веб-страниц.
С другой стороны, DNSCrypt для шифрования не полагается на доверенные центры сертификации — клиент должен доверять открытому ключу подписи, выданному провайдером. Этот ключ подписи используется для проверки сертификатов, которые извлекаются с помощью обычных (нешифрованных) DNS-запросов и используются для обмена ключами с использованием алгоритма обмена ключами X25519. В некоторых (более старых) реализациях DNSCrypt есть условие для сертификата на стороне клиента, который может использоваться в качестве схемы управления доступом. Это позволяет им журналировать ваш трафик независимо от того, с какой IP-адреса вы пришли, и связывать его с вашим аккаунтом. Такая схема не используется в DNSCrypt 2.
С точки зрения разработчика немного сложно работать с DNSCrypt. «DNSCrypt не особенно хорошо документирован, и не так много его реализаций», — говорит Крикет Лю из Infoblox. На самом деле мы смогли найти только единственный клиент в активной разработке — это DNSCrypt Proxy, а OpenDNS прекратил поддерживать его разработку.
Интересный выбор криптографии в DNSCrypt может напугать некоторых разработчиков. Протокол использует Curve25519 (RFC 8032), X25519 (RFC 8031) и Chacha20Poly1305 (RFC 7539). Одна реализация алгоритма X24419 в криптографических библиотеках Pyca Python помечена как «криптографически опасная», потому что с ней очень легко ошибиться в настройках. Но основной используемый криптографический алгоритм Curve25519, является «одной из самых простых эллиптических кривых для безопасного использования», — сказал Денис.
Разработчик говорит, что DNSCrypt никогда не считался стандартом IETF, потому что был создан добровольцами без корпоративной «крыши». Представление его в качестве стандарта «потребовало бы времени, а также защиты на заседаниях IETF», — сказал он. «Я не могу себе этого позволить, как и другие разработчики, которые работают над ним в свободное время. Практически все ратифицированные спецификации, связанные с DNS, фактически написаны людьми из одних и тех же нескольких компаний, из года в год. Если ваш бизнес не связан с DNS, то действительно тяжело получить право голоса».
TLS стал приоритетом для CloudFlare, когда понадобилось усилить шифрование веб-трафика для защиты от слежки
У DNS по TLS (Transport Layer Security) несколько преимуществ перед DNSCrypt. Во-первых, это предлагаемый стандарт IETF. Также он довольно просто работает по своей сути — принимает запросы стандартного формата DNS и инкапсулирует их в зашифрованный TCP-трафик. Кроме шифрования на основе TLS, это по существу то же самое, что и отправка DNS по TCP/IP вместо UDP.
Существует несколько рабочих клиентов для DNS по TLS. Самый лучший вариант, который я нашел, называется Stubby, он разработан в рамках проекта DNS Privacy Project. Stubby распространяется в составе пакета Linux, но есть также версия для MacOS (устанавливается с помощью Homebrew) и версия для Windows, хотя работа над последней ещё не завершена.
Хотя мне удалось стабильно запускать Stubby на Debian после сражения с некоторыми зависимостями, этот клиент регулярно падал в Windows 10 и имеет тенденцию зависать на MacOS. Если вы ищете хорошее руководство по установке Stubby на Linux, то лучшая найденная мной документация — это пост Фрэнка Сантосо на Reddit. Он также написал shell скрипт для установки на Raspberry Pi.
Положительный момент в том, что Stubby допускает конфигурации с использованием нескольких служб на основе DNS по TLS. Файл конфигурации на YAML позволяет настроить несколько служб IPv4 и IPv6 и включает в себя настройки для SURFNet, Quad9 и других сервисов. Однако реализация YAML, используемая Stubby, чувствительна к пробелам, поэтому будьте осторожны при добавлении новой службы (например, Cloudflare). Сначала я использовал табы — и всё поломал.
Клиенты DNS по TLS при подключении к серверу DNS осуществляют аутентификацию с помощью простой инфраструктуры открытых ключей (Simple Public Key Infrastructure, SPKI). SPKI использует локальный криптографический хэш сертификата провайдера, обычно на алгоритме SHA256. В Stubby этот хэш хранится как часть описания сервера в файле конфигурации YAML, как показано ниже:
После установления TCP-соединения клиента с сервером через порт 853 сервер представляет свой сертификат, а клиент сверяет его с хэшем. Если всё в порядке, то клиент и сервер производят рукопожатие TLS, обмениваются ключами и запускают зашифрованный сеанс связи. С этого момента данные в зашифрованной сессии следуют тем же правилам, что и в DNS по TCP.
После успешного запуска Stubby я изменил сетевые настройки сети DNS, чтобы направлять запросы на 127.0.0.1 (localhost). Сниффер Wireshark хорошо показывает этот момент переключения, когда трафик DNS становится невидимым.
Переключаемся с обычного трафика DNS на шифрование TLS
Хотя DNS по TLS может работать как DNS по TCP, но шифрование TLS немного сказывается на производительности. Запросы dig к Cloudflare через Stubby у меня выполнялись в среднем около 50 миллисекунд (у вас результат может отличаться), в то время как простые DNS-запросы к Cloudflare получают ответ менее чем за 20 мс.
Здесь тоже имеется проблема с управлением сертификатами. Если провайдер удалит сертификат и начнёт использовать новый, то в настоящее время нет чистого способа обновления данных SPKI на клиентах, кроме вырезания старого и вставки нового сертификата в файл конфигурации. Прежде чем с этим разберутся, было бы полезно использовать какую-то схему управления ключами. И поскольку сервис работает на редком порту 853, то с высокой вероятностью DNS по TLS могут заблокировать на файрволе.
Google и Cloudflare, похоже, одинаково видят будущее зашифрованного DNS
Как Cloudflare, мы считаем, что туннели иллюстрируют операцию «Арго» лучше, чем Бен Аффлек
Дабы убедиться, что проблема именно в протоколе DoH, а не в программистах Cloudflare, я испытал два других инструмента. Во-первых, прокси-сервер от Google под названием Dingo. Его написал Павел Форемски, интернет-исследователь из Института теоретической и прикладной информатики Академии наук Польши. Dingo работает только с реализацией DoH от Google, но его можно настроить на ближайшую службу Google DNS. Это хорошо, потому что без такой оптимизации Dingo сожрал всю производительность DNS. Запросы dig в среднем выполнялись более 100 миллисекунд.
Это сократило время отклика примерно на 20%, то есть примерно до того показателя, как у Argo.
А оптимальную производительность DoH неожиданно показал DNSCrypt Proxy 2. После недавнего добавления DoH Cloudflare в курируемый список публичных DNS-сервисов DNSCrypt Proxy почти всегда по умолчанию подключается к Cloudflare из-за низкой задержки этого сервера. Чтобы убедиться, я даже вручную сконфигурировал его под резолвер Cloudflare для DoH, прежде чем запустить батарею dig-запросов.
Все запросы обрабатывались менее чем за 45 миллисекунд — это быстрее, чем собственный клиент Cloudflare, причём с большим отрывом. С сервисом DoH от Google производительность оказалась похуже: запросы обрабатывались в среднем около 80 миллисекунд. Это показатель без оптимизации на ближайший DNS-сервер от Google.
Я не Бэтмен, но моя модель угроз всё равно немного сложнее, чем у большинства людей
Я профессиональный параноик. Моя модель угроз отличается от вашей, и я предпочел бы сохранить в безопасности как можно больше своих действий в онлайне. Но учитывая количество нынешних угроз приватности и безопасности из-за манипуляций с трафиком DNS, у многих людей есть веские основания использовать какую-либо форму шифрования DNS. Я с удовольствием обнаружил, что некоторые реализации всех трёх протоколов не оказывают сильно негативного влияния на скорость передачи трафика.
Другая проблема в том, что, хотя прекрасные ребята из сообщества DNSCrypt проделали большую работу, но такая приватность по-прежнему слишком сложна для обычных людей. Хотя некоторые из этих DNS-клиентов для шифрования оказалось относительно легко настроить, но ни один из них нельзя назвать гарантированно простым для нормальных пользователей. Чтобы эти услуги стали действительно полезными, их следует плотнее интегрировать в железо и софт, который покупают люди — домашние маршрутизаторы, операционные системы для персональных компьютеров и мобильных устройств.
Интернет-провайдеры наверняка постараются активнее монетизировать обычный DNS-трафик, и никуда не исчезнут государственные агентства и преступники, которые стремятся использовать его во вред пользователю. Но маловероятно, что крупные разработчики ОС стремятся надёжно защитить DNS доступным для большинства людей способом, потому что они часто заинтересованы в монетизации, как и интернет-провайдеры. Кроме того, эти разработчики могут столкнуться с сопротивлением изменениям со стороны некоторых правительств, которые хотят сохранить возможности мониторинга DNS.
Так что в ближайшее время эти протоколы останутся инструментом для тех немногих людей, кто реально заботится о конфиденциальности своих данных и готов для этого немного потрудиться. Надеюсь, сообщество вокруг DNSCrypt продолжит свою активность и продвинет ситуацию вперёд.
Сегодня мы немного прокачаем наш прокси сервер
- Берем ОС Windows 7 x86.. Можно взять и x64 — дело хозяйское.
- Устанавливаем DNS-прокси Acrylic DNS
- Устанавливаем web-сервер Mongoose
- Устанавливаем антивирус
- Устанавливаем 3proxy
- Настраиваем логирование в БД
- Смотрим отчеты
Теперь поехали по пунктам…
Step 6
In the Networking tab access the properties of the Internet Protocol Version 6 (TCP/IPv6) item by selecting it and clicking on the Properties button.
5 и 6. 3proxy и логи в БД
Дошли до самого интересного. Скачиваем подходящую сборку под нашу винду, распаковываем архив куда-нибудь на C:3proxy.
Скачиваем мой архив с двумя файлами: пустая БД для 3proxy и утилита просмотра отчетов.
Файл 3proxy.sqlite запихиваем в C:3proxylog Утилиту можно положить куда угодно, где вам будет удобно ее запускать.
Настраиваем ODBC: добавляем системный DSN как на скриншоте
Настраиваем конфигурационный файл в C:3proxycfg3proxy.cfg У меня он выглядит довольно просто. Доступ через прокси у меня разрешен всем, аутентификации нет.
Строки из конфига, отвечающие за логирование событий в БД:
Теперь устанавливаем 3proxy в качестве службы Windows. Открываем командную строку от имени администратора и пишем там
Служба установится и запустится. Теперь можно настраивать браузеры компов локальной сети на прокси сервер и выходить в интернет.
3. Mongoose
Если вам нужен простой web-сервер для показа внутри локалки простых html страниц или, например, для раздачи скриптов автонастройки браузеров, то mongoose весьма неплох. Если у вас таких потребностей нет, то этот шаг можно пропустить.
У Mongoose есть несколько редакций как платных так и бесплатных. Мы, конечно же будем юзать бесплатную редакцию, которая имеет некоторые ограничения. Например, бесплатная версия не может работать в качестве службы windows. Скачиваем бесплатную версию , закидываем в какую-нибудь папку на диске С и запускаем там.
Я сделал папку C:webserver и в ней еще одну папку www
Установка не требуется. Нам нужно зайти в настройки web-сервера через иконку головы желтого мангуста в трее:
Откроется страница браузера, где нужно поменять несколько параметров: путь корневого каталога web-сервера, порт и нажать кнопку сохранить настройки
Теперь заставим работать его как служба Windows. Для этого скачиваем nssm . В архиве будут бинарники для Win x86 и Win x64. Берете нужный EXE-ник и кладете рядом с mongoose. Открываем командную строку от имени администратора и пишем там C:webservernssm.exe install mongoose
В открывшемся окне указываем путь по Mongoose и жмем Install Service
How do I install Acrylic?
Step 1
Right-click on the Network icon in the System tray and select the Open Network and Sharing Center item.
2. Acrylic DNS
Эта штука ни что иное как кэширующий DNS-прокси. Он поможет нам «отфильтровать» самые плохие сайты, мы сможем легко задавать красивые имена любым ресурсам в локальной сети и мы прилично уменьшим DNS-трафик идущий за пределы нашей локалки.
Пару слов о фильтрации. Обычно в сетевых настройках компьютеров и в роутерах в качестве DNS-сервера выставлен ip-адрес DNS-сервера провайдера, который работает по принципу «как есть»: если компьютер запрашивает имя сайта с вредоносным контентом, то честный DNS-сервер укажет IP-адрес сайта. В результате на компьютере откроется вредоносный сайт со всеми вытекающими. Наше спасение заключается в том, что в последнее время в интернете стали появляться «правильные» DNS-сервера, которые не ответят вашему компьютеру ничего, если тот пытается узнать адрес «плохого» сайта. Вместо сайта в браузере будет показан «красивый» отбойник.
Такие правильные DNS-сервера предоставляет, например, Яндекс за бесплатно.
Короче говоря, на нашем сервере мы поднимаем Acrylic DNS и в его настройках указываем «правильные» DNS-сервера из интернета. А на компьютерах локальной сети в качестве DNS-сервера мы указываем IP-адрес нашего сервера. Сделать это можно или руками или через настройки DHCP — как вам удобнее.
Скачиваем Acrylic DNS , дополнительно к нему скачиваем Acrylic DNS Monitor — утилиту мониторинга.
Так же в конфигурационном файле не лишним будет задать логирование:
Так же нужно разрешить обращаться к Acrylic DNS с компьютеров локальной сети:
В моем случае Acrylic DNS будет отвечать всем у кого IP-адрес 10.x.x.x ну и самому себе 127.0.0.1
В файле AcrylicHosts.txt при необходимости можно прописать нужные вам имена:
Я прописал несколько имен, которые я использую в DHCP для раздачи скриптов автонастройки браузеров (как-нибудь напишу на эту тему обзор), а вы можете вписать сюда что-то своё.
После этого необходимо перезапустить службу Acrylic DNS:
За работой программы можно следить с помощью Acrylic DNS Monitor. Здесь отображается вся история запросов к серверу от компьютеров локальной сети.
В настройках сети нашего сервера меняем адрес DNS-сервера на 127.0.0.1
С помощью DHCP или руками на компьютерах сети нужно указать IP-адрес нашего прокси сервера в поле DNS-сервера.
Читайте также: