Dns over tls keenetic настройка
Как известно, в России, Китае и некоторых других странах повально закрывают доступ к множеству сайтов, легальных и не очень, безопасных и не очень. РКН не держит базу в открытом доступе, а вместо этого он предлагает провайдерам использовать цифровую подпись для доступа к базе. РКН рекомендует провайдерам обновлять базу раз в час. Эта база содержит список доменных имен, IP адресов и сетей, которые должны быть заблокированы.
Провайдер, в свою очередь, скачав базу, должен перенаправлять запросы к указанных ресурсам на страницу о блокировке. Кроме того, провайдеров обязали установить программно-аппаратный комплекс « Ревизор» разработки «МФИ Софт», который автоматически проверяет доступ к запрещенным сайтам из сети провайдера. Кстати, решение было создано на базе беспроводного маршрутизатора компании TP-Link :)
В итоге при обращении по определенному доменному имени или IP правила на сетевом оборудовании провайдера резолвили (разрешали) адрес заблокированного сайта в IP сервера, где находится страница с информацией о блокировке, которая пользователем и показывалась вместо ожидаемого сайта.
Но этим все не заканчивается. Конечно же, продвинутые пользователи сразу начали обходить такую блокировку просто прописав сторонние DNS, например от Google (8.8.8.8). Но счастье продлилось недолго.
Собственно решение
Включаем DoH в браузере
Google Chrome
В адресной строке вводим вот такой URL-адрес:
Нажимаем клавишу «Enter» и попадаем вот на такую страницу:
Первым будет параметр «Secure DNS Lookups» — он то нам и нужен. Напротив него в выпадающем списке выбираем пункт Enable и перезапускаем приложение.
Opera
В браузере Opera порядок действий такой же, как и в хроме, только URL-запрос нужно вводить вот такой:
Искомый параметр называется «Secure DNS». Вот он:
Ставим ему значение Enable и перезапускаем Оперу. После этого браузер будет использовать ДНС-сервер Cloudflare 1.1.1.1 через защифрованное соединение.
Microsoft Edge
В адресную строку вводим URL:
Параметру «Secure DNS lookups» ставим значение «Enable» и нажимаем на кнопку «Restart» внизу странички чтобы перезапустить браузер.
Mozilla Firefox
В результатах видим, что нужно зайти в параметры сети. Кликаем на кнопку «Настроить» и видим вот такое окно:
Как я уже сказал, некоторые WiFi маршрутизаторы уже умеют работать с этим протоколом. Правда, не из коробки — в каждом случае нужно устанавливать дополнения для операционной системы. Я покажу это на примере роутера Keenetic.
Кликаем на кнопку «Добавить сервер» чтобы появились поля параметров. Тут нужно прописать имя сервера DNS. Я использую вот эти:
Формат можно использовать JSON, который идёт по умолчанию, либо или DNS message, как у меня. Так же я указал WAN-интерфейс на котором будет работать протокол.
Если Вы пропишите несколько ДНС, то предпочитаемым будет тот, который быстрее отвечает.
Кратко — логика решения
- Устанавливаем и настраиваем Pi-Hole
- Устанавливаем и настраиваем cloudflared
- Настраиваем ваш домашний роутер
- Решаем проблемы
Современные методы блокировки
Основными мотивами перенаправления обычно является желание сэкономить трафик, снизить время отклика, обеспечить дополнительную защиту или реализовать блокировку запрещённых ресурсов. Если пользователь пытается перейти на несуществующий сайт, то провайдер перенаправляет его на свою страницу с рекламой. А может и не на свою. В наибольшей степени перехват обращений к DNS пользуются в Китае, на втором месте Россия, на третьем — США.
Кстати, перехват DNS запросов (DNS hijacking) может использоваться и троянами для вредоносных целей. В 2007 году группа предприимчивых людей из Эстонии создала троян DNSChanger, который за несколько лет заразил 4 млн компьютеров по всему миру. Троян изменял системные настройки DNS, что приводило к появлению рекламы на веб-страницах. Также подвержены этой уязвимости и домашние модемы и роутеры (при условии, что проникнув в них, будут прописаны подставные DNS сервера).
Из методов перехвата трафика наиболее популярными являются перенаправление запросов и реплицирование ответа (оригинальный запрос и ответ не блокируются, но провайдер также направляет свой подставной ответ, который обычно приходит раньше и воспринимается клиентом). Наиболее часто перехватываемым публичным DNS-сервером стал сервис Google (8.8.8.8).
Что вам для этого потребуется
- Доверять Cloudflare. На самом деле это очень важный пункт, поскольку в описываемой реализации все ваши DNS-запросы обрабатываются сервисом Cloudflare. Если вы ему не доверяете — вам придется внедрить другое решение (и это немногим сложнее, чем описанное, но целью этой статьи не является).
- Иметь возможность поддерживать в домашней сети постоянно работающий сервер с Linux, который будет обслуживать DNS-запросы ваших устройств. Требование Pi-Hole — от 512M оперативной памяти (впрочем, работу с меньшим объемом сам не проверял). Если ваш роутер или NAS умеют виртуальные машины — это прекрасный вариант, если на полке где-то завалялась Raspberry Pi или другой микрокомпьютер на ARM — не менее хорошо, если на антресолях в коридоре жужжит виртуальная ферма на ESXi — то что я вам рассказываю, вы и сами всё знаете. Если у вас ничего из этого нет — самые младшие решения, типа Orange Pi Zero, на вторичном рынке можно найти за единицы сотен рублей либо привезти из Али за плюс-минус те же деньги. Но выбор платформы сильно выходит за рамки этой статьи, поэтому считаем, что у вас что-то есть. Впрочем, вопросы на этот счет можно задавать в комментариях.
- Вы должны иметь представление о использовании Linux и сетевых технологиях. Или хотя бы хотеть получить такое представление. Поскольку объять необъятное в этот раз я не готов, некоторые непонятные для вас моменты вам придется изучить самостоятельно. Впрочем, на конкретные вопросы, конечно же, отвечу в комментариях и вряд ли окажусь единственным отвечающим, так что не стесняйтесь спрашивать.
2. Устанавливаем и настраиваем cloudflared
Тут для установки нам потребуется приложить немного больше усилий, но тоже ничего особо сложного.
Выбираем и загружаем инсталлятор для нашей платформы.
После выполнения последней команды мы должны получить вывод, подобный следующему:
Если он у вас такой (естественно, номер версии и билда может отличаться) — то поздравляю, установка прошла успешно. Теперь дело за настройкой.
Создаем пользователя для работы сервиса:
Создаем файл конфигурации сервиса /etc/default/cloudflared:
И даем на него и на исполняемый файл права свежесозданному пользователю:
Далее создаем файл /lib/systemd/system/cloudflared.service, который даст нам возможность интеграции сервиса в systemd:
Активируем сервис и запускаем его:
Если всё получилось — вы увидите, что сервис в состоянии active (running).
Вы можете проверить работу сервиса, например командой dig:
Осталось только подключить сервис к Pi-Hole. Для этого вы заходите в веб-интерфейс Pi-Hole (тут вам пригодится записанный в первом этапе пароль), идете в пункт меню Settings — DNS и делаете его выглядящим приблизительно вот так:
Если вы забыли записать пароль — ничего страшного, заходите на сервер через ssh и исполняете команду pihole -a -p, она позволит задать новый пароль. Ну и в целом посмотрите ключи команды pihole, там много интересного. Например, обновление системы делается одной командой pihole -up.
1. Устанавливаем и настраиваем Pi-Hole
Pi-Hole — это известная домашняя платформа, предназначенная прежде всего для борьбы с рекламой через блокирование запросов к доменам из централизованно обновляемого списка. Не то чтобы это был необходимый компонент решения, но если начал собирать домашний DNS, становится трудно остановиться. А если серьезно — Pi-Hole, возможно, и не идеален, но снимает большой объем головной боли с человека, которому надо "чтобы работало".
Чтобы установить Pi-Hole на уже имеющийся у нас запущенный Linux-сервер, нам достаточно выполнить одну команду:
И далее запущенный скрипт проведет вас по шагам установки.
В момент, когда он спросит вас про выбор Upstream DNS Provider, вы можете выбрать любой, поскольку на следующем шаге мы всё равно будем его менять. Все остальные параметры можно смело оставлять по умолчанию.
В конце инсталляции скрипт покажет вам сгенерированный случайным образом пароль от веб-интерфейса, который вам было бы полезно записать.
Если что-то при установке пошло не так — можно использовать альтернативные способы, описанные тут.
Disclaimer
Поскольку публиковать способы обхода блокировок доступа к информации, запрещенной на территории Российской Федерации, не очень законно, целью этой статьи будет рассказать о методе, позволяющем автоматизировать получение доступа к ресурсам, разрешенным на территории Российской Федерации, но из-за чьих-то действий недоступным напрямую через вашего провайдера. А доступ к другим ресурсам, получаемый в результате действий из статьи, является досадным побочным эффектом и целью статьи ни в коем случае не является.
Разворачиваем собственный DNS-сервер на базе Pi-Hole, использующий Cloudflare DoH для запросов в мир. Цель — зашифровать все DNS-запросы и обойти таким образом операторскую фильтрацию через перехват DNS. Полезный бонус — фильтрация рекламы.
Никаких волшебных know-how не открывается, простая пошаговая инструкция для тех, кому не хочется разбираться во всех хитросплетениях самому.
Как работает DNS over TLS
Для реализации DNS-over-TLS предлагается клиент Stubby для Windows, MacOS и Ubuntu.
Также из хороших новостей в Android 9 поддержка DNS-over-TLS встроена в системный DNS резолвер. В частности, в моем Huawei P20 эта настройка находится в Настройки — Беспроводные сети — Частный DNS. По умолчанию, там стоит Авто.
Например, для того, чтобы настроить телефон на использование DNS сервиса CloudFlare, вам нужно туда прописать в качестве адреса DNS сервера:
Инструкция с картинкой доступна на официальном сайте.
[Посещений: 3 487, из них сегодня: 1]
После сравнительно недавнего анонса компанией Mozilla запуска поддержки DNS-over-HTTPS (DoH) в продакшн в сети не утихают споры, зло это или благо. По моим ощущениям, позиция "зло" базируется в основном на том, что при этом манипуляция вашими DNS-запросами даже в полезных для вас целях будет затруднена, поэтому я пока что остаюсь на позиции "благо".
В Российской Федерации операторы связи, поставленные в очень жесткие условия нашим законодательством, вынуждены строить изощренные многоуровневые системы блокировок доступа к запрещенному Роскомнадзором на территории РФ контенту, на одном из уровней которых более-менее успешно работает перехват DNS-запросов. Использование DoH позволит обойти этот уровень, что в совокупности с использованием VPN может несколько облегчить вам жизнь. Обратите внимание, само по себе решение не может избавить вас от блокировок, потому что вряд ли в России есть провайдер, полагающийся только на фильтрацию через DNS. Вам нужен еще какой-то вариант обойти блокировки, например VPN, один из описанных в моих предыдущих статьях.
Парадоксально, но в текущем паноптикуме оператору связи ничем не грозит ваш обход его блокировок (с использованием специальных средств для этого), поэтому если вы опасаетесь навредить ему таким образом — эти опасения напрасны.
Но переходить на специальный браузер, чтобы обойти перехват DNS — не наш путь. Наш путь — перевести все устройства домашней сети на DoH, быстро, эффективно и без лишних трудозатрат.
Схема работы DoH
Сегодня DNS-серверы это один из ключевых элементов работы глобальной сети Интернет. С их помощью идет обработка запросов пользователя. В самом простом приближении это выглядит так: человек вводит адрес сайта в адресной строке браузере, после этого идёт обращение к ДНС-серверу, который в свою очередь определяет IP сайта и возвращает результат обратно пользователю, чтобы он мог перейти на нужный ему сайт. В таком виде запросы достаточно просто перехватить, просмотреть и даже подменить. Конечно, провайдер подменой заниматься не будет, а вот злоумышленники очень даже могут!
3. Настраиваем ваш домашний роутер
Всё многообразие роутеров я, конечно, закрыть этим текстом не могу. Но для большинства домашних роутеров справедливы следующие моменты:
1) У роутера можно задать кастомный DNS-сервер в настройках WAN-интерфейса, даже если IP-адрес получается от провайдера динамически
2) Роутер выдает внутренним клиентам свой адрес в качестве DNS и переправляет их запросы на тот сервер, который указан в настройках WAN
Соответственно, в этом случае нам необходимо и достаточно прописать адрес нашего Pi-Hole в качестве DNS-сервера в настройках WAN-интерфейса домашнего роутера. Важно, чтобы он был единственным DNS-сервером в настройках, если будет указан какой-то еще — роутер будет балансировать запросы между ними по только ему известному принципу и такая ситуация крайне неудобна для отладки проблем в сети.
Если вдруг что-то пошло не так и сервис перестал работать, указанную выше настройку достаточно поменять на адрес DNS-сервера вашего провайдера или, например, 8.8.8.8, а уже потом начинать разбираться.
Если у вас роутер более умный и, например, имеет возможность указать в DHCP, какой адрес раздавать клиентам в качестве DNS-сервера, можете пойти по альтернативному пути и настроить раздачу адреса Pi-Hole клиентам напрямую. Это немного разгрузит роутер, но зато усложнит вышеописанный откат с использования сервиса.
В случае, если что-то не будет получаться — спрашивайте в комментариях, найдем решение.
4. Решаем проблемы
В целом после выполнения вышеописанных пунктов у вас уже всё должно быть хорошо, но бывают нюансы, с которыми я и мои клиенты иногда сталкивались.
Обнаружить такую проблему достаточно просто — если вы пытаетесь зайти на заблокированный сервер, ваш браузер показывает вам ошибку ERR_NAME_NOT_RESOLVED или подобную, а проверка в командной строке через nslookup в ответ выдает 0.0.0.0.
Также регулярно бывает, что Pi-Hole инсталлируют на сервер, на котором уже работает какой-то веб-сервис. В этом случае вы не получите доступа к веб-интерфейсу управления. Как разруливать такой конфликт — зависит от конкретной ситуации, но основные пути решения — это:
DNSCrypt
Сообщество DNSCrypt создало простые в использовании клиенты, такие как Simple DNSCrypt для Windows и клиент для Apple iOS под названием DNS Cloak, что делает шифрование DNS доступнее для нетехнических людей. Другие активисты подняли независимую сеть приватных DNS-серверов на основе протокола, помогающего пользователям уклониться от использования корпоративных DNS-систем.
Для тех, кто хочет запустить DNS-сервер с поддержкой DNSCrypt для всей своей сети, лучшим клиентом будет DNSCrypt Proxy 2. По умолчанию прокси-сервер использует открытый DNS-резолвер Quad9 для поиска и получения с GitHub курируемого списка открытых DNS-сервисов. Затем подключается к серверу с самым быстрым откликом. При необходимости можно изменить конфигурацию и выбрать конкретный сервис.
Основное преимущество DNSCrypt в том, что он передаёт UDP-трафик по порту 443 — тот же порт используется для безопасных веб-соединений. Это даёт относительно быстрый резолвинг адресов и снижает вероятность блокировки на файрволе провайдера.
Кроме того нативная поддержка DNSCrypt реализована в Яндекс.Браузере. При этом все запросы в зашифрованном виде будут отправляться на быстрый DNS-сервер Яндекса, который также получил поддержку протокола DNSCrypt. Правда, по умолчанию эта настройка в браузере отключена.
Сравним два эти протокола:
Как бороться с перехватом DNS
Также для компаний разумно рассмотреть вариант проксирования DNS трафика. DNS-прокси с одной из этих служб (непосредственно на сетевом устройстве или на сервере в локальной сети) поможет предотвратить DNS-утечки через VPN, поскольку прокси-сервер всегда будет самым быстрым DNS-сервером среди всех доступных.
Список публичных DNS-сервисов с поддержкой DoT/DoH вы можете найти на:
Для пользователей подключить DNS-шифрование не так просто, как изменить адрес в настройках сети. В настоящее время ни одна ОС напрямую не поддерживает шифрование DNS без дополнительного программного обеспечения. И не все сервисы одинаковы с точки зрения софта и производительности.
Диспозиции сейчас такие:
DNS через TLS поддерживается основными поставщиками DNS, что не относится к DNSCrypt. Однако, последняя предоставляет удобную утилиту для Windows, плюс этот протокол поддерживается Яндекс. Поэтому с него и начнем.
Исходные данные
IPv4-адрес нашего сервера в домашней сети: 192.168.1.10 и он назначен как статический.
Настройки на Linux выполняем от root (т.е. перед началом настройки выполняем команду sudo su -).
Проверка работы протокола
Нажимаем кнопочку «Check my browser» и смотрим что будет показано в результатах. А именно, нас интересует пункт «Secure DNS» — он должен быть помечен зеленой галочкой:
Единственный момент, о котором стоит упомянуть — если Вы используете публичные ДНС от Google то этот тест не всегда удаётся пройти. Всё же Cloudflare продвигает свой сервис и поэтому удивляться не стоит.
Заключение
Как и обещал, не написал ничего нового. Для многих читателей эта схема понятна и очевидна, и или уже внедрена, или не внедрена за ненадобностью. Многие другие построили что-то подобное по-другому, с использованием тех же или иных компонентов. Предлагаю рассматривать этот пост скорее как заготовку для вашего собственного решения, если оно вам когда-либо потребуется. Но, выполнив его как пошаговую инструкцию, вы уже получите сервис, закрывающий ваши базовые потребности в фильтрации рекламы и использовании DoH.
На вопросы, традиционно, отвечу и с настройками помогу.
P.S. Замечание от GennPen — при использовании DoH вы становитесь зависимыми от наличия у вас интернета и если на счету закончились деньги — то даже в личный кабинет провайдера зайти не сможете, чтобы их заплатить. Поэтому для таких сайтов в этом решении желательно прописать статические записи в Pi-Hole — это можно сделать в консоли командой pihole -a -r или просто вручную в файле /etc/hosts. В веб-интерфейсе для этого инструмент, к сожалению, не заложен.
Шифрование трафика между вашим устройством и 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 продолжит свою активность и продвинет ситуацию вперёд.
Жмакнув по этой ссылке и проверив Firefox ( или любой другой популярный браузер ), у каждого из вас перед глазами откроется невыносимая сторона жизни. губительные противоречия действительности, неразрешимый конфликт в области информационных систем и технологий .
Упсс. Ну, как же так? Почему моя конфиденциальность ниже плинтуса? Запросы DNS у всех на виду, resolver не проверяет ответы DNS с помощью DNSSEC, браузер не зашифровал SNI.
В гордом одиночестве TLS 1.3. У кого и с этим проблемы, отредактируйте файл конфигурации Firefox ( именно с этим браузером будем возиться ). В адресной строке браузера набираем: about:config и в строке поиска настроек, вводим имя security.tls.version.max - (выставляем значение 4 ).
Языком бульдозериста, что такое DNS-сервер.
Пользователю тяжело запомнить цифры. Компьютер разговаривает только на языке цифр. Каким образом столкнуть лбами принципиально разные субстанции .
На картинке, что выше мы видим красные стрелки (запрос, ответ, запрос, ответ). И всё это напоминает деревню. стоит кому-то, что-либо «шушукнуть» - через пять минут, пол деревни всё знает.
Основная задача DoH - зашифровать DNS-трафик для предотвращения перехвата и обеспечения дополнительной конфиденциальности и безопасности.
Вот еще один камень ( ссылка ), запущенный в сторону евангелистов «безопасного DNS». (DoH) это панацея не от цензуры, а от излишне любознательных «информационных посредников», провайдеров и интернет-жулья.
Другие всеми конечностями «За», ибо хватит молчать, надо что-то решать ( ссылка ), все давно устали от того, что упЫри делают с нашим интернетом.
Как ко всему этому кордебалету относится автор ? Сейчас расскажу.
По началу в веб конфигураторе интернет центра (192.168.1.1), стояли DNS-сервера моего горячо любимого провайдера LLC Intercon . Стоят и стоят, каши не просят. Но, потом началось. чуть ли не каждую неделю интернет стал «сыпаться», когда на 15 минут, а когда и на значительно больший промежуток времени. Не очень приятная штука, однако. Звонишь провайдеру, а там нУль эмоций и безразличие в голосе. Ща, все будет голубчик, не надо паниковать ٩(̾●̮̮̃̾•̃̾)۶. Начинаешь делать диагностику неполадок, выскакивает типа этого:
Ага, думаю, сколько рубаху телефон не рви, пока сам себе не поможешь, будет шляпа. Зашел в системный монитор интернет-центра KEENETIC (192.168.1.1) и заколотил прямой наводкой DNS 1 : 8.8.8.8 DNS 2 : 1.1.1.1 DNS 3 : 9.9.9.9. Разложил, так сказать «DNS яйца» по разным корзинам, помимо Domain name server провайдера ツ.
LLC Intercon снова стал горячо любим и уважаем, интернет перестал «падать», бесполезные звонки прекратились.
Дык вот, к чему веду. Если давно использую публичные сервера , почему бы не зашифровать DNS запросы. Заодно уберем раздражающие, тягостные, мрачные кнопки с этой страницы .
Сказано, сделано. Мы не ищем лёгких путей, будем делать всё длинными ручками, хотя в Firefox можно поставить единственный маркер , но, об этом чуть позже.
В адресной строке браузера набираем: about:config и в строке поиска настроек, находим network.trr.mode - (присваиваем параметру значение 2 - используется DoH по умолчанию, а DNS как запасной вариант ).
Вы можете установить другие значения:
0 – отключить TRR по умолчанию;
1 - используется DNS или DoH, в зависимости от того, что быстрее;
4 - режим зеркалирования при котором DoH и DNS задействованы параллельно. Вариант лично для меня совершенно не понятный, но разработчикам виднее;
5 - отключить TRR по выбору.
Далее находим network.trr.bootstrapAddress и настраиваем на 1.1.1.1 ( если хотите работать с cloudflare ) или 8.8.8.8 ( если хотите работать с Google ).
В адресной строке браузера набираем: about:networking и проверяем сеть (раздел DNS). Нажимаем кнопку Очистить кеш DNS, обновляем страничку, смотрим TRR. Должно быть true на против многочисленных имен узлов.
Читайте также: