Не запускается ruantiblock после перезагрузки роутера

gSpotx2f / ruantiblock_openwrt

Обход блокировок в OpenWrt с помощью Tor или VPN

GNU General Public License v3.0

164 stars 15 forks source link

Не запускается ruantiblock после перезагрузки роутера #54

Closed vit9696 closed 8 months ago

vit9696 commented 8 months ago

Добрый день,

После перезагрузки роутера всегда в LUCI наблюдаю VPN routing error! Need restart. Если перезапустить сервис, то сразу же всё работает. Я предполагаю, что где-то надо выставить задержку перед стартом, но пока ничего не нашёл.

OpenWrt 2023.05.02 (Stable).

В логах наблюдаю разве что:

Mon Jan  1 17:46:26 2024 daemon.notice procd: /etc/rc.d/S99ruantiblock:  ruantiblock start...
Mon Jan  1 17:46:26 2024 user.info ruantiblock: start...
Mon Jan  1 17:46:27 2024 daemon.notice procd: /etc/rc.d/S99ruantiblock:  ruantiblock update...
Mon Jan  1 17:46:27 2024 user.notice ruantiblock: update...
Mon Jan  1 17:46:32 2024 daemon.notice procd: /etc/rc.d/S99ruantiblock: Failed to send request: Operation not permitted
Mon Jan  1 17:46:32 2024 daemon.notice procd: /etc/rc.d/S99ruantiblock: Blacklist downloading failed! Connection error (https://raw.githubusercontent.com/gSpotx2f/ruantiblock_blacklist/master/blacklist-1.1/fqdn/ruantiblock.dnsmasq)
Mon Jan  1 17:46:32 2024 user.err ruantiblock: Blacklist downloading failed! Connection error (https://raw.githubusercontent.com/gSpotx2f/ruantiblock_blacklist/master/blacklist-1.1/fqdn/ruantiblock.dnsmasq)
Mon Jan  1 17:46:32 2024 daemon.notice procd: /etc/rc.d/S99ruantiblock:  Module run attempt 1: failed [DownloadRuabBlacklist fqdn]
Mon Jan  1 17:46:32 2024 user.err ruantiblock: Module run attempt 1: failed [DownloadRuabBlacklist fqdn]
Mon Jan  1 17:48:39 2024 daemon.notice procd: /etc/rc.d/S99ruantiblock:  Received entries: CIDR: 659, IP: 5302, FQDN: 164621
Mon Jan  1 17:48:39 2024 user.notice ruantiblock: Received entries: CIDR: 659, IP: 5302, FQDN: 164621
Mon Jan  1 17:48:39 2024 daemon.notice procd: /etc/rc.d/S99ruantiblock:  Blacklist updated
Mon Jan  1 17:48:39 2024 user.notice ruantiblock: Blacklist updated
Mon Jan  1 17:48:39 2024 daemon.notice procd: /etc/rc.d/S99ruantiblock:  Updating nft sets...
Mon Jan  1 17:48:40 2024 daemon.notice procd: /etc/rc.d/S99ruantiblock:  Ok
Mon Jan  1 17:48:40 2024 daemon.notice procd: /etc/rc.d/S99ruantiblock: udhcpc: started, v1.36.1
Mon Jan  1 17:48:40 2024 daemon.notice procd: /etc/rc.d/S99ruantiblock: udhcpc: broadcasting discover
Mon Jan  1 17:48:43 2024 daemon.notice procd: /etc/rc.d/S99ruantiblock: udhcpc: no lease, failing
Mon Jan  1 17:48:43 2024 daemon.notice procd: /etc/rc.d/S99ruantiblock: udhcpc: started, v1.36.1
Mon Jan  1 17:48:43 2024 daemon.notice procd: /etc/rc.d/S99ruantiblock: udhcpc: broadcasting discover
Mon Jan  1 17:48:46 2024 daemon.notice procd: /etc/rc.d/S99ruantiblock: udhcpc: no lease, failing

Подскажите, пожалуйста, куда копать. Спасибо и с наступившим!

vit9696 commented 8 months ago

Мне удалось обойти проблему, отредактировав файл /etc/rc.d/S99ruantiblock. Я добавил задержку в функцию start, и запуск стал происходить корректно:

start() {
    local update_at_startup
    config_get update_at_startup config update_at_startup
    sleep 30 # Задержка в 30 секунд для инициализации VPN
    $APP_EXEC start
    if [ $? -eq 0 -a "$update_at_startup" = "1" ]; then
        $APP_EXEC update
    else
        /etc/init.d/dnsmasq restart
    fi
}

Однако хотелось бы либо более изящное решение, либо данный функционал из коробки с возможностью настройки таймаута в интерфейсе.

gSpotx2f commented 8 months ago

Сообщение об ошибке маршрутизации означает отсутствие маршрута на VPN-интерфейс. Маршрут добавляется автоматически, при поднятии VPN-интерфейса (указанного в параметре VPN-интерфейс в настройках ruantiblock). Даже если VPN запускается намного позже старта ruantiblock - это не должно быть проблемой. Покажите содержимое конфига /etc/config/ruantiblock. Что используете для проксификации трафика (OpenVPN, wireguard, sing-box и пр.)?

vit9696 commented 8 months ago

Насколько я понимаю, tun0 создаётся не безусловно, а в момент поднятия OpenVPN. И видимо позже старта ruantiblock. Возможно из-за этого проблема.

Конфигурация ruantiblock:

# cat /etc/config/ruantiblock
config main 'config'
  option proxy_mode '2'
  option proxy_local_clients '1'
  option nftset_clear_sets '1'
  option allowed_hosts_mode '0'
  option bypass_mode '1'
  option enable_fproxy '0'
  option enable_bllist_proxy '0'
  option if_vpn 'tun0'
  option vpn_route_check '0'
  option tor_trans_port '9040'
  option onion_dns_addr '127.0.0.1#9053'
  option t_proxy_port_tcp '1100'
  option t_proxy_port_udp '1100'
  option t_proxy_allow_udp '0'
  option add_user_entries '1'
  option enable_logging '1'
  option bllist_min_entries '3000'
  option bllist_ip_limit '0'
  option bllist_summarize_ip '1'
  option bllist_summarize_cidr '1'
  option bllist_ip_filter '0'
  option bllist_ip_filter_type '0'
  option bllist_sd_limit '16'
  list bllist_gr_excluded_sld 'livejournal.com'
  list bllist_gr_excluded_sld 'facebook.com'
  list bllist_gr_excluded_sld 'vk.com'
  list bllist_gr_excluded_sld 'blog.jp'
  list bllist_gr_excluded_sld 'msk.ru'
  list bllist_gr_excluded_sld 'net.ru'
  list bllist_gr_excluded_sld 'org.ru'
  list bllist_gr_excluded_sld 'net.ua'
  list bllist_gr_excluded_sld 'com.ua'
  list bllist_gr_excluded_sld 'org.ua'
  list bllist_gr_excluded_sld 'co.uk'
  list bllist_gr_excluded_sld 'amazonaws.com'
  list bllist_gr_excluded_sld 'spb.ru'
  list bllist_gr_excluded_sld 'appspot.com'
  list bllist_gr_excluded_sld 'googleusercontent.com'
  option bllist_fqdn_filter '1'
  option bllist_fqdn_filter_type '0'
  option bllist_enable_idn '0'
  option bllist_alt_nslookup '0'
  option bllist_alt_dns_addr '8.8.8.8'
  option update_at_startup '1'
  option bllist_preset 'ruantiblock-fqdn'

Конфигурация OpenVPN:

# cat /etc/openvpn/client.ovpn 
auth-user-pass /etc/openvpn/client.auth
client
dev tun
hand-window 120
inactive 604800
mute-replay-warnings
nobind
persist-key
persist-remote-ip
persist-tun
ping 5
ping-restart 120
remote-random
reneg-sec 3600
script-security 2
tls-cipher TLS_CHACHA20_POLY1305_SHA256:TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS_AES_256_GCM_SHA384:TLS-RSA-WITH-AES-256-CBC-SHA
tls-timeout 5
verb 4
route-delay 2
resolv-retry 60
route-method exe
tun-mtu  1500
tun-mtu-extra  32
mssfix 1450
proto udp
remote ####### 
data-ciphers AES-256-GCM
auth SHA512
remote-cert-tls server

<ca>
#######
</ca>
<cert>
#######
</cert>
<key>
#######
</key>
<tls-crypt>
#######
</tls-crypt>

route-noexec
pull-filter ignore ipv6-route
pull-filter ignore ifconfig-ipv6
pull-filter ignore "dhcp-option DNS"

gSpotx2f commented 8 months ago

Насколько я понимаю, tun0 создаётся не безусловно, а в момент поднятия OpenVPN. И видимо позже старта ruantiblock. Возможно из-за этого проблема.

Всё именно так и должно работать, как вы написали: сначала стартует ruantiblock, потом OpenVPN соединяется с сервером. На самом деле, вообще не важно кто из них раньше стартует. Ruantiblock можно запускать с отключенным VPN, он будет ждать когда появится VPN интерфейс и после начнёт работать не требуя никаких действий или перезапуска. Когда OpenVPN поднимает тунель с сервером и создаёт свой интерфейс (например, tun0), то срабатывают скрипты расположенные в /etc/hotplug.d/iface. Там есть скрипт 40-ruantiblock в котором прописано добавление маршрута на VPN-интерфейс. Тоже самое происходит и при переподключении VPN в любой момент (не только после загрузки роутера). Т.е. этот функционал уже существует в ruantiblock, но не в виде задержки в стартовом скрипте (это ненадёжно и работает непредсказуемо), а в виде event-скрипта выполняемого при появлении VPN-интерфейса в системе. Возможно, нужно просто подождать секунд 10 после поднятия VPN соединения и обновить страницу LuCI в браузере, тогда сообщение об ошибке маршрутизации пропадёт. У меня похожая конфигурация (ruantiblock + OpenVPN) работает в стандартном виде без проблем, и при запуске роутера, и при внезапных переподключениях VPN.

vit9696 commented 8 months ago

Ну вот нет, попробовал даже пару минут. Не взлетает оно без задержки. Есть какие-то иные механизмы диагностирования?

gSpotx2f commented 8 months ago

Есть какие-то иные механизмы диагностирования?

Проверьте срабатывает ли hotplug-скрипт при переподключении VPN:

Роутер включен, полностью загрузилась ОС, OpenVPN туннель поднялся (появился интерфейс tun), вы перезапустили ruantiblock, обход блокировок работает, нет сообщения VPN routing error! Need restart на странице ruantiblock в LuCI.
Далее отключите OpenVPN (в вебморде на странице OpenVPN, кнопка start/stop у вашего экземпляра).
Откройте страницу ruantiblock в LuCI. Там будет сообщение об ошибке маршрутизации (VPN routing error! Need restart).
Затем заново подключитесь к VPN серверу, не трогая ruantiblock. Посмотрите в консоли вывод ifconfig, там должен быть интерфейс tun0 (или tun1 и т.п.) связанный с вашим VPN туннелем.
Подождите 15 сек, откройте страницу ruantiblock в LuCI. Сообщение об ошибке маршрутизации (VPN routing error! Need restart) должно отсутствовать.
Проверьте наличие маршрута на VPN интерфейс в консоли:
```
ip route show table 99
```
вывод должен показать маршрут как-то так:
```
default via 10.10.15.46 dev tun0
```

vit9696 commented 8 months ago

Проверил, по всей видимости не работает, и это объясняет проблему. Сообщение VPN routing error! Need restart остаётся на месте, а ip route show table 99 выдаёт пустоту. Это даже после минуты ожидания. При этом в логах я вижу:

daemon.notice openvpn(client)[31819]: /usr/libexec/openvpn-hotplug up client tun0 1500 1584 10.10.10.11 255.255.255.0 init
daemon.notice openvpn(client)[31819]: Initialization Sequence Completed

vit9696 commented 8 months ago

Хмм, минуту, openvpn-hotplug вызывает hotplug не с iface событием, а с событием openvpn:

# cat /usr/libexec/openvpn-hotplug
#!/bin/sh

ACTION=$1
shift
INSTANCE=$1
shift

export ACTION=$ACTION
export INSTANCE=$INSTANCE
exec /sbin/hotplug-call openvpn "$@"

# cat /sbin/hotplug-call
#!/bin/sh
# Copyright (C) 2006-2016 OpenWrt.org

export HOTPLUG_TYPE="$1"

. /lib/functions.sh

PATH="/usr/sbin:/usr/bin:/sbin:/bin"
LOGNAME=root
USER=root
export PATH LOGNAME USER
export DEVICENAME="${DEVPATH##*/}"

if [ \! -z "$1" -a -d /etc/hotplug.d/$1 ]; then
    for script in $(ls /etc/hotplug.d/$1/* 2>&-); do (
        [ -f $script ] && . $script
    ); done
fi

По идее тогда в /etc/hotplug.d/openvpn скрипт класть надо.

vit9696 commented 8 months ago

Добавил скрипт /etc/hotplug.d/openvpn/40-ruantiblock со следующим содержимым:

#!/bin/sh

UCI_CMD=`which uci`
if [ $? -ne 0 ]; then
    echo " Error! UCI doesn't exists" >&2
    exit 1
fi
RUAB_CMD="/usr/bin/ruantiblock"
PROXY_MODE=`$UCI_CMD get ruantiblock.config.proxy_mode`
IF_VPN=`$UCI_CMD get ruantiblock.config.if_vpn`
VPN_ROUTE_CHECK=`$UCI_CMD get ruantiblock.config.vpn_route_check`

[ "$VPN_ROUTE_CHECK" != "0" ] && exit 0

if [ "$ACTION" = "up" ] && [ "$PROXY_MODE" = "2" ] && [ "$2" = "$IF_VPN" ]; then
    if [ `$RUAB_CMD raw-status` -ne 2 ]; then
        sleep 5
        $RUAB_CMD reload
    fi
fi

Работает корректно после перезагрузки. У меня вроде самый стандартный openvpn-openssl, как-то странно.

gSpotx2f commented 8 months ago

В LuCI на странице "Интерфейсы" откройте свойства неуправляемого интерфейса к которому привязан сетевой интерфейс tun0. Галка "Запустить при загрузке" включена? Похоже, в этом причина не выполнения скриптов в /etc/hotplug.d/iface при поднятии tun0.

vit9696 commented 8 months ago

Хм, такого интерфейса у меня нет.

В разделе Interfaces у меня только 2 lan (основной и гостевой) и 2 wan (v4 и v6).
В разделе Devices я вижу tun0, но у него такой галочки нет, так как это не "мост".

Фотографии прилагаю:

Полная версия LuCI:

Powered by LuCI openwrt-23.05 branch (git-23.357.58018-024e7ab) / OpenWrt 23.05.2 (r23630-842932a63d)

gSpotx2f commented 8 months ago

В разделе Interfaces у меня только 2 lan (основной и гостевой) и 2 wan (v4 и v6).

А как у вас тогда межсетевой экран настроен, правило разрешающее трафик из LAN в VPN (tun0)? Я слегка допилил вики, добавил подробнее про настройки для VPN.

vit9696 commented 8 months ago

В параметрах firewall в WAN прописано вот так:

Делал по инструкции с OpenWRT: https://openwrt.org/docs/guide-user/services/vpn/openvpn/client-luci#b_with_openwrt_1907_alternative_to_the_above_step_41

В конце конфига есть route-noexec, конечно же, после <ca> (см. выше):

route-noexec
pull-filter ignore ipv6-route
pull-filter ignore ifconfig-ipv6
pull-filter ignore "dhcp-option DNS"

Я могу попробовать поменять конфигурацию OpenVPN, но на вид у меня рекомендуемые параметры с точки зрения OpenWRT.

gSpotx2f commented 8 months ago

Вы добавили tun0 в устройства "не управляемые через uci", поэтому не срабатывает скрипт. Нужно создать интерфейс для устройства tun0, в пункте 4.1 как раз прописано создание интерфейса OpenWrt. Там пятый пункт: 5. In panel General Settings: unselect the checkbox Bring up on boot., вот если эту галку отключить, то скрипты в /etc/hotplug.d/iface не срабатывают. Галка Bring up on boot должна быть включена. Я про это спрашивал. Потом его надо добавить в зону wan или создать отдельную зону для VPN и далее по тексту...

vit9696 commented 8 months ago

Вот теперь всё работает корректно. Спасибо большое! Обновленной инструкции на Wiki действительно не хватало, теперь всё стало понятнее. Тикет закрываю ^_^

nitro3188 commented 6 months ago

так должно быть?