Openwrt curl не работает

curl / polarssl handshake error

Reported by:	anonymous	Owned by:	developers
Priority:	normal	Milestone:	Chaos Calmer 15.05
Component:	base system	Version:	Trunk
Keywords:	curl polarssl	Cc:

Description

Trying to download a zeustracker domain blocklist with curl (ca-certificates installed) failed in cc:

Same download works fine with curl/debian:

Attachments (0)

Change History (37)

comment:1 Changed 3 years ago by hauke

• Resolution set to worksforme
• Status changed from new to closed

This works for me, you have to specify that you want to trust all certs if you do not have a certificate store installed.

Which OpenWrt version are you using?

comment:2 Changed 3 years ago by dibdot

Thanks for looking into this. I’ve done a retest with current snapshot and with ca-certificates installed .

Test with curl (still broken):

Test with wget (works fine):

So it’s still an issue (at least for me).

comment:3 Changed 3 years ago by dibdot

• Resolutionworksforme deleted
• Status changed from closed to reopened

comment:4 Changed 3 years ago by dibdot

Other https connections are working fine (example for kernel.org), even with curl:

But as I said in my first post, curl did work with debian . so it seems to be an openwrt specific problem.

comment:5 Changed 3 years ago by anonymous

comment:6 Changed 3 years ago by chris5560

Last entry seems to be fixed. Missing certificate files.

comment:7 Changed 3 years ago by dibdot

Retested with a fresh build of r46484 . error still persistent.

comment:8 Changed 2 years ago by DeusExMachina

I tried to build Barrier Breaker 14.07 with polarssl and curl for the WGT634U as Legacy Unit. Does work, however, I get the same error described here, even though certificates are installed:

root@OpenWrt:/# curl -V
curl 7.38.0 (mipsel-openwrt-linux-gnu) libcurl/7.38.0 PolarSSL/1.3.9
Protocols: http https
Features: Largefile SSL

Error: «* ssl_handshake returned — PolarSSL: (-0x7280) SSL — The connection indicated an EOF
curl: (35) ssl_handshake returned — PolarSSL: (-0x7280) SSL — The connection indicated an EOF»

even if used with -k

Any Idea? And how about backporting the solution to the current stable release — please? 🙂

comment:9 Changed 2 years ago by dibdot

Retested with a fresh build of r46773 (incl. musl and mbedTLS-Update) . error still persistent.

comment:10 Changed 2 years ago by dibdot

Retested with current trunk — even the download with curl works quite fine.

Thanks a lot, ticket can be closed!

comment:11 Changed 2 years ago by nbd

• Resolution set to fixed
• Status changed from reopened to closed

comment:12 Changed 2 years ago by dibdot

• Resolutionfixed deleted
• Status changed from closed to reopened

Sorry, I have to reopen this ticket. Bug still exists on ar71xx devices (checked with wdr4300 and dir835), working now for raspi2 (bcm2709).

comment:13 Changed 2 years ago by anonymous

Also confirmed broken in trunk (DD) on Archer C7 v2.

comment:14 Changed 2 years ago by saidi

Same issue on trunk, fixed with:
opkg install ca-certificates

comment:15 Changed 2 years ago by anonymous

Still having the same issue trying to update now-ip, even with ca-certificates. ar71xx 15.05

comment:16 Changed 2 years ago by anonymous

Hello. I had similar problem with libcurl and polarssl without ca-certificates. I was using custom path with custom ca-bundle.crt.

But I’ve received error # 77 (Error: No such file or directory) from curl_easy_perform.

And the problem is fixed!

comment:17 Changed 2 years ago by dibdot

Retested with DD r48259, still broken on ar71xx devices like wdr4300 or dir835.

comment:18 Changed 2 years ago by anonymous

Still broken in r48648 on ar71xx device.

comment:19 Changed 2 years ago by wim@…

Still broken in r48973 ar71xx devices, like DIR-505

comment:20 Changed 23 months ago by wim@…

Curl still broken in r49037 for ar71xx devices like DIR-505.
With ca-certificates or just cacert.pem it just hangs forever in:
curl -u user:passw » ​ https://now-ip.com/update?hostname=my.host.name»
Can someone please repair this?

comment:21 Changed 22 months ago by wim@…

Curl still broken in r49218 for ar71xx devices.

comment:22 Changed 21 months ago by Zak

Working in 15.05 (CC) on Archer C7 v2 (AC1750 Wireless Dual Band Gigabit Router).
I was able to resolve by installing certificates.
opkg install ca-certificates

comment:23 Changed 21 months ago by wim@…

The presence of ca-certificates is obvious, but it does not help on the ar71xx platform were stuff is broken op until now! (r49296).

comment:24 Changed 21 months ago by zloop

this might be a packaging issue/local setup issue

test run on WDR3600 ar71xx w. LEDE r278

adresses that fail (basically all):

using certificate store does not work with mbedtls (curl/mbedtls will not build with the ca-path option)
so ca-certificates is not useful with mbedtls i think (it does not provide a single cert file)
using a cacert.pem file does work — from: ​ https://curl.haxx.se/docs/caextract.html

now its working (and by adding certificates to cacert.pem):

comment:25 Changed 21 months ago by wim@…

Here I have (r49296): curl -V
curl 7.48.0 (mips-openwrt-linux-gnu) libcurl/7.48.0 mbedTLS/1.3.16
Protocols: file ftp ftps http https
Features: IPv6 Largefile SSL

ls -al /etc/ssl/cacert.pem
-rw-r—r— 1 root root 252451 Mar 12 17:25 /etc/ssl/cacert.pem

• ssl_handshake returned — PolarSSL: (-0x7280) SSL — The connection indicated an EOF

curl: (35) ssl_handshake returned — PolarSSL: (-0x7280) SSL — The connection indicated an EOF

www.howsmyssl.com/a/check and www.tagesschau.de do answer a lot. (okay then?)

With strace it always ends like this:
.
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
.
clock_gettime(CLOCK_REALTIME, <1463674522, 87186882>) = 0
write(3, «\26\3\1\0\225\1\0\0\221\3\3W=\346\232@I\367=\361X\244\315\205\243\363\337\34\205\20\244\236». 154) = 154
read(3, 0x57f088, 5) = -1 EAGAIN (Resource temporarily unavailable)
fcntl64(3, F_GETFL) = 0x82 (flags O_RDWR|O_NONBLOCK)
clock_gettime(CLOCK_MONOTONIC, <784055, 29300982>) = 0
clock_gettime(CLOCK_MONOTONIC, <784055, 30097275>) = 0
clock_gettime(CLOCK_MONOTONIC, <784055, 30436456>) = 0
poll([], 1, 0) = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, <784055, 31297898>) = 0
clock_gettime(CLOCK_MONOTONIC, <784055, 31601424>) = 0
clock_gettime(CLOCK_MONOTONIC, <784055, 31923370>) = 0
poll([], 1, 0) = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, <784055, 34630073>) = 0
clock_gettime(CLOCK_MONOTONIC, <784055, 34988484>) = 0
clock_gettime(CLOCK_MONOTONIC, <784055, 35973807>) = 0
poll([], 1, 1000) = 1 ([])
clock_gettime(CLOCK_MONOTONIC, <784055, 118187106>) = 0
clock_gettime(CLOCK_MONOTONIC, <784055, 118576402>) = 0
poll([], 1, 0) = 1 ([])
read(3, «\25\3\3\0\2», 5) = 5
read(3, «\1p», 2) = 2

Where nothing ever follows.

comment:26 Changed 20 months ago by wim@…

Still broken in r49379 ar71xx devices, DIR-505.
Please get a free account at now-ip.com, it’s really easy compared to no-ip.com. It’s much harder to set up a platform to crosscompile ‘everything’ plus curl+openssl, just to discover that that wouldn’t fit in the DIR505. It’s still possible that the real problem lies at now-ip.com, but their contact addresses don’t work and the only one that did work (via WHOIS) stays unanswered.
They require https with curl.
As an alternative, noip.com will work with http instead of https. But that doesn’t resolve the bug.

comment:27 Changed 19 months ago by steve@…

Hi happy to look into this from Now-IP, we’ve not seen any reports to our support email addresses as far as I can see.

comment:28 Changed 19 months ago by wim@…

All at 18 feb 2016:
Curiously enough you mention two different contact addresses on your
home page. However, nothing would work.
Nothing but bounces from eforward3e.registrar-servers.com .
: unknown user: «contact@…»

: unknown user: «postmaster@…»
: unknown user: «support@…»
: unknown user: «hostmaster@…»

In the end I found an address in the whois database that worked:
Date: Thu, 18 Feb 2016 13:47:33 +0100
To: 6CBCC38B4AC644C48BEDC60376F21288.PROTECT@…
Subject: bug? and API updates

However, no reply either.

comment:29 Changed 19 months ago by steve@…

Hmm all addresses should be wild carded, I thought info@ was the only address listed on the site.

Any who, happy to help debug if needed.

comment:30 Changed 19 months ago by anonymous

It was not really a temporary problem, although it’s different now.
No mail can get through. Qmail says now:
@40000000577833b2009d95cc delivery 599: deferral: 209.188.21.37_does_not_like_recipient./Remote_host_said:_451-131.180.127.155_is_not_yet_authorized_to_deliver_mail_from/451_ _to_ ._Please_try_later./Giving_up_on_209.188.21.37./
@40000000577833b21378fe34 delivery 598: deferral: 209.188.21.37_does_not_like_recipient./Remote_host_said:_451-131.180.127.155_is_not_yet_authorized_to_deliver_mail_from/451_ _to_ ._Please_try_later./Giving_up_on_209.188.21.37./

comment:31 Changed 19 months ago by wim@…

I could try to remotely launch an API call, if that would help you to debug?

comment:32 Changed 19 months ago by steve@…

Sure, let me know source ip or some variable that you’re setting so I can pick it out.

comment:33 Changed 19 months ago by wim@…

Request is now coming from 145.94.245.206

comment:34 Changed 19 months ago by wim@…

three times in a row.
Strace stops as previously posted.

comment:35 Changed 19 months ago by steve@…

The client established TCP multiple times but at least twice ended the connection without even attempting an SSL handshake.

Two of the connections did begin SSL negotiation, during one the client did not respond timely which caused a HTTP 408 after about 20 seconds, the server ended that session. The other time the client sent a RST after about 16 seconds.

comment:36 Changed 19 months ago by wim@…

Strange, isn’t it?
The first attempt (before I announced the IP number) was from a machine behind the router and succeeded of course. Then three times from the the Dlink. All I can do is stop curl with Ctrl-C and restart it. So you might have seen twee shortish ones and a long one that I left alone for a while.
No difference at all on my side. Later I repeated another two times of which the last one still hangs.
No difference to be seen after all that time.

comment:37 Changed 19 months ago by anonymous

So curl doesn’t notice that the connection has ended.
This is definitely wrong at the OpenWRT side then.
Let’s hope the developers will do something about it then.
Thanks.

Источник

Настройка точечного обхода блокировок на роутере с 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. С такой конфигурацией можно полностью забыть про мелкие пакости от Роскомнадзора и начать, наконец, жить 🙂

Источник