Dns fallback что это
Обновлено: 04.07.2024
Предыдущий релиз был меньше двух месяцев назад, и вот мы снова здесь. Встречайте AdGuard 4.1 для iOS! Давайте посмотрим, что хорошего в новой версии.
Но для начала небольшое чистосердечное признание. Сегодня утром Босс собрал всю нашу контент-команду и сказал, что про новые версии стоит писать, цитата: «Как-то повеселее». Всё для того, чтобы вам, дорогие пользователи, не было скучно от всех этих технических подробностей. Мы, конечно, согласны и очень этому рады. 😬 Но этот текст переписывать заново уже не было времени :(
Быстрое решение нашлось: мы добавили три поистине великолепнейшие шутки в текст, чтобы он стал «как-то повеселее».
Как называется прямая трансляция длинных носков в Twitch?
Гольфстрим
Ладно, давайте перейдём к списку изменений.
Нативная поддержка DNS
Давным-давно ученые обнаружили интересный феномен. Нам кажется, что больше всего мы хотим получить желаемое, но на самом деле, гораздо больше удовольствия мы получаем в ожидании получения желаемого. Прошло несколько месяцев с тех пор, как Apple добавила поддержку встроенного DNS-шифрования в iOS, и вы могли подумать, что мы в AdGuard просто поленились тоже добавить его поддержку. А вот и нет! Мы просто следовали за наукой и хотели доставить вам как можно больше удовольствия. Ну а теперь время для катарсиса :)
Да, мы добавили нативную поддержку DNS.
В новой версии поддерживаются уже три протокола, в том числе и Обычный (Regular DNS), и метод стал нативным не только для iOS, но и для AdGuard. Мы упростили схему из сентябрьского поста: теперь вам не нужно скачивать и устанавливать DNS-профили, достаточно включить «Нативное решение» в настройках AdGuard для iOS:
- Откройте Настройки AdGuard > DNS-защита > DNS-решение > Нативное.
- Включите системную защиту. Вы увидите инструкцию, что делать дальше (откройте Системные настройки, перейдите в Основные > VPN и сеть > DNS и выберите там AdGuard).
Новый метод настройки DNS на самом деле не лучше старого, уже знакомого вам. У него есть одно небольшое преимущество: в этом случае DNS полностью контролируется системой, а не приложением, т.е. AdGuard не придётся создавать собственный локальный VPN. К сожалению, это не поможет обойти системные ограничения и использовать AdGuard параллельно с другими VPN-приложениями — нативный DNS просто игнорируется, если включён хотя бы один VPN. Кроме того, вы не можете фильтровать трафик локально и не сможете использовать наш новый протокол DNS-over-QUIC (DoQ).
Все эти протоколы и другие истории про DNS вас не отпугнули? Круто! Вы можете наградить себя очередной изысканной шуткой:
Как называют людей, которые незаконно обогащаются на гречке?
Крупционеры
Пожалуй, перейдём к остальным изменениям.
Низкоуровневые настройки
Этот раздел настроек AdGuard может смутить пользователей провокационным вопросом «Вы разработчик?» в описании. Но если вы технически подкованы, есть несколько новых функций, которые могут вам пригодиться.
Bootstrap- и Fallback-серверы
С Fallback всё довольно просто — это резервный DNS-сервер. Если вы выбрали DNS-сервер и с ним что-то случилось, необходим запасной вариант, резервный DNS-сервер, который будет использоваться, пока не отвечает основной.
С Bootstrap чуть сложнее. Чтобы AdGuard для iOS мог использовать кастомный защищённый DNS-сервер, наше приложение должно сначала получить его IP-адрес. Для этой цели по умолчанию используется системный DNS, но иногда это невозможно по разным причинам. В таких случаях для получения IP-адреса выбранного DNS-сервера можно использовать Bootstrap. Вот два примера случаев, когда кастомный Bootstrap-сервер может помочь:
- Когда системный DNS-сервер, выбранный по умолчанию, не возвращает IP-адрес защищённого DNS-сервера и последний невозможно использовать.
- Когда наше приложение и сторонний VPN используются одновременно и невозможно использовать системный DNS в качестве Bootstrap.
Блокировать IPv6
На любой запрос к DNS-серверу на получение IPv6-адреса наше приложение возвращает пустой ответ, как будто этого адреса не существует. Новая функция позволяет не возвращать IPv6-адреса. Боюсь, что её дальнейшее описание получится слишком техническим: всё-таки настройка или отключение IPv6 — это исключительная прерогатива продвинутых пользователей. Если вы один из них, то наверняка и так знаете, что это за функция, если нет – то, честно говоря, и нет необходимости погружаться в эти детали.
Пост подходит к концу, а значит настало время для последней шутки.
Что Бэтмен сказал Робину, прежде чем они сели в машину?
Робин, садись в машину!
Нам очень жаль. Правда.
На сегодня всё. Скорее обновляйтесь, и надеемся, что вам понравится новая версия.
Как и обычно, полный список изменений можно увидеть на GitHub.
И помните, что мы всегда рады вашим отзывам. Поделитесь с нами впечатлениями в разделе комментариев ниже или в социальных сетях!
Бичовый вариант: поднимаем dnsmasq на VPN-сервере, в настройках dns для openvpn указываем внутренний адрес VPN-сервера.
Здесь dnsmasq будет работать как dns-прокси (перенаправлять днс-запросы наружу и держать у себя их кэш) с простым конфигом. Крутим его на VPN-сервере, конечно. Теперь задача заставить клиент использовать этот прокси. Если правильно помню, потом нужно указать dhcp-options DNS внутренний.адрес.сервера, script-security 2 в конфиге клиента.
У клиента должен стоять resolvconf. И несколько строчек в конфиг добавить. Гуглиться должно очень быстро.
Бичовый вариант: поднимаем dnsmasq на VPN-сервере, в настройках dns для openvpn указываем внутренний адрес VPN-сервера.
Здесь dnsmasq будет работать как dns-прокси (перенаправлять днс-запросы наружу и держать у себя их кэш) с простым конфигом. Крутим его на VPN-сервере, конечно. Теперь задача заставить клиент использовать этот прокси. Если правильно помню, потом нужно указать dhcp-options DNS внутренний.адрес.сервера, script-security 2 в конфиге клиента.
У меня нету доступа к VPN серверу.
Тогда выставляешь внешний DNS-сервер руками на клиенте (в networkmanager или что там у тебя) и указываешь именно для его адреса маршрут через VPN.
Дописываешь в свой клиентский конфиг OpenVPN следующее:
Не забудь отредактировать адрес DNS и VPN серверов (для последнего нужен адрес внутри VPN-сети).У меня нету доступа к VPN серверу.
Может у клиента проблема и не пушится просто.(вообще надо лог смотреть) Добавь в свой конфиг:
че это такое, первый раз такое костыльное решение вижу?
И каким образом в resolv.conf адреса поменяются? Че за брендятина?
И каким образом в resolv.conf адреса поменяются? Че за брендятина?
Нашел файл resolf.conf в папке /etc вот его содержимое domain lan search lan nameserver 192.168.0.1
Оно должно автоматом при подключении перезаписывать файл. Для этого тебе надо проделать манипуляции выше.
Дописываешь в свой клиентский конфиг OpenVPN следующее:
Попробовал так сделать, заменил в клиентском конфиге строчки: script-security 2 up /etc/openvpn/update-resolv-conf down /etc/openvpn/update-resolv-conf
это так и оставил DNS_IP=8.8.8.8 а здесь прописал IP VPN сервера VPN_SERVER_IP=(прописал IP)
поднял соединение, DNS утечка не устранена.
Тогда выставляешь внешний DNS-сервер руками на клиенте (в networkmanager или что там у тебя) и указываешь именно для его адреса маршрут через VPN.
У меня нету никаких networkmanager. Все делаю в терминале.
Пакет resolvconf стоит в системе?
заменил в клиентском конфиге строчки: script-security 2 up /etc/openvpn/update-resolv-conf down /etc/openvpn/update-resolv-conf
Не надо, делай все обратно. Посмотри внутрь скрипта
и увидишь, что оно там дергает resolvconf. Поставь пакет, и ставь решено.
Да, стоит еще до того как я создал этот пост на форуме.
Не надо, делай все обратно. Посмотри внутрь скрипта
А что именно надо внутри скрипта смотреть?
Обычно это работает - всегда. Что в логе у тебя при подключении?
Что в логе у тебя при подключении?
Логи предоставлю, только подскажи что ты имеешь виду. Лог это инфа которая в терминале отображается после того как я ввожу команду для подключения, или какой то файл куда записываются все логи?
Пробовал подключить VPN с помощью 3 разных провайдеров и вот оно чудо, на одном из них нет утечки по DNS, а у остальных есть. При этом никакие настройки не трогаю, просто по очереди запускаю файлы конфигурации командой sudo openvpn --config /провайдер1 и все работает, но когда пишу в терминал команду sudo openvpn --config /провайдер2 то идет утечка по DNS. Кто то может сказать почему так происходит?
script-security 2 up /etc/openvpn/update-resolv-conf down /etc/openvpn/update-resolv-conf
то DNS трафик пойдет через VPN провайдера, но этого не происходит. Как видите, еще есть остался маленький нерешенный вопрос.
При этом утечка происходит не рандомно, а конкретный файл конфигурации четко либо дает утечку DNS либо нет.
Скорее в серверном конфиге, где у тебя dnsleak, нет строчек про пуш dns. Поэтому ничего не прилетает со стороны сервера. Можешь самостоятельно руками отредактировать /etc/resolv.conf вписать туда публичный dns сервер. Или не пользуйся этими провайдерами.
Нужно предотвращать не утечку DNS в отдельности, но все утечки трафика вне VPN в целом.
Наиболее простой и понятный вариант это запретить весь исходящий трафик по умолчанию:
После чего разрешить только трафик до VPN сервера:
Где 192.0.2.17 — IP адрес VPN сервера.
А также траффик через само VPN соединение:
Где tun+ и tap+ — маски openvpn интерфейсов по умолчанию.
Нужно предотвращать не утечку DNS в отдельности, но все утечки трафика вне VPN в целом.
А какие могут быть утечки трафика вне VPN вообще?
Где tun+ и tap+ — маски openvpn интерфейсов по умолчанию.
А где брать эти маски openvpn?
И насчет iptables, я когда то поверхностно ознакомился с iptables, мне показалось это дело сложным, поэтому не сильно не вникал, помню что там некоторые вещи могут функционировать до первой перезагрузки. Поэтому спрошу, команды iptables которые ты мне написал будут действовать до первой перезагрузки ПК или всегда?
Нужно предотвращать не утечку DNS в отдельности, но все утечки трафика вне VPN в целом.
Кстати, если брать чисто VPN клиент, любой, не только OpenVpn, какие виды утечки трафика могут быть у клиентов кроме утечек DNS , IPv6 и привычных всем IPv4?
Шифрование трафика между вашим устройством и 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 продолжит свою активность и продвинет ситуацию вперёд.
Попытки взлома стали более умными, учитывая более широкое использование удаленного доступа к Интернет-соединениям. Наличие общедоступного подключения к Wi-Fi также привело к серьёзным уязвимостям в соединениях, предлагаемых поставщиками услуг Интернета (ISP). Более того, с учетом роста числа кибератак и атак программ-вымогателей на персональные компьютеры и корпоративные сети, конфиденциальность и безопасность данных, хранящихся в киберпространстве, поставлены под сомнение.
В этой статье мы подробнее обсудим утечки DNS, их симптомы в сети и способы их проверки.
Что такое DNS
DNS означает систему доменных имен, которая действует как база данных соответствий IP-адресов веб-сайтов, которые пользователь посещает через браузер. Когда вы вводите URL-адрес веб-сайта в браузере, интернет-провайдеры не могут напрямую подключить вас к сайту только по адресу домена. Вам нужен совпадающий или соответствующий IP-адрес серверам этого сайта для связи между вашим браузером и сайтом.
Поскольку запомнить абстрактные IP-адреса очень сложно, интернет-провайдеры используют DNS-серверы для хранения всех соответствующих IP-адресов веб-сайтов, которые вы хотите посетить. DNS-сервер автоматически сопоставляет доменное имя с IP-адресом и помогает вам получить доступ к веб-сайту.
Какой DNS-сервер вы используете?
Он принадлежит вашему интернет-провайдеру. Маршрутизатор Wi-Fi действует как путь для ваших DNS-запросов, которые достигают DNS-сервера, а затем передаются на веб-сайт.
Вы всегда можете проверить, какой DNS-сервер использует ваше устройство для получения IP-адресов веб-сайтов, которые вы просматриваете, посетив этот веб-сайт – Какой у меня DNS-сервер?
Что такое утечка DNS?
К сожалению, эти DNS-серверы подвержены кибератакам и могут раскрывать вашу личную информацию, касающуюся активности вашего браузера, злоумышленникам. Кроме того, информация видна интернет-провайдерам, что делает её менее безопасной, чем должна быть.
Иногда хакеры просматривают DNS-запросы, которые ваше устройство отправляет вашим интернет-провайдерам, или пытаются взломать DNS-сервера, чтобы получить дополнительную информацию о действиях пользователей в браузере, что, в конечном итоге, приводит к серьёзному нарушению или раскрытию ваших данных. Это называется утечкой DNS.
Каковы причины утечки DNS
Существует несколько причин утечки DNS:
Проблема в конфигурации сети
При подключении к Интернету убедитесь, что вы используете стабильное соединение. Часто случается, что соединение прерывается на несколько секунд до того, как будет установлено новое соединение. Это приводит к изменению IP-адреса. Когда это изменение произойдёт, вы можете подключиться к DNS-серверу вашего интернет-провайдера, даже если вы используете VPN. Хакеры могут проникнуть в соединение, поскольку ваша VPN не будет работать из-за внезапного изменения IP-адреса и раскрыть вашу информацию.
Утечки IPv6
Большинство IP-адресов состоят из четырех наборов трёхзначных кодов, например 111.111.111.111; это называется IPv4-адресом. Однако, Интернет медленно переходит в фазу IPv6, когда IP-адреса состоят из восьми наборов по 4 кода, которые также могут включать буквы.
В большинстве случаев, если вы отправляете запрос IPv6 на свой DNS-сервер для веб-сайта, у которого всё ещё есть адрес IPv4, в таком случае безопасность соединения может быть нарушена. Даже в случае соединения VPN запрос IPv6 обходит шифрование VPN, если VPN явно не поддерживает безопасность соединения IPv6.
Прозрачные DNS-прокси
VPN туннелирует ваше соединение через сторонний сервер, прежде чем достигнет DNS-серверов вашего интернет-провайдера, чтобы замаскировать ваш IP-адрес. Это также удерживает интернет-провайдеров от сбора и мониторинга ваших данных или действий в Интернете.
Иногда интернет-провайдеры используют отдельный или прокси-сервер для повторного перенаправления ваших запросов и веб-трафика на свои серверы – таким образом, интернет-провайдеры во многих случаях «заставляют» утечки DNS собирать информацию о пользователях.
Функция Windows «Smart Multi-Homed Name Resolution»
«Smart Multi-Homed Name Resolution» – это функция, представленная Windows версии 8.0. Эта функция позволяет подключаться к другим нестандартным серверам, отличным от того, который принадлежит соответствующим интернет-провайдерам, если серверы интернет-провайдеров перестают отвечать.
В Windows 10 эта функция позволяет принимать ответы на запросы DNS от любого самого быстрого доступного сервера. Так как это позволяет читать IP-адреса пользователей разными серверами, это может вызывать серьёзные проблемы, связанные с утечками DNS.
Проблема Teredo
Teredo – это технология, разработанная Mircosoft, которая позволяет пользователям находить IPv6-совместимые соединения с веб-сайтами и плавно переходить с IPv4 на IPv6. В этой технологии ваш запрос IPv4 туннелируется таким образом, что адреса веб-сайтов IPv4 выбирают их. Однако, этот процесс может обойти процесс туннелирования VPN и раскрыть ваш IP-адрес, что приведёт к утечке DNS.
Как предотвратить утечку DNS
Используйте эффективный VPN-сервис
Вы всегда можете предотвратить утечки DNS и связанные с этим проблемы, если используете правильный VPN-сервис. Имейте в виду, что это не должен быть бесплатный поставщик услуг VPN, поскольку они не обеспечивают достойной защиты от возможных утечек DNS и часто «грешат» разрывами соединения.
Используйте анонимные браузеры
Браузер Tor считается одним из самых безопасных браузеров для серфинга. Он использует луковую маршрутизацию, чтобы замаскировать или скрыть ваши данные и IP-адрес. Он перескакивает через три разных места, позволяя осуществлять обширный гео-спуфинг и скрывать большую часть информации, связанной с конкретным соединением.
Как проверить соединение на утечку DNS
Вы всегда можете проверить утечку DNS, посетив эти два веб-сайта:
Чтобы узнать, «герметично» ли соединение, посмотрите:
- Совпадает ли полученный IP-адрес с IP-адресом VPN, а не вашим реальным.
- Посмотрите, указано ли в результатах теста имя вашего интернет-провайдера, это сигнализирует об утечке DNS.
Не используйте инструмент проверки DNS, который предлагается в приложении VPN, поскольку он никогда не показывает правильный результат и не указывает на какие-либо дефекты в защищенном VPN-соединении.
Утечки DNS широко распространены, особенно с учетом того, что хакеры разрабатывают новые методы поиска возможных нарушений в сетях. Однако, использование правильного VPN и агрессивный мониторинг активности вашего браузера может помочь вам уменьшить их.
Мы постарались написать статью, которая по своей сути должна быть технической, языком, понятным обычному пользователю. Вам не нужно быть сисадмином, чтобы понять, о чём мы здесь пишем, но Вам нужны эти знания, чтобы избежать утечки DNS, которая может привести к уязвимости Ваших личных данных.
Утечки DNS случаются, когда пользователь или само устройство меняет сетевые настройки — к примеру, если был утерян сигнал Wi-Fi). Приложение VPN, как правило, упускает эту уязвимость. А если мы говорим про бесплатный VPN сервис — они грешат этим почти всегда.
Для того, чтобы Ваша конфиденциальность в Интернете была сохранена, необходимо, чтобы приложение VPN непрерывно скрывало Ваш IP-адрес. VPN туннель не должен иметь ни единого разрыва на протяжении всей сессии. Шифрование трафика должно идти постоянно на всём протяжении сессии. Ести соединение стабильное, приложение VPN, как правило, справляется с этой задачей. А если нет?
Поговорим о конкретных случаях, когда приложение VPN может упустить утечки DNS. Это происходит не только при самой очевидной причине — разрыве соединения с сервером VPN.
Утечки DNS происходят при переключении между точками доступа Например, у Вас есть ноутбук, Вы подключены к Интернету через точку доступа Wi-Fi. Приложение VPN активно с начала сессии, соединение стабильное (ещё бы — маршрутизатор в двух шагах от Вас), вроде бы всё под контролем.
Затем Вы подключаете кабель локальной сети, чтобы взаимодействовать с ещё одним домашним компьютером. Вроде бы ничего страшного не произошло, но конфигурация сети изменилась. Особенно если сам этот компьютер подключен к Интернету через обычный кабель, идущий в квартиру. Утечки DNS могут произойти не только в момент переключения соединения (о предпочтительном соединении мы поговорим далее), но и в том случае, если подключение второго компьютера не защищено.
(Не)тонкая настройка
В данном примере мы покажем эту тонкость на Mac OS, но и устройства под Windows уязвимы для этой утечки DNS ничуть не меньше. Итак, что нужно сделать. В момент, когда Вы подключены к точке доступа Wi-Fi и кабелю Ethernet, зайдите в системные настройки и откройте вкладку Сеть. На экране будет что-то вроде этого.
Что это означает? Подключены-то Вы к обеим сетям. Но есть одна предпочтительная. И если зайти в эту предпочтительную (вкладка Дополнительно), и затем в раздел DNS. сисадмины здесь уже всё поняли, остальным поясним.
Указанные во вкладке DNS-серверов IP-адреса выглядят как 10.x.x.x, 192.168.x.x, или 172.16.x.x-172.31.x.x. Что это значит: роутер в этой структуре играет роль DNS. С готовностью демонстрируя провайдеру все DNS-запросы пользователя (то есть Ваши). Если, конечно, Вы не используете приложение VPN.
Более того: не стоит расслабляться и в том случае, если в качестве DNS-сервера указан другой IP-адрес. Лучший выход — не использовать для выхода в Интернет столь сложные конфигурации. Или хотя бы запустите приложение VPN на обоих устройствах.
Утечки DNS: как их обнаружить?
Если Ваше приложение VPN имеет функцию, позволяющую проверить утечки DNS, самый простой способ — Вы не поверите: используйте эту функцию! Если приложение VPN, которое Вы используете, не может проверить утечки DNS самостоятельно — есть сторонние программы, позволяющие выполнить этот тест.
Критерий, показывающий, что утечки DNS не найдены (если это не указано в результате теста прямым образом) — в результате теста будет указан только один DNS-сервер.
Есть ещё один способ обнаружить утечки DNS – с помощью утилиты tcpdump. Имейте в виду, что это профессиональная программа с широким набором функций. Если Вы не владеете навыками системного администратора, лучше выберите предыдущий вариант — а то даже с инструкцией разбираться будете в несколько раз дольше, чем если использовать программу-тестер, специально созданную, чтобы показывать утечки DNS.
Утечки DNS: из-за чего они вообще случаются?
Суть проблемы в том, что операционная система выбирает серверы DNS, которые использовать в приоритетном режиме. А что такое приоритет? Это выбор из нескольких вариантов. То есть всегда, когда есть несколько вариантов подключения, система будет выбирать из них лучший — по её мнению.
Какое здесь самое безопасное решение? Если Вы используете приложение VPN (а мы надеемся, что это так), лучшее решение очевидно. Сделать приоритетом серверы, которые использует приложение VPN.
Как правило, приложение VPN считает, что всё ок — ведь оно по-прежнему отправляет зашифрованный трафик. Но если при этом DNS-запросы не шифруются — провайдер видит их без проблем.
Утечки DNS: как изучить поведение DNS-сервера с помощью утилиты Terminal Если Вы хотите лучше понять, как работают Ваши DNS-серверы — Вам поможет утилита Terminal для Linux. Вот как это сделать:
● Наберите scutil --dns
● Адрес IP, написанный рядом с именем сервера, будет тем самым адресом, который используется для запросов DNS.
Читайте также: