Stubby openwrt не работает

unixforum.org

Форум для пользователей UNIX-подобных систем

• Темы без ответов
• Активные темы
• Поиск
• Статус форума

OpenWrt: настройка dnsmasq

OpenWrt: настройка dnsmasq

Сообщение Bizdelnick » 26.06.2019 16:47

# nslookup unixforum.org ‘127.0.0.1#5453’
Server: 127.0.0.1
Address: 127.0.0.1#5453

Name: unixforum.org
Address 1: 109.68.191.155
*** Can’t find unixforum.org: No answer
root@OpenWrt:

# nslookup unixforum.org 192.168.1.1
;; connection timed out; no servers could be reached

# uci show dhcp.@dnsmasq[0]
dhcp.cfg01411c=dnsmasq
dhcp.cfg01411c.domainneeded=’1′
dhcp.cfg01411c.localise_queries=’1′
dhcp.cfg01411c.rebind_protection=’1′
dhcp.cfg01411c.rebind_localhost=’1′
dhcp.cfg01411c.expandhosts=’1′
dhcp.cfg01411c.authoritative=’1′
dhcp.cfg01411c.readethers=’1′
dhcp.cfg01411c.leasefile=’/tmp/dhcp.leases’
dhcp.cfg01411c.local=’/home/’
dhcp.cfg01411c.domain=’home’
dhcp.cfg01411c.serversfile=’/tmp/adb_list.overall’
dhcp.cfg01411c.server=’127.0.0.1#5453′
dhcp.cfg01411c.noresolv=’1′
dhcp.cfg01411c.dnssec=’1′
dhcp.cfg01411c.dnsseccheckunsigned=’1′
dhcp.cfg01411c.localservice=’0′
dhcp.cfg01411c.nonwildcard=’0′
root@OpenWrt:

# grep -v ‘^$\|^#’ /etc/dnsmasq.conf
root@OpenWrt:

Что здесь не так?

P. S. Да, я в курсе, что я неправ в отношении .home.

Источник

Stubby

Overview

An unprotected setup without Stubby might look like this:

local	→	internet
dnsmasq on 53	→	unencrypted dns on 53

A setup protected with Stubby will then look like this:

local	→	local	→	internet
dnsmasq on 53	→	stubby on 5453	→	encrypted dns on 853

We’ll basically be putting Stubby in between dnsmasq and the internet, leaving most things untouched so that dnsmasq will continue to work in OpenWrt.

Installation

Configuration

Stubby can be configured directly via /etc/stubby/stubby.yml or via /etc/config/stubby when using uci. The README within the packages repository contains further information.

The default listening port for stubby is 5453 (IPv4 and IPv6 on localhost).

Note that this does not prevent clients in LAN to access unencrypted DNS directly (for example if they ignore the advertised router DNS through DHCP , because of a static DNS setting).

To prevent local leaks or delays, make sure stubby is the only server that is being forwarded to, and block TCP and UDP output to port 53 in wan.

You might want to add /etc/stubby/ to the list of config files that should be preserved on upgrade / backup!

Troubleshooting

Make sure the service is enabled.

Make sure the trigger option matches the name of your WAN interface.

Verify the user/group and owner/permissions are set up properly.

External Links

• Last modified: 2020/06/15 09:00
• by vgaetera

Self-registration in the wiki has been disabled.
If you want to contribute to the OpenWrt wiki, please post HERE in the forum or ask on IRC for access.

Except where otherwise noted, content on this wiki is licensed under the following license:
CC Attribution-Share Alike 4.0 International

Источник

DoT with Dnsmasq and Stubby

This article relies on the following:

Introduction

Goals

Command-line instructions

Install the required packages. Enable DNS encryption.

Testing

Use nslookup to verify that domain name resolution works.

Test DNSSEC validation.

Troubleshooting

Collect and analyze the following information.

Extras

Web interface

If you want to manage the settings using web interface.

DoT provider

Stubby is configured with Cloudflare DNS by default. You can change it to Google DNS or any other DoT provider including your own DoT server with Nginx. Make sure the resolvers support DNSSEC validation if necessary. Specify several resolvers to improve fault tolerance.

DNSSEC validation

• Last modified: 2021/09/27 05:31
• by vgaetera

Self-registration in the wiki has been disabled.
If you want to contribute to the OpenWrt wiki, please post HERE in the forum or ask on IRC for access.

Except where otherwise noted, content on this wiki is licensed under the following license:
CC Attribution-Share Alike 4.0 International

Источник

Настройка точечного обхода блокировок на роутере с OpenWRT

Думаю, не стоит объяснять, почему проблема блокировок в рунете стоит настолько остро. И дело даже не в пресловутых сериалах на торрентах. Если не обходить блокировки, то банально сложно работать: то bugs.python.org заблокирован, то документация по нужному тебе сервису недоступна, то какой-нибудь репозиторий с пакетами отвалился, из-за чего у тебя внезапно перестают собираться контейнеры, то LinkedIn пишет письма на почту, а зайти на него ты не можешь. Например, вот здесь можно найти список опенсорс-проектов, которые были заблокированы Роскомнадзором. Это всё тянется еще с тех времён в 2018 году, когда Роскомнадзор пытался накрыть Telegram ковровыми блокировками, блокируя без разбора всех направо и налево. Какое-то время я пытался с этим жить, игнорируя проблему, но однажды мое терпение лопнуло, во мне пробудился дух цифрового сопротивления, и я решил настроить себе VPN — да так, чтобы это работало на всех моих устройствах сразу.

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

Так как большая часть моего трафика всё-таки ходит к незаблокированной части интернета, то логично пускать через VPN лишь тот трафик, который в этом нуждается. Ну нет ведь смысла гонять через VPN просмотр видео на YouTube или какую-нибудь игру? В итоге получится просто более медленный доступ, а профита никакого.

Стоит отметить, что если вам нужен обход блокировок только на одном устройстве, там вам намного проще будет настроить VPN именно на нём. У многих провайдеров VPN есть программы-клиенты, которые в несколько кликов по красивым кнопкам настроят вам всё, что нужно — просто погуглите, сравните цены и условия. Ещё можете посмотреть в сторону таких бесплатных проектов, как АнтиЗапрет.

Опишу свой процесс настройки роутера на OpenWRT с точечным обходом блокировок. Мне уже приходилось делать это пару раз (то переезд со сменой провайдера, то смена роутера), и вот на третий раз я решил наконец задокументировать этот процесс, чтобы в следующие разы было легче. Может и ещё кому пригодится.

Роутер и прошивка

OpenWRT — это опенсорсный проект, который разрабатывает прошивки для роутеров на основе Linux. В той или иной мере, пожалуй, поддерживаются все существующие девайсы. Внутри есть даже свой собственный пакетный менеджер. Так как роутер с OpenWRT — это почти настоящая линукс-машина, то открывается огромное поле для различных извращений — файловые шары, торрент-клиенты, блокировка рекламы на уровне роутера, VPN — да что угодно.

Мой нынешний роутер — это Xiaomi Mi WiFi Router 3G. Выбрал его, потому что в нём достаточно мощи, чтобы на нём хорошо работала OpenWRT. Да и вообще, Mir3G — это, похоже, один из самых популярных девайсов в тусовке людей, которые занимаются дрессировкой роутеров, так что в сети по нему уже есть много мануалов и обсуждений на форумах. Если захотите купить такой же, то будьте аккуратны с конкретной моделью — их две под одним названием, а хорошая только та, у которой есть порт USB3. Такой роутер должно быть несложно купить на Авито или других досках объявлений.

У меня на данный момент установлена почти последняя версия прошивки:

Прошивка OpenWRT и базовая настройка роутера выходит за рамки этой статьи. Поищите мануалы для вашего роутера. Далее предполагается, что у вас уже есть роутер с OpenWRT, подключенный к интернету, и к нему настроен доступ по SSH.

Блокировки

Грубо говоря, существует два типа блокировок:

1. по доменным именам;
2. по IP-адресам.

Нам нужно победить оба. Разберёмся с каждым из них по порядку.

Шаг 1. Шифрованный DNS

DNS (Domain Name System) — это распределенная система (нет, это не сеть магазинов), состоящая из множества серверов по всему миру, которая позволяет вашему компьютеру преобразовать человекочитаемое имя сайта в машиночитаемый IP-адрес, например, из github.com получить 140.82.121.3 . Этот процесс называется «разрешением» или «резолвингом» доменного имени.

Блокировка по доменным именам зачастую реализуется провайдером следующим образом: ваш роутер по умолчанию использует DNS-сервер, который контролируется провайдером и для заблокированных доменных имён возвращает специальный адрес сайта-заглушки. Именно это происходит, когда вы видите в браузере «доступ к ресурсу ограничен в соответствии со 149-ФЗ».

Кажется, что решение очевидно — просто не пользоваться DNS-сервером провайдера, а использовать, например, Google DNS, IP-адреса которого уже стоит знать наизусть как считалку — 8.8.8.8, 8.8.4.4 . Раньше это действительно работало, но сегодня провайдеры уже не дадут вам так просто себя обмануть.

Поскольку DNS — это очень старый протокол, в котором никак не было предусмотрено шифрование от слова «вообще», у провайдеров есть возможность перехватывать ваши запросы и подменять ответы, вставляя свой сайт-заглушку, даже если запрос шёл, например, к Google DNS. Именно этим они и занимаются. По сути, провайдер проводит против вас атаку DNS hijacking.

Вот как это работает, если всё хорошо. В таком сценарии можно даже не заметить этого «человека посередине» в лице вашего провайдера:

А вот так это работает, когда всё плохо. Провайдер наверняка даже не отправляет запрос к DNS-серверу, которому он предназначался, а просто сразу же возвращает ответ, подставляя адрес своей заглушки:

Но по-настоящему эффективное решение есть. Если провайдер не сможет увидеть, к какому домену происходит обращение, то не сможет и подменить ответ. А ещё лучше, если он вообще не будет знать, что происходит резолвинг имени. Этого можно достичь шифрованием.

Совсем недавно стали появляться шифрованные версии протокола DNS — DNSCrypt, DoT (DNS-over-TLS) и DoH (DNS-over-HTTPS). Судя по всему, именно последний из них (DoH) получит наибольшую популярность. При использовании этого протокола DNS-запрос складывается внутрь HTTPS-запроса, который, само собой, зашифрован. Для человека посередине, который перехватит такой трафик, это будет выглядеть как просто один из миллиарда шифрованных HTTP-запросов к Google или Cloudflare.

DNS-over-HTTPS мы и собираемся настроить в первую очередь. Ничего принципиально нового я не скажу, вся информация взята с соответствующей страницы вики OpenWRT.

Обновим список пакетов. Эту команду нужно выполнять после каждой перезагрузки роутера перед установкой пакетов:

Установим необходимые зависимости, которые в связке позволят принимать DNS-запросы от клиентов в локальной сети и отправлять их во внешний интернет, замаскированными под HTTPS-запросы. Третий пакет — это просто плагин для веб-интерфейса OpenWRT LuCI, чтобы можно было через GUI настраивать поведение DoH:

Чтобы плагин для LuCI заработал, нужно сделать выполнить вот такую команду:

Готово! Теперь на компьютере, подключенном к роутеру, можно проверить как это работает:

Обратите внимание, что адреса возвращаются разные: до настройки DoH — неправильный, это результат подмены адресов провайдером, а после — правильный. Можно считать это маленькой победой!

По умолчанию используются DNS-over-HTTPS сервера от Google и Cloudflare — очень разумный выбор, потому что на этих двух компаниях держится добрая половина глобального интернета, и их блокировка наверняка приведёт к катастрофическим последствиям, так что блокировать их, надеюсь, никто не будет. Если же хочется сменить используемые сервера, то сделать это теперь можно через веб-интерфейс: Services > DNS HTTPS Proxy .

Сам по себе обход блокировок по DNS вряд ли даст ожидаемый эффект, потому что, как правило, в довесок к доменному имени, ресурс блокируется еще и по IP-адресам — видимо, для надежности. Это следующий тип блокировок, которые нужно победить.

Стоит упомянуть про побочные эффекты от такой настройки — могут стать недоступными различные внутренние ресурсы провайдера. Например, когда у меня кончается интернет и я забываю его оплатить, провайдер просто не может меня переадресовать на страницу, куда он обычно направляет своих забывчивых абонентов. Для меня выглядит это всё так, будто интернет просто пропал, без каких-либо объяснений. Я даже первый раз из-за этого чуть не поругался с поддержкой, а оказалось, что это я сам дурак. Что ж, просто приходится платить заранее.

Если нравится статья, то подпишитесь на уведомления о новых постах в блоге, чтобы ничего не пропустить! А ещё читайте другие мои посты!

Шаг 2. Настройка VPN WireGuard

Для того, чтобы обходить блокировки по IP-адресам, придётся настроить VPN — другого способа нет. VPN «спрячёт» от провайдера ваши IP-пакеты так, что он не будет знать куда именно они направляются и что в себе содержат. В качестве протокола предлагаю использовать WireGuard — легковесный VPN-протокол, который к тому же довольно легко настраивать.

Всё описанное дальше вдохновлено и по сути является пересказом вот этой замечательной статьи на Хабре с некоторыми (минимальными) дополнениями от меня.

VPN — это клиент-серверный протокол. Наш роутер будет клиентом, но также нам обязательно нужен сервер. Можно либо поднять свой VPN-сервер самостоятельно (смотрите инструкцию в статье по ссылке выше, это не сложно), либо оформить подписку на какой-нибудь готовый VPN-сервис. Я пробовал оба варианта, но поддерживать свой VPN-сервер оказалось достаточно трудозатратно, и это тоже, как ни странно, стоит денег. Сложнее всего найти хостинг для своего VPN с незаруиненной репутацией. Проблема, с которой я столкнулся, заключалась в том, что все дешевые хостинги уже имеют плохую репутацию (спасибо вам, господа спамеры), и некоторые ресурсы, типа Пикабу (который тоже, как выяснилось, немножко заблокирован), сразу же заранее отвечают ошибкой 403. Намного проще купить готовый VPN, и пусть лучше кто-то другой за меня беспокоится о том, чтобы мне были доступны все нужные мне сайты.

В последнее время появляется очень много VPN-сервисов, которые работают по протоколу WireGuard — это нынче горячая тема. Недавно поддержка WireGuard была добавлена в основной состав ядра Linux. Погуглите, выбор сервисов действительно есть. Сейчас я пользуюсь RedShieldVPN, и меня пока что всё устраивает.

Бонус для читателей: при регистрации по этой ссылке вам подарят месяц бесплатного VPN.

Дальше буду описывать процесс для RedShieldVPN, но, думаю, для других подобных сервисов процесс должен быть похожим.

Переходим в раздел WireGuard, авторизуемся, выбираем страну и скачиваем конфиг. Я обычно выбираю какую-нибудь европейскую страну, чтобы пинг был приемлемым. В этот раз возьму Финляндию.

Вот примерно такой файл конфигурации скачался (ключи я заменил):

Переключимся на роутер и установим там нужную зависимость:

Дальше нужно настроить сеть. Это происходит в файле /etc/config/network . Открываем его при помощи vi (если не умеете пользоваться этим редактором, то лучше предварительно почитайте что-нибудь для подготовки психики) и дописываем в конец две секции вот такого содержания:

Приватный и публичный ключи замените соответствующими значениями из конфига. Поле list addresses заполняется IPv4-адресом из строчки Address в конфиге, а IPv6 адрес мы просто игнорируем — позже станет понятно почему. Поле Endpoint из конфига WireGuard распадается, соответственно, в поля endpoint_host и endpoint_port в конфиге OpenWRT. Остальные поля статичные.

Перезапустим сеть на роутере:

Если команда wg show выводит что-то подобное, то всё идёт хорошо.

Шаг 3. Скрипт для сбора списков заблокированных адресов

Это возможно благодаря крутейшему сервису antifilter.download, который обрабатывает выгрузки Роскомнадзора и отдает их в виде списков IP-адресов в машиночитаемых форматах. Мы настроим периодическую выгрузку списков заблокированных адресов с antifilter.download, чтобы всегда иметь актуальную информацию о блокировках. По моему опыту обновлять этот список раз в сутки (например, ночью) вполне достаточно.

Кроме того, нам нужно настроить файрволл роутера, чтобы он помечал пакеты, которые направляются к заблокированным адресам, специальным маркером. Такие маркированные пакеты должны маршрутизироваться роутером через VPN.

Начнём со скрипта, который реализует эту логику по обновлению списков заблокированных адресов.

Создадим файл /etc/init.d/hirkn со скриптом следующего содержания:

Этот скрипт скачивает два списка заблокированных адресов — один в виде сетей (иногда РКН блокирует адреса целыми подсетями), другой — обобщенный список отдельных заблокированных адресов. За счёт обобщения в небольшие подсети он содержит не миллионы строк, а всего лишь что-то около 15 тысяч. Нам нужны оба списка, они не пересекаются между собой. Файлы сохраняются в каталог /tmp , который в OpenWRT хранится в оперативной памяти — это должно работать быстро. В конце скрипт перезапускает файлволл. Настройка файлволла будет происходит позже.

Добавим этому скрипту права на выполнение:

Добавим скрипт в «автозапуск», чтобы он выполнялся при включении роутера после всех остальных скриптов:

Через cron запланируем выполнение этого скрипта раз в сутки:

В открывшемся редакторе нужно добавить на новой строке:

На crontab.guru можно посмотреть объяснение этой строчки.

Включим cron , потому что по умолчанию в OpenWRT он выключен:

Убедимся, что скрипт работает.

Если файлы со списками заблокированных адресов появились, то всё ок:

Шаг 4. Дальнейшая настройка

Теперь осталось настроить роутер так, чтобы он правильно маршрутизировал пакеты через VPN-туннель.

Создадим таблицу маршрутизации для VPN, добавив в файл /etc/iproute2/rt_tables строчку следующего вида:

Добавим дефолтный маршрут для VPN через туннельный интерфейс:

Чтобы сделать это изменение постоянным, чтобы оно переживало перезагрузки роутера, создадим файл /etc/hotplug.d/iface/30-rknroute с вот таким содержимым:

В файл /etc/config/network , который мы уже редактировали в процессе настройки WireGuard, добавим правило, которое будет перенаправлять маркированные пакеты в таблицу маршрутизации VPN:

Теперь приступим к настройке файрволла. Это самая важная часть логики, которая просматривает списки заблокированных адресов, и маркирует пакеты. В файл /etc/config/firewall допишем несколько абзацев:

Первый из них настраивает зону для VPN — из неё разрешён лишь выход пакетов и включён маскарадинг.

Второй абзац разрешает переход из зоны lan , где по умолчанию находятся все устройства, подключенные к роутеру, в зону для VPN.

Третий и четвертый абзацы заставляют файрволл загрузить файлы со списками заблокированных адресов и распихать по хеш-таблицам в памяти. Как известно, поиск по хеш-таблице происходит за константное время, так что роутер сможет эффективно определять направляется ли пакет к заблокированному адресу или к обычному.

Пятый и шестой абзацы отвечают за маркировку пакетов: «если пакет направляется на заблокированный адрес, то добавим ему пометку 0x1 «.

И запустим наш скрипт:

После этого трафик к заблокированным сайтам должен побежать через VPN. Если нет, то попробуйте перезагрузить роутер.

Шаг 5. Отключаем IPv6

Этот шаг мой самый нелюбимый, потому что я за всё новое и против всего старого. По моему глубокому убеждению IPv4 уже давно должен умереть и быть вытеснен шестой версией протокола. К сожалению, дела у IPv6 пока идут не так гладко, как хотелось бы (сейчас он занимает всего около 30% процентов трафика).

Проблема в том, что antifilter.download выдаёт только заблокированные IPv4 адреса. Это значит, что наш обход блокировок не будет работать по IPv6. Если разрешить вашему роутеру работать по IPv6, то многие ваши устройства предпочтут открывать сайты по IPv6 либо напарываясь на страницы с блокировками от провайдеров, либо просто получая ошибки подключения по таймауту.

Отключаем IPv6 (команды взяты отсюда):

После этого может потребоваться ещё одна перезагрузка роутера, чтобы он перестал раздавать вновь подключенным устройствам IPv6-адреса.

Заключение

Вот как-то так можно при помощи несложных (ладно, сложных) манипуляций настроить свой роутер на точечный обход блокировок. Все незаблокированные сайты работают как обычно, а заблокированные — через VPN. С такой конфигурацией можно полностью забыть про мелкие пакости от Роскомнадзора и начать, наконец, жить 🙂

Источник