Что это дает ignore wan dns в настройках вв цке
После поднятия защищенного канала OpenVPN весь клиентский трафик как правило идёт через него. На этапе установки соединения OpenVPN-сервер изменяет на клиенте шлюз по умолчанию, оправляя ему команду push "redirect-gateway". В этом нет никакой ошибки и в большинстве случаев, подобная настройка на стороне сервера вполне логична, да и пользователю не нужно вручную прописывать маршруты и весь трафик получается защищённым.
Но, допустим, что мы просто хотим предоставить удалённым пользователям возможность работы с ресурсами внутри сети. Зачем гонять весь трафик через защищённое соединение, когда требуется только доступ к терминальному серверу или сетевому принтеру? Пусть спокойно лазят в интернете и качают торренты, используя собственное подключение, а защищённый канал используется исключительно по прямому назначению, не тратя драгоценных ресурсов на обработку лишней информации.
На стороне OpenVPN сервера, за переопределение шлюза и DNS сервера у клиента отвечают следующие строки конфигурационного файла:
push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"
Достаточно в конфигурационном файле клиента отфильтровать нужную опцию, указав её в качестве аргумента для pull-filter . Опция фильтрации параметров доступна начиная с версии 2.4 и выше и может использоваться только на клиентах. Для более старых версий OpenVPN следует воспользоваться другим методом, описание которого можно найти перейдя по ссылке чуть выше.
Чтобы игнорировать изменение шлюза OpenVPN в конфигурационный файл клиента добавляем такую строку:
То был конкретный пример из моего конфига, а вообще функция фильтрации параметров, полученных с сервера, выглядит так:
--pull-filter accept|ignore|reject текст
Флаг действия accept разрешает опцию, ignore удаляет ее, а reject помечает как ошибочную и запускает SIGUSR1. Фильтры могут вызываться несколько раз и применяются в указанном порядке. Несколько примеров:
--pull-filter ignore "route"
Удаляет все push-опции, содержащие текст route , в том числе и route-gateway . Если в тексте параметра присутствует пробел, его следует заключать в кавычки:
--pull-filter accept "route 192.168.1."
--pull-filter ignore "route "
Будут удалены все маршруты, которые не начинаются с 192.168.1. Таким же образом можно отказаться от переназначения DNS-серверов при подключении к OpenVPN:
Стоит также обратить внимание, что reject может привести к повторному подключению, поэтому для игнорирования параметра, переданного сервером лучше использовать команду ignore .
ПыСы: ну и раз мы отказались от предложенного сервером маршрута по умолчанию, то на клиенте можно прописать недостающие маршруты из удалённой сети (если таковые требуются). Делается это просто:
Подписывайтесь на канал Яндекс.Дзен и узнавайте первыми о новых материалах, опубликованных на сайте.
В статье разъясняется, как настроить роутер с прошивкой DD-WRT, чтобы он подключался к сети поставщика услуг Интернет Билайн по проводу (витая пара) по протоколу L2TP. Используются новые прошивки 2021 года.
Введение.
Для начала определитесь, нужен ли вам L2TP, и нужен ли вам Билайн вообще. Билайн последние лет 10 переводит пользователей на подключение по IPOE, по сути DHCP + привязка по MAC адресу. Для определения возможности использования IPOE позвоните в службу техподдержки, которая прояснит этот вопрос исходя из адреса подключения. Было время в 2020 году — в техподдержке невозможно было поговорить с человеком, отвечал робот, и это
Билайн как поставщик услуг весьма плох, если можете выбрать кого-то получше, то так и сделайте. Но кого?
Техподдержка Билайна отказывается от обсуждения настройки DD-WRT: ссылка.
Nikolai_d
to Niklv Здесь есть нормальные инженеры?
NikIv
Странный вопрос вы задаете, в принципе здесь все такие же как и вы, а инженеры Билайна не занимались и никогда не будут заниматься работой прошивки ddwrt на протоколе L2TP.
Тема «Настрока DD-WRT для Билайн» умерла.
Да-да, «Настрока», с 23 сентября 2010 г. не исправили.
Хорошо, начинаем настройку.
Настройка подключения к Интернету без роутера.
Для начала выйдем в Сеть без роутера. Как настраивать винду — написано на сайте Билайна.
Что делать для Линукса на примере openSUSE:
Свободные прошивки
Основных свободных прошивок для роутеров — две: DD-WRT и OpenWRT. По-моему, DD-WRT легче настраивать, поэтому использую её. Не для всех роутеров есть свободные прошивки, см. сайты прошивок для определения наличия оной. Множества поддерживаемых роутеров у этих двух проектов почти совпадают, но всё же есть различия. И то, что не поддерживается одним, может поддерживаться другим(и). Есть и другие проекты, и прошивки от отдельных людей, ищите их в Сети. Которые видел прошивки — все на Линуксе, где же NetBSD и прочие?
Плюсы и минусы свободных прошивок
- Более надёжны, чем заводские.
- Быстрее работают (бывает, что в 2 раза).
- Есть возможности, недоступные в заводских.
- Есть поддержка после окончания заводской.
- Сложнее настраивать.
- Устройство снимается с гарантии (если таковая ещё имеется).
Получение прошивки DD-WRT
DD-WRT и L2TP
Сложности с подключением по L2TP у DD-WRT начались несколько лет назад, когда создатели DD-WRT перешли на работу с DNSMasq. Эта программа наверное хороша, но настройка L2TP не доработана (или — плохо описана). Старые руководства написаны для старых выпусков прошивки, и не получается по ним настроить роутер на работу.
Шаг 2. Настраиваем роутер на подключение по L2TP. Руководства есть в Сети, приведу одно из:
Вкладка «Setup» — «Basic Setup»:
1. WAN Connection Type:
2. Optional Settings
DHCP Type — DHCP Server
DHCP Server — Enable
Start IP Address — адрес, с которого начнётся раздача сетевых адресов
Maximum DHCP Users — наибольшее количество раздаваемых адресов
. Количество выделяемых адресов дложно укладываться в маску.
Client Lease Time — на какое время в минутах выдавать адрес (1440 минут = 24 часа)
Static DNS — по нулям
WINS — по нулям
Use DNSMasq for DHCP — больше нет такого свойства
Use DNSMasq for DNS — Yes
DHCP-Authoritative — No (Не размещайте в сети более одного сервера с «DHCP-Authoritative». )
Recursive DNS Resolving — больше нет такого свойства
Forced DNS Redirection — No
Вкладка «Services» — «Services»:
DHCP Server
Use JFFS2 for client lease DB — (Not mounted)
Use NVRAM for client lease DB — не отмечено
Used Domain — LAN & WLAN — поменял с WAN
LAN Domain — mydomain (вписал строковый параметр, не использовать «local» т.к. оно есть служебное слово)
Additional DHCPd Options — пусто, ничего не писал.
SSHd — Disable
Telnet — Disable
Вкладка Security — Firewall:
SPI Firewall — Enable
Все защиты включил — работает.
Вкладка Security — VPN Passthrough:
IPSec Passthrough — Enable
PPTP Passthrough — Enable
L2TP Passthrough — Enable
Всё — включено, иначе не создавалось соединение L2TP.
Вкладка «NAT / QoS» — «UPnP»:
И — оно не работает. Соединение L2TP не поднимается.
Шаг 3: Отключаем использование DNSMasq как сервера DNS. Соединение L2TP поднимается, выхода на внешние сайты — нет.
Шаг 4: В свойствах подключения на компьютере (сетевого адаптера) добавляем DNS серверы Билайна 85.21.x.x и 213.234.x.x (вкладка IPv4 у NetworkManager, поле «Другие DNS серверы:»). Соединение L2TP — есть, выход на внешние сайты — есть.
Шаг 5: Включаем обратно использование DNSMasq как сервера DNS. И всё работает «волшебным образом».
Для более нового роутера с ядром Linux 4.4 всё хорошо работает, для старого DIR-300NRU с ядром 3.2 — есть были разрывы соединения L2TP каждые 30 минут, сейчас вроде исправили.
В итоге D-Link DIR-300NRU rev. B (300N Ru) тянет 50 Мбит/с по L2TP в обе стороны (на заводской прошивке было около 25 Мбит/с с разрывами и зависаниями). Или больше — есть ограничение подключения 50 Мбит/с.
Шифрование трафика между вашим устройством и 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 продолжит свою активность и продвинет ситуацию вперёд.
В последнее время многие пользователи столкнулись с проблемами в работе домашнего или офисного интернет-соединения. Это выражается в периодических дисконектах или лагах во время передачи данных.
Скорее всего, это может быть связано с использованием DNS-серверов Google и Cloudflare. Согласно заявлению Роскомнадзора, эти сервера вскоре могут быть заблокированы в России.
Сейчас расскажем, как сменить параметры DNS-сервера и не столкнуться потом с неработающим интернетом на смартфоне, компьютере или вообще всех устройствах, подключенных к вашему роутеру.
Как убрать DNS-адреса из настроек роутера
Делать это необходимо, если вы самостоятельно прописывали адреса серверов на используемом маршрутизаторе, чтобы они применялись для всех гаджетов в домашней или офисной сети.
1. Определите IP-адрес используемого роутера. Для большинства моделей по умолчанию используется:
Маркировка с используемым адресом обычно нанесена на самом роутере, данные можно найти в используемом приложении для настройки сети.
2. Перейдите по IP-адресу вашего роутера в браузере на любом устройстве, которое на данный момент подключено к сети (смартфон, планшет или компьютер).
Если сохраненных данных нет, возможно, используются стандартные учетные данные, которые тоже нанесены на корпусе маршрутизатора.
4. Найдите раздел с настройкой DNS. Параметры могут находиться по пути:
5. Найдите два поля с параметрами DNS. Обычно они маркируются Первичный\Вторичный, Основной\Дополнительный, DNS1\DNS2 или как-то еще.
6. Удалите используемые параметры DNS серверов Google или Cloudflare.
7. Сохраните параметры и перезагрузите роутер для вступления изменений в силу.
Как убрать DNS-адреса из настроек в macOS
Если вы прописывали адреса серверов не в роутере, а на каждом используемом девайсе, то и удалять их придется на каждом устройстве. Алгоритм действия на Mac следующий:
■ В левой панели выберите используемое интернет-соединение. Это может быть проводной Ethernet-канал или Wi-Fi.
■ На вкладке DNS удалите или измените используемые адреса для серверов.
■ Нажмите ОК, а затем Применить.
■ Для вступления изменений в силу отключитесь от интернета и подключитесь заново.
Как убрать DNS-адреса из настроек в Windows
При использовании Windows-компьютера нужно делать следующее:
□ Откройте Панель управления (через меню Пуск или свойства компьютера).
□ В окне Просмотр основных сведений о сети и настройка подключений найдите активное подключение Wi-Fi или Ethernet.
□ Выберите активное подключение и нажмите кнопку Свойства.
□ В открывшемся окне выберите протокол IP версии 4 (TCP/IPv4) и нажмите Свойства.
□ На вкладке Общие удалите или измените используемые адреса серверов DNS.
□ Для вступления изменений в силу отключитесь от интернета и подключитесь заново.
Как убрать DNS-адреса из настроек на iPhone или iPad
Чтобы внести нужные изменения в параметры сетевого подключения iOS, делайте следующее:
● Перейдите в раздел Настройка DNS.
● Удалите или измените используемые адреса серверов DNS
● Нажмите Сохранить и переподключитесь к сети для вступления изменений в силу.
Как убрать DNS-адреса из настроек в Android
При использовании Android-смартфонов, планшетов или ТВ-приставок, менять настройки нужно следующим образом (название и расположение пунктов меню может отличаться):
○ Выберите активное подключение и нажмите Изменить сеть.
○ В разделе DNS-1/DNS-2 удалите или измените используемые адреса серверов DNS.
○ Нажмите Сохранить и переподключитесь к сети для вступления изменений в силу.
Какие сервера DNS использовать вместо Google и Cloudflare
Многие интернет провайдеры и поставщики сетевых услуг самостоятельно рекомендуют пользователям определенные настройки DNS или настраивают автоматическое получение DNS. Чаще всего эти параметры указываются при настройке подключения.
Актуальные данные можете уточнить в службе поддержки своего провайдера.
Если самостоятельно решили указать какой-либо сторонний DNS-сервер, можете использовать такие варианты:
Экспериментируйте и выбирайте подходящий сервис, который устроит по скорости работы и стабильности подключения.
(23 голосов, общий рейтинг: 4.22 из 5)
Читайте также: