Расшаривание обхода не IKEv2

[AltGrF13]

Вопрос по расшариванию SS другим подсетям с собственным сетевым интерфейсом (гостевой или любым другим VPN: OpenVPN, PPTP, SSTP и т.д.) Сейчас оно не работает (по крайней мере, связка SS + гостевой WiFi).

1. При вызове kvas vpn net add мы попадаем в bridge_vpn_access_add из opt/bin/libs/vpn:902. Если запрошено для ikev2, то вызывается ikev2_net_access_add (коий в декабре был отлажен и прекрасно работает), иначе — bridge_access_add. Этот метод сохраняет выбор в настройки и записывает в /opt/etc/dnsmasq.conf строчку listen-address=192.168.3.1 Да, при подключении к гостевой именно этот адрес в качестве DNS, это мы перехватили. Но как минимум в случае SS (а для основного соединения VPN нет специфических правил для каждого гостевого интерфейса?) нам нужно решить не только проблему DNS, но и самого трафика, те многострадальные

   iptables -A PREROUTING -w -t nat -i ${guest_bridge_id} -p tcp -m set --match-set unblock dst -j REDIRECT --to-port 1181
   iptables -A PREROUTING -w -t nat -i ${guest_bridge_id} -p udp -m set --match-set unblock dst -j REDIRECT --to-port 1181

   Т.е. как минимум в случае SS нам нужно вызвать не только bridge_access_add (запишет в настройки и добавит прослушку DNS), но и ip4_add_selected_guest_to_ssr_network (создаст правила трафика). Код

   bridge_vpn_access_add() {
   guest_bridge_id=${1}
   
   if [ -n "${guest_bridge_id}" ]; then
       if echo "${guest_bridge_id}" | grep -iq ikev2 ; then
           ikev2_net_access_add
       else
           bridge_access_add "${guest_bridge_id}"
   
           if has_ssr_enable; then
               ip4_add_selected_guest_to_ssr_network "${guest_bridge_id}"
           fi
       fi
   fi
   }

2. Ещё у нас есть куча скриптов в opt/etc/ndm/netfilter.d, которые срабатывают при перезапуске роутера целиком или какого-то из его интерфейсов (например, в веб-морде что-то изменили). В 100-dns-local идёт вызов set_guest_nets_rules из opt/etc/ndm/ndm:328, которая вызовет ip4_add_guest_to_ssr_network и для каждого гостевого интерфейса вызовет ip4_add_selected_guest_to_ssr_network. Как его плюс-минус адаптировать к любой гостевой сети как раз упоминалось в комментарии к задаче 53 в пункте 7. Для ikev2 правила с -s ${net_pool} -i ${net_inface} (полученный из get_entware_ikev2_inface), для остальных просто переданный -i ${net_inface}. Код

   ip4_add_selected_guest_to_ssr_network() {
   net_inface=${1}
   net_pool=${2}
   
   [ -z "${net_inface}" ] && {
       error "[${FUNCNAME}] Отсутствует обязательный параметр сетевой интерфейс."
       exit 1
   }
   
   if [ "${net_inface}" = ikev2 ] ; then
       net_inface=$(get_entware_ikev2_inface)
   
       [ -z "${net_pool}" ] && {
           ikev2_settings=$(curl -s "${LOCALHOST_IP}:79/rci/crypto/virtual-ip-server-ikev2")
           pool_start=$(echo "${ikev2_settings}" | grep pool-start | cut -d':' -f2 | sed 's/[\,\" ]//g;')
           net_pool=$(echo "${pool_start}" | sed 's/\.[0-9]\{1,3\}$/.0\/24/')
       }
   
       net_filter=" -s ${net_pool}"
   else
       net_filter=""
   fi
   
   port=$(get_config_value SSR_DNS_PORT)
   if ! iptables-save | grep PREROUTING | grep "${net_filter}" | grep "${net_inface}" | grep unblock | grep REDIRECT | grep -q "${port}" ; then
       log_warning "Подключаем правила маркировки гостевого трафика ${net_inface} для SHADOWSOCKS."
   #       {
           iptables -A PREROUTING -t nat${net_filter} -i ${net_inface} -p tcp -m set --match-set unblock dst -j REDIRECT --to-port ${port}
           iptables -A PREROUTING -t nat${net_filter} -i ${net_inface} -p udp -m set --match-set unblock dst -j REDIRECT --to-port ${port}
   #       } || error "[${FUNCNAME}] Возникла ошибка при подключении правил маркировки гостевого трафика ${net_inface} для SHADOWSOCKS."
   fi
   }

   С такими 2 функциями работает расшаривание и в IKEv2, и в гостевую.

Если в списке разрешённых для расшаривания сетей начать выводить sstp+, то и #109 будет решён (ваша bridge_access_add добавит listen-address для DNS, а обновлённая ip4_add_selected_guest_to_ssr_network докинет оба правила). Если узнать имя сетевого интерфейса Wireguard, то и связка Wireguard + SS будет работать.

[qzeleza]

Большое спасибо за Ваши мысли по поводу проекта.

Правильно ли я Вас понял, что Вы переделаете внести изменения в код путем вставки двух кусков кода выше? Если так, то прошу дать пояснения - Вы свой код тестировали при всех возможных конфигурациях пакета? Все работает?

[AltGrF13]

1. Да, я предлагаю внести эти 2 функции прям копипастой. Просто отсмотрите их глазами при коммите (в визуальных git-клиентах очень удобно видеть было-стало прям до символа); может что-то пропущено, у Вас тут больше опыта.
2. При всех возможных конфигурациях, к сожалению, не тестировалось. Но: в первой функции вставлен лишь блок с if'ом, изменение только для случая SS+неIKEv2, который сейчас и не работает. Во вторую код может прийти с двух мест, но лишь при расшаривании и основном соединении SS. Эти случаи и были проверены.
3. Да, было сделано:
   • функции заменой скопированы в файлы на устройстве (обычно это оба файла ndm и один vpn);
   • удалены оба расшаривания через команду КВАС;
   • проверено, что правила iptables пропали;
   • проверено, что у гостевой прослушивание DNS удалено;
   • проверено, что файл хранимых настроек подчищен;
   • дальше обе сети были добавлены обратно и вышеописанные 3 проверки.

[AltGrF13]

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

[qzeleza]

Хорошо, благодарю Вас. В следующем релизе постараюсь внести изменения, после проверки.

[qzeleza]

изменения внесены в 1.1.8 r1 прошу дать обратную связь.

[qzeleza]

После удаления гостевой сети из кваса и перезагрузки устройства, остаются правила iptables которые для моей модели не актуальны.

Прошу прислать в "личку" файл отладки

[AltGrF13]

После удаления гостевой сети из кваса и перезагрузки устройства, остаются правила iptables которые для моей модели не актуальны

А у Вас, случайно, не осталось в Entware старого ручного решения? В /opt/etc/ndm/netfilter.d/ какого-нибудь своего файла типа 100-shadowsocks-vpn-server?

Ну и совсем дурацкое предположение: а у Вас команда ip a | grep -q 'global eth3' && echo eth3 || echo eth2.2 выводит правильное значение? А то одноинтерфейсных Кинетиков в наличии нет)

[qzeleza]

После удаления гостевой сети из кваса и перезагрузки устройства, остаются правила iptables которые для моей модели не актуальны

А у Вас, случайно, не осталось в Entware старого ручного решения? В /opt/etc/ndm/netfilter.d/ какого-нибудь своего файла типа 100-shadowsocks-vpn-server?

Поясните пожалуйста Ваши вопросы. Не понимаю о чем речь?

Ну и совсем дурацкое предположение: а у Вас команда ip a | grep -q 'global eth3' && echo eth3 || echo eth2.2 выводит правильное значение? А то одноинтерфейсных Кинетиков в наличии нет)

К чему этот вопрос, поясните пожалуйста.

[AltGrF13]

файл 100-shadowsocks-vpn-server имеется

Это костыль из тех времён, когда КВАС из коробки не делал прокидку IKEv2+SS. Я предполагаю, это он и даёт не актуальные правила. Надо избавиться от него, перезагрузиться, вернуть прокидку гостевых КВАСом и проверить ещё раз. Что-то типа:

kvas vpn net del
mv /opt/etc/ndm/netfilter.d/100-shadowsocks-vpn-server /opt/tmp
reboot
kvas vpn net add
iptables-save | grep -E 'PREROUTING|nat' | grep -vE '_NDM|^\*|^\:' &> /opt/tmp/kvas_iptables.txt

В /opt/etc/ndm/netfilter.d/ должны быть лишь

0. 100-dns-local, и то через некоторое время будет удалён, сейчас там всё закомментировано;
1. 100-proxy-redirect пересоздаёт правила, если основное соединение SS;
2. 100-vpn-mark пересоздаёт правила, если основное соединение VPN.

[AltGrF13]

После обновления были проверены (что на сайтах из списка обхода подключение через прокси, а на обычные — напрямую) домашний WiFi, гостевой, IKEv2 при основном подключении SS. Везде всё хорошо, вопрос можно закрывать.