Поддержка IKEv2 в ssr guest

qzeleza / kvas

vpn и shadowsocks клиент для роутеров keenetic

Other

649 stars 41 forks source link

Поддержка IKEv2 в ssr guest #53

Closed AltGrF13 closed 8 months ago

AltGrF13 commented 1 year ago

IPSec, в отличии от привычных VPN-решений, не создаёт сетевые интерфейсы, только политики обработки. Поэтому через ssr guest и vpn guest на него обход блокировок не добавить.

1. При выводе списка

Состоящего из сетевых VPN-интерфейсов и guest сети, можно дёрнуть из API Keenetic'а (команды оттуда КВАСом поддерживаются) show running-config. Если есть блок crypto map VirtualIPServerIKE2 и в нём есть enable,

crypto map VirtualIPServerIKE2
    set-peer any
    set-profile VirtualIPServerIKE2
    set-transform VirtualIPServerIKE2
    match-address _WEBADMIN_IPSEC_VirtualIPServerIKE2
    set-tcpmss 1200
    force-encaps
    no nail-up
    reauth-passive
    virtual-ip range 192.168.2.35 192.168.2.149
    virtual-ip dns-server 192.168.1.1
    virtual-ip nat
    virtual-ip multi-login
    virtual-ip static-ip abc 192.168.2.32
    virtual-ip static-ip def 192.168.2.30
    virtual-ip enable
    enable
!

то на роутере включен VPN-сервер IKEv2/IPsec. В списке ssr guest нужно вывести виртуальный пункт ikev2.

2. Если выбрано расшаривание обхода для ikev2

Т.е. тот самый добавленный виртуальный пункт ikev2. То нужно:

2.1. В вышеприведённом блоке найти virtual-ip dns-server. По умолчанию там 78.47.125.180, который на лету подменялся DNS-сервером Keenetic'а, отключенным при установке КВАСа. Теперь там должен быть указан IP роутера! Его можно получить той же командой API show running-config, блок interface Bridge0, пункт ip address

interface Bridge0
    rename Home
    description "Home network"
    inherit GigabitEthernet0/Vlan1
    include AccessPoint
    include AccessPoint_5G
    mac access-list type none
    security-level private
    ip address 192.168.1.1 255.255.255.0
    ip dhcp client dns-routes
    ip dhcp client name-servers

Собственно, сверяем virtual-ip dns-server и ip address. Если они не совпадают, то ругаемся на пользователя, что в настройках VPN-сервера IKEv2/IPsec в поле DNS-сервер должен быть указан IP роутера, т.е. [значение] (чаще всего там 192.168.1.1). Два новых DNS-правила iptables, как у других VPN-подключений, не нужны. Достаточно, чтобы стояла эта настройка. 2.2. Из того же самого первоначального блока crypto map VirtualIPServerIKE2 (приведённого первым) мы можем узнать virtual-ip range (по умолчанию там 172.20.8.1, у меня 192.168.2.35). Берём первые 3 сегмента, преобразуем их в 192.168.2.0/24 и получаем необходимые 2 правила шаринга (команды аналогичны другим VPN):

iptables -A PREROUTING -w -t nat -s 192.168.2.0/24 -i eth3 -p tcp -m set --match-set unblock dst -j REDIRECT --to-port 1181
iptables -A PREROUTING -w -t nat -s 192.168.2.0/24 -i eth3 -p udp -m set --match-set unblock dst -j REDIRECT --to-port 1181

Итого

Расшаривание на клиентов IKEv2 сервера роутера, по сути — 2 правила и одна настройка. Поддержка IKEv2 для vpn guest, скорее всего, не сложнее. Просто нужно помнить, что сейчас не свой собственный интерфейс -i sstp0, а весь сетевой порт -i eth3 плюс правило диапазона IP у клиентов VPN-сервера -s 192.168.2.0/24.

qzeleza commented 1 year ago

Благодарю, в следующей версии постараюсь включить в пакет данный функционал.

qzeleza commented 9 months ago

Прошу дать обратную связь по выявленной Вами проблеме в крайней версии пакета Квас - 1.1.5-pr2. Решена ли Ваша проблема в этой версии пакета?

Желательно это сделать вплоть до 26 ноября текущего года. Детали описаны на форуме по этой ссылке.

qzeleza commented 9 months ago

Если ошибка воспроизводима в крайней версии Кваса - откройте тикет вновь. Пока же тикет закрываю из-за отсутствия обратной связи по ошибке.

AltGrF13 commented 9 months ago

Здравствуйте. К сожалению, не было времени успеть до срока. Добрался сейчас.

Установил с нуля через

opkg install curl
cd /opt/packages
curl -sOfL https://bit.ly/kvas_update
sh ./kvas_update

Указал shadowsocks, добавил локальные домены, применил список обхода, включил шифрование DNS.

Через kvas vpn net add добавил применение правил для ikev2. Правила добавились, но они не верны, обход не работает. Проверить можно через iptables -vL PREROUTING -t nat: kvas-iptables

зелёные правила — сам обход для домашней сети br0: 2 правила для трафика и 2 для DNS;
синим — что я добавил руками, с чем обход работает, ограничено сетевым соединением eth3 и диапазоном IP (/opt/sbin/iptables -A PREROUTING -w -t nat -i eth3 -s 192.168.2.0/24 …): 2 правила для трафика, для DNS не требуются;
красным — то, что добавил КВАС. В качестве сетевого интерфейса указан ikev2, но такого не существует (IPSec, в отличии от других VPN протоколов, не создаёт сетевые интерфейсы). Также КВАС пытался добавить 2 правила для DNS, а этого не требуется, т.к. в настройках IKEv2 уже указан IP роутера.

P.S. Переоткрыть задачу не смог.

qzeleza commented 9 months ago

Здравствуйте, Прошу Вас, по возможности, прислать вывод следующих команд

kvas debug
iptables-save | grep -E 'PREROUTING|nat' | grep -vE '_NDM|\*|\:'.
curl -s http://127.0.0.1:79/rci/crypto/virtual-ip-server-ikev2

AltGrF13 commented 9 months ago

qzeleza commented 9 months ago

Благодарю Вас

красным — то, что добавил КВАС. В качестве сетевого интерфейса указан ikev2, но такого не существует (IPSec, в отличии от других VPN протоколов, не создаёт сетевые интерфейсы). Также КВАС пытался добавить 2 правила для DNS, а этого не требуется, т.к. в настройках IKEv2 уже указан IP роутера.

Не соответствует действительности, так как в новой 1.1.5-final-7 нет такого кода, который бы добавлял указанный Вами правила выше для интерфейса ikev2. Возможно это осталось у Вас от предыдущих экспериментов.

Сейчас, с данной конфигурацией, присланной выше, у Вас клиенты ikev2 подключаются к Квасу?

AltGrF13 commented 9 months ago

Ставил через рекомендованные команды. Раз такое подозрение (и Вы писали на форуме, что обновили скрипт установки), решил провести полную переустановку.

kvas vpn net del
kvas rm full
cd /opt/tmp
rm -f ./*
curl -sOfL https://bit.ly/kvas_update
sh ./kvas_update
kvas vpn net add

Картина ровно та же, правила не верны.

Может Вас смутило то, что я прислал результат curl со своими вручную добавленными 2 правилами? Ну вот результат без них kvas_iptables.txt

Сейчас, с данной конфигурацией, присланной выше, у Вас клиенты ikev2 подключаются к Квасу?

Когда добавляю свои 2 правила руками, то клиенты IKEv2 ходят к ресурсам из списка обхода через указанный КВАСу SS, всё работает. Без них — нет, kvas vpn net add добавляет неправильное в iptables.

Может ли быть такое, что kvas rm full и curl -sOfL https://bit.ly/kvas_update && sh ./kvas_update не устанавливают актуальную версию пакета? Для чистоты эксперимента могу переустановить OPKG с переформатированием флешки.

qzeleza commented 9 months ago

Может Вас смутило то, что я прислал результат curl со своими вручную добавленными 2 правилами? Ну вот результат без них kvas_iptables.txt

Нет, меня смутило, то что добавлены правила с интерфесом ikev2, который там физически не может появляться.

Для чистоты эксперимента могу переустановить OPKG с переформатированием флешки.

Если нет возможности дать доступ на устройство, то да, было бы здорово.

badigit commented 9 months ago

Странно, у меня вот VirtualIP IPSec Ikev2 используется как интерфейс для обхода, уже довольно давно (год), все работает (IPSec виден при сканировании интерфейсов)

qzeleza commented 9 months ago

Странно, у меня вот VirtualIP IPSec Ikev2 используется как интерфейс для обхода, уже довольно давно (год), все работает (IPSec виден при сканировании интерфейсов)

Если не трудно поделитесь пожалуйста выводом команд:

1. kvas debug
2. iptables-save | grep -E 'PREROUTING|nat' | grep -vE '_NDM|\*|:'.
3. curl -s http://127.0.0.1:79/rci/crypto/virtual-ip-server-ikev2

badigit commented 9 months ago

1.debug.txt

~ # iptables-save | grep -E 'PREROUTING|nat' | grep -vE '_NDM|\*|:'.
-A PREROUTING -i br0 -p tcp -m tcp --dport 53 -j DNAT --to-destination 10.9.8.1
-A PREROUTING -i br0 -p udp -m udp --dport 53 -j DNAT --to-destination 10.9.8.1
-A PREROUTING -p tcp -m set --match-set unblock dst -j VPNREDIR
-A PREROUTING -p udp -m set --match-set unblock dst -j VPNREDIR

~ # curl -s http://127.0.0.1:79/rci/crypto/virtual-ip-server-ikev2
{
  "enable": false,
  "nat": true,
  "pool-start": "172.20.8.1",
  "pool-size": "256",
  "dns-server": "78.47.125.180",
  "multi-login": false,
  "sa-compat": "default"
}~ #

Возможно я не так понял суть тикета, у меня роутер - клиент IPSec VurtualIP, и это VPN используется для обхода.

А изначально вопрос в том чтобы на роутере, где размещен сервер VurtualIP использовать клиента VirtualIP для обхода блокировок?

Есть еще третий вариант - IPsec-подключения сеть—сеть, но вроде бы это вообще не относится к VirtualIP?

qzeleza commented 9 months ago

А изначально вопрос в том чтобы на роутере, где размещен сервер VurtualIP использовать клиента VirtualIP для обхода блокировок?

Нет, здесь речь идет о том, чтобы клиентам VurtualIP-IPSec-сервера иметь возможность заходить по списку хостов в сеть через ssr (через которое и работает Квас).

badigit commented 9 months ago

Спасибо, В моём случае есть вариант другого кинетика, где настроен обход через VPN WG, также настроен VirtualIP сервер, к нему подключаются клиенты (например телефон), и с телефона начинает работать обход.

Не знаю есть ли тут разница между wg\ssr но обход работает для клиента VirtualIP-IPSec IKEv2 Правда, все это уже много месяцев работает на 1.1.3 квасе и трогать не хочется)

qzeleza commented 9 months ago

Не знаю есть ли тут разница между wg\ssr но обход работает для клиента VirtualIP-IPSec IKEv2 Правда, все это уже много месяцев работает на 1.1.3 квасе и трогать не хочется)

Да, разница имеется, но, если не трудно (переустановки ни какой не требуется), пришлите пожалуйста данные по выполненным выше командам на нем.

AltGrF13 commented 9 months ago

переустановить OPKG с переформатированием флешки

К сожалению, при очередном переформатировании на ПК флешка отъехала в мир иной — сыплет ошибками. Проверку смогу завершить лишь через неделю, как приедет новая. Остался без OPKG(

badigit commented 9 months ago

Странно, у меня вот VirtualIP IPSec Ikev2 используется как интерфейс для обхода, уже довольно давно (год), все работает (IPSec виден при сканировании интерфейсов)

Если не трудно поделитесь пожалуйста выводом команд:

1 debug.txt

1. kvas debug
2. iptables-save | grep -E 'PREROUTING|nat' | grep -vE '_NDM|\*|:'.
3. curl -s http://127.0.0.1:79/rci/crypto/virtual-ip-server-ikev2


~ # iptables-save | grep -E 'PREROUTING|nat' | grep -vE '_NDM|\*|:'.
-A PREROUTING -i br0 -p tcp -m tcp --dport 53 -j DNAT --to-destination 10.9.0.1
-A PREROUTING -i br0 -p udp -m udp --dport 53 -j DNAT --to-destination 10.9.0.1
-A PREROUTING -p tcp -m set --match-set unblock dst -j VPNREDIR
-A PREROUTING -p udp -m set --match-set unblock dst -j VPNREDIR
~ # curl -s http://127.0.0.1:79/rci/crypto/virtual-ip-server-ikev2
{
  "enable": true,
  "nat": true,
  "pool-start": "10.9.2.1",
  "pool-size": "20",
  "dns-server": "10.9.0.1",
  "multi-login": false,
  "sa-compat": "default"
}~ #

AltGrF13 commented 9 months ago

Здравствуйте. Ну что ж, устанавливаю OPKG с нуля

opkg update
opkg install curl
cd /opt/tmp
curl -sOfL https://cutt.ly/kvas_update

Далее в Web CLI:

opkg dns-override
system configuration save
system reboot

Снова возвращаемся в Entware, вывод команд: kvas_install_debug.txt и kvas_install_iptables.txt

cd /opt/tmp
sh ./kvas_update

kvas debug &> ./kvas_install_debug.txt
iptables-save | grep -E 'PREROUTING|nat' | grep -vE '_NDM|\*|\:' &> ./kvas_install_iptables.txt

Теперь пытаемся включить КВАС для клиентов IKEv2, вывод команд: kvas_netadd_debug.txt и kvas_netadd_iptables.txt

kvas vpn net add

cd /opt/tmp
kvas debug &> ./kvas_netadd_debug.txt
iptables-save | grep -E 'PREROUTING|nat' | grep -vE '_NDM|\*|\:' &> ./kvas_netadd_iptables.txt

Т.к. добавлен неверный несуществующий интерфейс, то функционал этой задачи не работает. Удалим правила расшаривания КВАСа и добавим правильные руками, вывод команд: kvas_manual_debug.txt и kvas_manual_iptables.txt

kvas vpn net del
reboot
/opt/sbin/iptables -A PREROUTING -w -t nat -i eth3 -s 192.168.2.0/24 -p tcp -m set --match-set unblock dst -j REDIRECT --to-port 1181
/opt/sbin/iptables -A PREROUTING -w -t nat -i eth3 -s 192.168.2.0/24 -p udp -m set --match-set unblock dst -j REDIRECT --to-port 1181

cd /opt/tmp
kvas debug &> ./kvas_manual_debug.txt
iptables-save | grep -E 'PREROUTING|nat' | grep -vE '_NDM|\*|\:' &> ./kvas_manual_iptables.txt

qzeleza commented 9 months ago

Доброго дня

Благодарю Вас подробное описание и соотвествующие "логи". Не ясно, только, удалось ли Вам заставить работать Квас с клиентами гостевой сети, после ручного добавления правил?

Также, остается загадкой, форматировали Вы флешку или, как минимум, проверяли ли Вы правила iptables с неверным интерфейсом ikev2 до установки Кваса на предмет их отсутствия, чтобы предотвратить их наличие от предыдущих версий Кваса?

Проверку можно осуществить командой iptables-save | grep -E 'PREROUTING|nat' | grep -vE '_NDM|\*|\:' &> ./has_rules_ikev2_chains.txt, если правила остались, то необходимо их удалить командой: iptables -D PREROUTING -t nat -i ikev2 -p udp -m set --match-set unblock dst -j REDIRECT --to-ports 1181

AltGrF13 commented 9 months ago

Не ясно, только, удалось ли Вам заставить работать Квас с клиентами гостевой сети, после ручного добавления правил?

В таком режиме (ручного добавления правил) оно прекрасно работает около года. Решение закинуто на форум, и там им успешно пользовались и другие. Небольшой фикс (pull request), чтобы правила не вылетали, от меня Вы тоже приняли.

остается загадкой, форматировали Вы флешку

В сообщении ранее указал, что заминка вызвана как раз смертью флешки. Это новая, opkg полностью удалялся и отключался. Ещё по логам можно увидеть, что эти правила (с интерфейсом ikev2) создаёт как раз kvas vpn net add, до этой команды их нет.

если правила остались, то необходимо их удалить командой

Сначала тоже хотел удалить через iptables -D, но потом заметил, что kvas vpn net del с перезагрузкой их очищают. Поэтому и указал в списке команд 3го блока reboot, да и по kvas_manual_iptables.txt видно, что этих правил больше нет.

qzeleza commented 9 months ago

Если все так, как Вы пишите прошу предоставить доступ к своему устройству до 10 декабря включительно, чтобы я смог выявить проблему на месте, так как у меня на моем тестовом устройстве данная проблема не появляется и указанные Вами правила с сетью ikev2 не создаются - все работает штатно с созданием и удалением правил подсказанными Вами в своих сообщениях Выше.

AltGrF13 commented 9 months ago

Здравствуйте! Хотел сэкономить Вам время и сел поотлаживать сам (хотя мой профиль — веб). Выяснилась проблема — после kvas vpn net add настройки VPN-сервер IKEv2 сбрасываются, в частности IP-адреса откатываются на дефолтные, что видно в логе:

IpSec::Config::Ike::Policy: "VirtualIPServerIKE2": reset proposal.
IpSec::Config::Manager: removed ike proposal "VirtualIPServerIKE2".
IpSec::Config::Profile: "VirtualIPServerIKE2": reset policy.
IpSec::Config::Manager: removed crypto ike policy "VirtualIPServerIKE2".
IpSec::Config::CryptoMap: "VirtualIPServerIKE2": reset transform-set.
IpSec::Config::Manager: removed crypto ipsec transform-set "VirtualIPServerIKE2".
IpSec::Config::CryptoMap: "VirtualIPServerIKE2": reset profile.
IpSec::Config::Manager: removed crypto ipsec profile "VirtualIPServerIKE2".

Т.к. только что перезапустились все интерфейсы, то КВАС осуществляет:

Производим удаление стандартных правил в таблице nat, цепочке PREROUTING для SHADOWSOCKS
Производим удаление правил match-set в таблице nat, цепочке PREROUTING для REDIRECT
Подключаем правила для SHADOWSOCKS интерфейса br0 порт 1181.
Подключаем правила для корректной работы DNS трафика через 53 порт:
Интерфейс: br0, IP: 192.168.1.1, протокол: tcp.
Подключаем правила для корректной работы DNS трафика через 53 порт:
Интерфейс: br0, IP: 192.168.1.1, протокол: udp.
Подключаем правила маркировки гостевого трафика для SHADOWSOCKS.

Т.е. функция ikev2_net_access_add делает всё правильно (как Вы и указывали, она просто не может создать его не верно), но что-то вызывает рухание интерфейсов и правила пересоздаются (уже неправильные). Проблем, фактически, две:

В файле opt\etc\ndm\ndm функция ip4_add_selected_guest_to_ssr_network не полная, как раз там для гостевой создаются правила с -i ikev2. Как я понимаю, для воспроизведения ситуации не обязательно рушить интерфейсы; после ребута ситуация будет аналогична — гостевые правила создадутся без учёта проверки, что это ikev2 (что делается в opt\bin\libs\vpn).
При основном соединении через SS вызов команды kvas vpn net add вызывает сброс настроек IKEv2. Прям в админке роутера это видно. Методом исключения выяснил, что к этому приводит дёргание curl -s -d. Вызов curl с параметром -d отправляет POST-запрос, что API Кинетика воспринимает как присвоение новых значений. Наверное, вы хотели указать dns-server; но при этом сбрасываете в дефолт настройки пулла адресов и «Множественный вход». Если какие-то параметры не указаны, то они сбрасываются. Может оставить тут просто предупреждение, чтобы человек сменил руками DNS в админке? А то, если появятся новые настройки IKEv2 (а они недавно появлялись), то они будут теряться, код будет неустойчивым, требовать внимания.

qzeleza commented 9 months ago

И Вы здравствуйте. Благодарю Вас за столь подробный "разбор" кода.

По пункту первому - функция ip4_add_selected_guest_to_ssr_network устарела и не используется в коде (есть только ее описание), потому от куда может появляться правило с названием интерфейса ikev2 пока для меня загадка. У меня на тестовом устройстве таких правил нет.

По пункту второму, прошу Вас привести, пример подобных изменений. могу предположить, что здесь могут добавляться какие либо параметры, но менять имена переменных вряд ли будут, ради сохранения совместимости. Так же пока не понял, почему сброс параметров является проблемой для корректной работы команды kvas vpn net add. Поясните пожалуйста.

AltGrF13 commented 9 months ago

По первому пункту.

Ну хорошо, при перезапуске роутера какая функция пересоздаёт правила расшаривания? Читает настройки из конфига и повторяет их. Вот она и не знает, что в случае IKEv2 правила делаются по-другому.

Суть ситуации ещё раз: Вы отправляете POST-запрос на смену DNS у IKEv2, сетевые интерфейсы роутера перезапускаются; КВАС после этого дёргает эту функцию из файла ndm, а она в логе роутера оставляет сообщение Подключаем правила маркировки гостевого трафика для SHADOWSOCKS.

AltGrF13 commented 9 months ago

По второму пункту.

В админке роутера у IKEv2 сервера есть 6 настроек. Когда Вы curl'ом делаете POST-запрос лишь с DNS-сервером, то другие настройки (Начальный IP-адрес, Пул IP-адресов, Множественный вход) сбрасываются в значения по-умолчанию. Т.е. сохранённые настройки перезаписываются.

Я вижу тут 2 выхода:

считывать все настройки, регуляркой заменять dns-адрес и отправлять JSON обратно (тогда сменится лишь dns);
просто считывать DNS GET запросом и ругаться на пользователя, чтобы менял настройки в админке сам.

AltGrF13 commented 9 months ago

считывать все настройки, регуляркой заменять dns-адрес и отправлять JSON обратно (тогда сменится лишь dns)

Если DNS сервер IKEv2 уже был верным, то POST-запрос на изменение можно и вовсе не отправлять, зачем лишний раз рестартовать сетевые интерфейсы? Сразу эта мысль почему-то не пришла в голову, поэтому отправил отдельным комментарием.

qzeleza commented 9 months ago

Ну хорошо, при перезапуске роутера какая функция пересоздаёт правила расшаривания?

в файле /opt/apps/kvas/bin/libs/vpn начиная с 783 строки и ниже

Если DNS сервер IKEv2 уже был верным, то POST-запрос на изменение можно и вовсе не отправлять, зачем лишний раз рестартовать сетевые интерфейсы?

Добавил и перебрал в 1.1.5-final-23 - обновитесь пожалуйста.

qzeleza commented 8 months ago

Прошу дать обратную связь по данному вопросу.

AltGrF13 commented 8 months ago

Здравствуйте, огромное спасибо за быструю обратную связь!

Сделал kvas upgrade full (обновилось с 21 на 25 версию); проверил, что среди правил iptables только 4 начальные, необходимые для работы SS у Wi-Fi клиентов.

Замечание: для логирования Вы предлагали использовать первую команду; я предлагаю использовать вторую с проверкой начала строки, иначе правила с портами в лог не попадают (которые КВАС же в этой задаче и добавляет)
```
было_: iptables-save | grep -E 'PREROUTING|nat' | grep -vE '_NDM|\*|\:'
стало: iptables-save | grep -E 'PREROUTING|nat' | grep -vE '_NDM|^\*|^\:'
```

Запускаем слежение за логом роутера, делаем kvas vpn net add

Дек 13 08:59:55 ndm
Core::Scgi::ThreadPool: unable to parse JSON (http/rci).
Дек 13 08:59:55 ndm
Core::Scgi::Tools: bad request: invalid payload.

При формировании JSON в /bin/libs/vpn:868 пропущены 3 запятые новых параметров, он не валиден. После их добавления этой ошибки в логе нет.

было_: curl -s -d '{"enable": true, "nat": true, "dns-server": "'"${ikev2_dns}"'" "poll-size": "'"${poll_size}"'" "multi-login": "'"${multi_login}"'" "sa-compat": "'"${sa_compat}"'"}' \
стало: curl -s -d '{"enable": true, "nat": true, "dns-server": "'"${ikev2_dns}"'", "poll-size": "'"${poll_size}"'", "multi-login": "'"${multi_login}"'", "sa-compat": "'"${sa_compat}"'"}' \

Благодаря не перезаписи настроек IKEv2, сетевые интерфейсы не перезапускались, и я видел среди правил iptables правильные -s 192.168.2.0/24 -i eth3. Но фикс руками ошибки с запятыми возвращает нас к старой ситуации. Смотрим в лог, видим системный рестарт всех правил, связанных с IKEv2. На что КВАС реагирует

Дек 13 10:10:24 КВАС
Производим удаление стандартных правил в таблице nat, цепочке PREROUTING для SHADOWSOCKS
Дек 13 10:10:24 КВАС
Производим удаление правил match-set в таблице nat, цепочке PREROUTING для REDIRECT
Дек 13 10:10:25 КВАС
Подключаем правила для SHADOWSOCKS интерфейса br0 порт 1181.
Дек 13 10:10:25 КВАС
Подключаем правила для корректной работы DNS трафика через 53 порт:
Дек 13 10:10:25 КВАС
Интерфейс: br0, IP: 192.168.1.1, протокол: tcp.
Дек 13 10:10:25 КВАС
Подключаем правила для корректной работы DNS трафика через 53 порт:
Дек 13 10:10:25 КВАС
Интерфейс: br0, IP: 192.168.1.1, протокол: udp.
Дек 13 10:10:26 КВАС
Подключаем правила маркировки гостевого трафика для SHADOWSOCKS.

Единственное место в коде, которое может породить последнее лог-сообщение, это /etc/ndm/ndm:238. Та самая ip4_add_selected_guest_to_ssr_network, которая с Ваших слов

устарела и не используется в коде (есть только ее описание)

Как можно добиться этой ситуации по-другому? Просто в админке роутера зайдите в настройки IKEv2, измените какую-нибудь настройку (например, «Пул IP-адресов») и нажмите «Сохранить». Это действие, аналогично вызову API, перестроит сетевые правила; на что КВАС отреагирует (в случае основного соединения SS) вызовом вышеназванной функции, которая и добавляет -i ikev2. Достаточно в этом месте проверять не ikev2 ли перед нами и добавлять иные правила.

По-прежнему ловлю сброс параметров: Начальный IP-адрес, Пул IP-адресов. В случае пула описка, грепаете Вы pool-, а отправляете poll-
```
poll_size=$(echo "${ikev2}" | grep pool-size | cut -d':' -f2 | sed 's/[\,\" ]//g;')
```

curl -s -d '{"enable": true, "nat": true, "dns-server": "'"${ikev2_dns}"'", "poll-size": "'"${poll_size}"'", "multi-login": "'"${multi_login}"'", "sa-compat": "'"${sa_compat}"'"}' \

Отправки `pool-start` и вовсе нет, он сбрасывается в дефолтный.

5. Не понимаю, чего хотели добиться в первых правилах гостевой сети

            if ! iptables-save | grep PREROUTING | grep "${net_ip}" | grep eth3 | grep DNAT | grep -q ":53" ; then

                iptables -A PREROUTING -t nat -i eth3 -p tcp -j DNAT --to "${net_ip}:53"
                iptables -A PREROUTING -t nat -i eth3 -p udp -j DNAT --to "${net_ip}:53"
            fi

Если это попытка повторить DNS правила для `br0`, то там было

ip4tables PREROUTING -w -t nat -i "${interface}" -p "${protocol}" --dport ${DNS_PORT} -j DNAT --to "${local_ip}"

Т.е. ожидалась бы похожая конструкция с `--dport`; DNS-сервером, а не несуществующий 192.168.2.1:53; портом DNS из переменной и ограничением `-s ${net_pool}` (на `eth3` много другого трафика). С хардварной сетевухой `eth3` вообще нужно быть очень осторожным, описанные правила опасны!

В описании задачи я писал
>Два новых DNS-правила iptables, как у других VPN-подключений, не нужны. Достаточно, чтобы стояла эта настройка.

Причина — при подключении через IKEv2 клиенты ловят настройку «DNS-сервер» и уже используют его насильно, ничего отлавливать и перезаписывать (как в случае домашней сети `br0` или любого другого виртуального сетевого интерфейса) не требуется. Сейчас у меня на ручных правилах работает именно так — 2 правила, а не 4.

Итого я предлагаю этот блок удалить. Или хотя бы, если всенепременно хочется словить DNS косячных IKEv2 клиентов, то написать корректно:

                iptables -A PREROUTING -t nat -s ${net_pool} -i eth3 -p tcp --dport ${DNS_PORT} -j DNAT --to "${ikev2_dns}"
                iptables -A PREROUTING -t nat -s ${net_pool} -i eth3 -p udp --dport ${DNS_PORT} -j DNAT --to "${ikev2_dns}"

AltGrF13 commented 8 months ago

Могу попытаться к выходным собрать pull-request, если описал не понятно и/или у Вас недостаточно времени. Ибо в местах кода разобрался, и все ситуации воспроизвожу довольно легко. Больше времени уходит на составление таких текстов)

qzeleza commented 8 months ago

Здравствуйте, благодарю за столь подробный анализ кода. Одно только мне пока не ясно, почему взяли именно eth3, а не eth21 (как пример)?

qzeleza commented 8 months ago

В любом случае, попробуйте сейчас обновиться на 26 релиз.

AltGrF13 commented 8 months ago

Одно только мне пока не ясно, почему взяли именно eth3, а не eth21 (как пример)?

eth3 — интерфейс WAN-порта. Сам Keenetic вешает свои политики обработки IPSec именно на него, поэтому мы пытаемся заворачивать трафик IKEv2/IPSec (полное название) тоже там. Но на этом интерфейсе весь трафик роутера в интернет фактически, поэтому отделить IKEv2шный мы можем лишь по диапазону IP.

AltGrF13 commented 8 months ago

Здравствуйте!

Отправки pool-start и вовсе нет, он сбрасывается в дефолтный

Это по-прежнему делается, в opt/bin/libs/vpn:849

было: curl -s -d '{"enable": true, "nat": true, "dns-server": "'"${ikev2_dns}"'",                                  "pool-size": "'"${pool_size}"'", "multi-login": "'"${multi_login}"'", "sa-compat": "'"${sa_compat}"'"}' \
надо: curl -s -d '{"enable": true, "nat": true, "dns-server": "'"${ikev2_dns}"'", "pool-start": "'"${net_pool}"'", "pool-size": "'"${pool_size}"'", "multi-login": "'"${multi_login}"'", "sa-compat": "'"${sa_compat}"'"}' \

Аналогичное забывание отправки pool-start есть и в ikev2_net_access_del, оно тоже сбросит настройку пользователя в значение по умолчанию.
В этом пункте не ошибка, а вопрос логики работы. Если я дёргаю kvas vpn net del и выбираю IKEv2, то Вы отключаете IKEv2 и вырубаете клиентам интернет ("nat": false). По идее же, если я отключаю обход блокировок КВАСом, то я просто хочу отключить обход (те самые правила iptables), а не обход + интернет клиентам IKEv2. Надо либо удалить этот блок кода вовсе
```
if [ "${dns_server}" != "${ikev2_dns}" ]; then

    pool_size=$(echo "${ikev2}" | grep pool-size | cut -d':' -f2 | sed 's/[\,\" ]//g;')
    multi_login=$(echo "${ikev2}" | grep multi-login | cut -d':' -f2 | sed 's/[\,\" ]//g;')
    sa_compat=$(echo "${ikev2}" | grep sa-compat | cut -d':' -f2 | sed 's/[\,\" ]//g;')
    curl -s -d '{"nat": false, "dns-server": "'"${ikev2_dns}"'", "pool-size": "'"${pool_size}"'", "multi-login": "'"${multi_login}"'", "sa-compat": "'"${sa_compat}"'"}' \
        "${LOCALHOST_IP}:79/rci/crypto/virtual-ip-server-ikev2" &> /dev/null
    sleep 1
fi
```
, либо спрашивать пользователя «Отключить и сервер IKEv2 заодно?», передавая весь зоопарк параметров с "enable": false. Но вот nat отключать не следует в обоих случаях, это решать пользователю. В 90% случаев не используют VPN с обрезанным интернетом.
Предыдущий вопрос натолкнул на мысль, что в ikev2_net_access_add условия вызова API два: если IKEv2 отключен или DNS указан не верно. Но нужно проверять ещё одно ИЛИ; если NAT false, то это тоже повод насильно его включить.
Всё та же проблема перезапуска сетевых интерфейсов. Если это происходит (например, человек в админке роутера изменил настройки IKEv2), то все правила iptables на этом сетевом интерфейсе сбрасываются. Но КВАС ловит это и перенавешивает их заново. opt/etc/ndm/netfilter.d/100-dns-local вызывает set_guest_nets_rules, в нём идёт вызов ip4_add_guest_to_ssr_network, в котором вызывается ip4_add_selected_guest_to_ssr_network. Но вызывается с одним параметром, отчего он придёт к error "Отсутствует один из параметров: сетевой интерфейс или сетевой пул.". Предлагаю сделать функцию более устойчивой
```
if [ "${net_inface}" = ikev2 ] ; then
    net_inface=$(get_entware_ikev2_inface)
    [ -z "${net_pool}" ] && {
        # здесь добавить код по заполнению переменной net_pool из API
    }
else
    net_pool=$(ip a | grep global | grep "${net_inface}" | sed 's/inet $.*\/[0-9]\{1,3\}$ scope.*/\1/; s/[ ]//g; s/$.*$\.[0-9]\{1,3\}\/$[0-9]\{1,3\}$$/\1.0\/\2/')
fi
```
Продолжение случая 5, если даже код в ip4_add_selected_guest_to_ssr_network пройдёт дальше, то он вызовет add_ikev2_net_to_config. Т.е. попытается записать в конфиг ikev2 снова (а он не должен этого делать, мы восстанавливаем правила после перезапуска интерфейсов). Может имеет смысл перенести вызов add_ikev2_net_to_config в ikev2_net_access_add
```
    if has_ssr_enable ;then
        ip4_add_selected_guest_to_ssr_network ikev2 "${net_pool}"
        # вот эту строчку перенёс сюда
        add_ikev2_net_to_config
    else
        if ! iptables-save | grep POSTROUTING | grep "${net_pool}" | grep eth3 | grep -q MASQUERADE ; then
            iptables -A POSTROUTING -t nat -s "${net_pool}" -o eth3 -j MASQUERADE
            add_ikev2_net_to_config
        fi
    fi
```

По IKEv2 всё, вопрос по расшариванию SS другим подсетям (гостевой или любым другим VPN). Сейчас для них добавятся аналогичные правила с попыткой ограничения диапазона IP. Но стоит ли оно того, если для неIPSEC интерфейсов создаётся свой отдельный? Итак всё ограничено конкретным сетевым интерфейсом, добавление диапазона IP излишне усложнит логику (ведь уметь получать диапазон надо будет и для гостевых, и для всех вариантов VPN-серверов). Может имеет смысл изменить код в примерно такой

if ЭТОIKEv2 then
    # в этом блоке код, который имеется сейчас
    if ! iptables-save | grep PREROUTING | grep "${net_pool}" | grep "${net_inface}" | grep unblock | grep REDIRECT | grep -q "${port}" ; then
        log_warning "Подключаем правила маркировки гостевого трафика IKEv2 для SHADOWSOCKS."

        iptables -A PREROUTING -t nat -s ${net_pool} -i ${net_inface} -p tcp -m set --match-set unblock dst -j REDIRECT --to-port ${port}
        iptables -A PREROUTING -t nat -s ${net_pool} -i ${net_inface} -p udp -m set --match-set unblock dst -j REDIRECT --to-port ${port}
    fi
else
    log_warning "Подключаем правила маркировки гостевого трафика ${net_inface} для SHADOWSOCKS."

    if ! iptables-save | grep PREROUTING | grep "${net_inface}" | grep set | grep unblock | grep REDIRECT | grep -q "${port}" ; then
        iptables -A PREROUTING -t nat -i ${net_inface} -p tcp -m set --match-set unblock dst -j REDIRECT --to-port ${port}
        iptables -A PREROUTING -t nat -i ${net_inface} -p udp -m set --match-set unblock dst -j REDIRECT --to-port ${port}
    fi

    # если это не IPsec, то нужны ещё и правила DNS
    router_ip=$(get_router_ip)
    if ! iptables-save | grep PREROUTING | grep "${net_inface}" | grep "${DNS_PORT}" | grep DNAT | grep -q "${router_ip}" ; then
        iptables -A PREROUTING -t nat -i ${net_inface} -p tcp --dport ${DNS_PORT} -j DNAT --to "${router_ip}"
        iptables -A PREROUTING -t nat -i ${net_inface} -p udp --dport ${DNS_PORT} -j DNAT --to "${router_ip}"
    fi
fi

Если человек включит в админке сервер OpenVPN, PPTP или SSTP — для них всех и гостевой сети второй блок.

qzeleza commented 8 months ago

Здравствуйте, С 1-6 пункты согласен, изменения внес в 27 релиз.

Относительно 7 пункта, логика работы другая для гостевых сетей; Они начинают самостоятельно работать без добавления каких либо правил, в случае если их интерфейс начинает прослушиваться работающим в текущий момент DNS сервером.

qzeleza commented 8 months ago

Прошу дать обратную связь, решена ли проблема?

AltGrF13 commented 8 months ago

Здравствуйте, опять извиняюсь за задержку.

В пункте 5 (функция ip4_add_selected_guest_to_ssr_network) код должен быть примерно таким, сейчас берётся не тот диапазон (после перезапуска интерфейсов правила восстанавливаются не верно)

    if [ "${net_inface}" = ikev2 ] ; then
        net_inface=$(get_entware_ikev2_inface)

        [ -z "${net_pool}" ] && {
            # если функция вызвана из ip4_add_guest_to_ssr_network, то net_pool для ikev2 ещё не получен
            ikev2_settings=$(curl -s "${LOCALHOST_IP}:79/rci/crypto/virtual-ip-server-ikev2")
            net_pool=$(echo "${ikev2_settings}" | grep pool-start | cut -d':' -f2 | sed 's/[\,\" ]//g;')
        }
    else
        net_pool=$(ip a | grep global | grep "${net_inface}" | sed 's/inet \(.*\/[0-9]\{1,3\}\) scope.*/\1/; s/[ ]//g; s/\(.*\)\.[0-9]\{1,3\}\/\([0-9]\{1,3\}\)$/\1.0\/\2/')
    fi

В пункте 6 мы перенесли запись конфига, но не удалили его запись в исходной функции (чтобы после перезапуска интерфейсов конфиг не писался снова). Опять функция ip4_add_selected_guest_to_ssr_network

    if ! iptables-save | grep PREROUTING | grep "${net_pool}" | grep "${net_inface}" | grep unblock | grep REDIRECT | grep -q "${port}" ; then
        log_warning "Подключаем правила маркировки гостевого трафика для SHADOWSOCKS."
        iptables -A PREROUTING -t nat -s ${net_pool} -i ${net_inface} -p tcp -m set --match-set unblock dst -j REDIRECT --to-port ${port}
        iptables -A PREROUTING -t nat -s ${net_pool} -i ${net_inface} -p udp -m set --match-set unblock dst -j REDIRECT --to-port ${port}
        #вот это удалить add_ikev2_net_to_config
    fi

По пункту 7 Вас услышал, чуть позже попробую провести более комплексный тест с разными гостевыми и напишу отдельно. Тем более, что по нему корректно будет открыть отдельную задачу, здесь мы рассматриваем только популярную связку SS + IKEv2.

qzeleza commented 8 months ago

Исправления внес, обновитесь пожалуйста.

AltGrF13 commented 8 months ago

Смущает, этот момент при обновлении, но к этому вопросу (SS + IKEv2) он отношения не имеет
Даже при правильных настройках перезапуск сетевых интерфейсов происходит. В функции ikev2_setup должно происходить сравнение DNS IKEv2 и IP роутера, но пытается сравниваться внешний IP (перезапись настроек IKEv2 с перезапуском интерфейсов происходит всегда). В opt/bin/libs/vpn
```
было: ikev2_dns=$(get_external_ip)
надо: ikev2_dns=$(get_router_ip)
```
После этого фикса отправка API-запроса и перезапуска сетевого интерфейса лишний раз не происходит (как и должно быть), но удаление при kvas vpn net del не происходило. При отладке ikev2_net_access_del в opt/etc/ndm/ndm
```
[ -n "${1}" ] && del_ikev2_net_from_config
```
У меня "${1}" отсутствует, вызов второй части не происходит никогда. Если оставить просто del_ikev2_net_from_config, то всё работает.
И ошибка в моём предложенном коде до этого, не докопировал одну строчку, правила восстанавливались для одного IP, а не всего диапазона. Отловить можно при перезапуске роутера или интерфейса (сохранить настройки IKEv2 сервера, например). Надо
```
    [ -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/')
    }
```

AltGrF13 commented 8 months ago

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

Правила iptables сохраняем через iptables-save | grep -E 'PREROUTING|nat' | grep -vE '_NDM|^\*|^\:' &> /opt/tmp/kvas_iptables.txt. Ошибки в логе роутера смотрим, заходя в раздел «Диагностика», оттуда «Показать журнал». Для удобства нажимаем «Очистить журнал».

Отключаем обход всех гостевых kvas vpn net del, открываем слежение за логами роутера, обновляемся kvas upgrade full. Сохраняем лог-файл для iptables командой из начала текста, проверяем корректность правил обхода. Смотрим лог роутера на отсутствие ошибок; скриним, если есть. Сохраняем лог-файл kvas debug &> /opt/tmp/kvas_debug.txt.
Настраиваем проверяемую гостевую сеть в админке роутера (в случае IKEv2 DNS должен быть равен IP роутера, чаще всего это 192.168.1.1), открываем слежение за логами роутера, включаем обход КВАС для гостевой kvas vpn net add. Сохраняем лог-файл для iptables командой из начала текста, проверяем новые правила обхода гостевой. Смотрим лог роутера на отсутствие ошибок (в случае IKEv2 ещё, что перезапуска сетевых интерфейсов нет); скриним, если что-то не так.
Открываем слежение за логами роутера, изменяем настройки гостевой в админке роутера. Сохраняем лог-файл для iptables командой из начала текста, проверяем восстановление правил обхода гостевой. Смотрим лог роутера на отсутствие ошибок и что перезапуск соответствующего сетевого интерфейса произошёл; скриним, если что-то не так.
Открываем слежение за логами роутера, отключаем обход гостевых kvas vpn net del. Сохраняем лог-файл для iptables командой из начала текста, проверяем удаление правил обхода гостевой. Смотрим лог роутера на отсутствие ошибок; скриним, если есть.
Если проверяем гостевую IKEv2, то настраиваем сервер не корректно (например, дефолтный DNS в 78.47.125.180), открываем слежение за логами роутера, включаем обход гостевых для IKEv2 kvas vpn net add. Сохраняем лог-файл для iptables командой из начала текста, проверяем новые правила обхода гостевой. Смотрим лог роутера на отсутствие ошибок и что перезапуск соответствующего сетевого интерфейса произошёл; скриним, если что-то не так.
Перезагружаем роутер. Сохраняем лог-файл для iptables командой из начала текста, проверяем восстановление правил обхода гостевой.

qzeleza commented 8 months ago

Благодарю Вас за желание помочь и Ваш опыт.

Исправления по пп. 2-4 внес - обновитесь пожалуйста.

AltGrF13 commented 8 months ago

2-4 внес

А ведь действительно, нужно было в 3ем проверку изменить, а не убирать вовсе (как Вы и сделали). Сразу не заметил, что есть вызовы ikev2_net_access_del dont_del_config.

AltGrF13 commented 8 months ago

Когда-то просил добавить в документацию примечание:

Если используется VPN-сервер IKEv2/IPsec, то в его настройках нужно изменить служебный DNS 78.47.125.180 на IP-адрес роутера, например, на 192.168.1.1 (по умолчанию).

Сейчас это уже не актуально, КВАС всё проверяет и изменяет сам. Поэтому предлагаю удалить, чтобы не путать пользователей.

qzeleza commented 8 months ago

Сейчас это уже не актуально, КВАС всё проверяет и изменяет сам. Поэтому предлагаю удалить, чтобы не путать пользователей.

Убрал.

Все ли работает?

AltGrF13 commented 8 months ago

Обновил протокол проверки обхода гостевой сети, сделал его более универсальным, не только для IKEv2. И расписал более подробно. Предлагаю им (с какими-то доработками от Вас) и отвечать на будущие вопросы из разряда «не работает обход для такой-то сети». 6 логов для разных случаев (только что добавили, перезагрузились, удалили и т.д.) позволят лучше понять в какой именно части проблема.

Все ли работает?

Как раз проходил по составленному списку. Все 6 пунктов отработали, ура! Вопрос можно закрывать.

qzeleza commented 8 months ago

Благодарю Вас за усидчивость и проделанную работу.

Обновил Wiki и включил туда Ваш протокол проверки, с небольшими изменениями косметического характера. Тикет закрываю.