Closed AltGrF13 closed 8 months ago
Благодарю, в следующей версии постараюсь включить в пакет данный функционал.
Прошу дать обратную связь по выявленной Вами проблеме в крайней версии пакета Квас - 1.1.5-pr2. Решена ли Ваша проблема в этой версии пакета?
Желательно это сделать вплоть до 26 ноября текущего года. Детали описаны на форуме по этой ссылке.
Если ошибка воспроизводима в крайней версии Кваса - откройте тикет вновь. Пока же тикет закрываю из-за отсутствия обратной связи по ошибке.
Здравствуйте. К сожалению, не было времени успеть до срока. Добрался сейчас.
Установил с нуля через
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
:
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. Переоткрыть задачу не смог.
Здравствуйте, Прошу Вас, по возможности, прислать вывод следующих команд
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
Благодарю Вас
- красным — то, что добавил КВАС. В качестве сетевого интерфейса указан
ikev2
, но такого не существует (IPSec, в отличии от других VPN протоколов, не создаёт сетевые интерфейсы). Также КВАС пытался добавить 2 правила для DNS, а этого не требуется, т.к. в настройках IKEv2 уже указан IP роутера.
Не соответствует действительности, так как в новой 1.1.5-final-7 нет такого кода, который бы добавлял указанный Вами правила выше для интерфейса ikev2. Возможно это осталось у Вас от предыдущих экспериментов.
Сейчас, с данной конфигурацией, присланной выше, у Вас клиенты ikev2 подключаются к Квасу?
Ставил через рекомендованные команды. Раз такое подозрение (и Вы писали на форуме, что обновили скрипт установки), решил провести полную переустановку.
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 с переформатированием флешки.
Может Вас смутило то, что я прислал результат curl со своими вручную добавленными 2 правилами? Ну вот результат без них kvas_iptables.txt
Нет, меня смутило, то что добавлены правила с интерфесом ikev2, который там физически не может появляться.
Для чистоты эксперимента могу переустановить OPKG с переформатированием флешки.
Если нет возможности дать доступ на устройство, то да, было бы здорово.
Странно, у меня вот VirtualIP IPSec Ikev2 используется как интерфейс для обхода, уже довольно давно (год), все работает (IPSec виден при сканировании интерфейсов)
Странно, у меня вот 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
2.
~ # 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
3.
~ # 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?
А изначально вопрос в том чтобы на роутере, где размещен сервер VurtualIP использовать клиента VirtualIP для обхода блокировок?
Нет, здесь речь идет о том, чтобы клиентам VurtualIP-IPSec-сервера иметь возможность заходить по списку хостов в сеть через ssr (через которое и работает Квас).
Спасибо, В моём случае есть вариант другого кинетика, где настроен обход через VPN WG, также настроен VirtualIP сервер, к нему подключаются клиенты (например телефон), и с телефона начинает работать обход.
Не знаю есть ли тут разница между wg\ssr но обход работает для клиента VirtualIP-IPSec IKEv2 Правда, все это уже много месяцев работает на 1.1.3 квасе и трогать не хочется)
Не знаю есть ли тут разница между wg\ssr но обход работает для клиента VirtualIP-IPSec IKEv2 Правда, все это уже много месяцев работает на 1.1.3 квасе и трогать не хочется)
Да, разница имеется, но, если не трудно (переустановки ни какой не требуется), пришлите пожалуйста данные по выполненным выше командам на нем.
переустановить OPKG с переформатированием флешки
К сожалению, при очередном переформатировании на ПК флешка отъехала в мир иной — сыплет ошибками. Проверку смогу завершить лишь через неделю, как приедет новая. Остался без OPKG(
Странно, у меня вот 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
~ # 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"
}~ #
Здравствуйте. Ну что ж, устанавливаю 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
Доброго дня
Благодарю Вас подробное описание и соотвествующие "логи". Не ясно, только, удалось ли Вам заставить работать Квас с клиентами гостевой сети, после ручного добавления правил?
Также, остается загадкой, форматировали Вы флешку или, как минимум, проверяли ли Вы правила 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
Не ясно, только, удалось ли Вам заставить работать Квас с клиентами гостевой сети, после ручного добавления правил?
В таком режиме (ручного добавления правил) оно прекрасно работает около года. Решение закинуто на форум, и там им успешно пользовались и другие. Небольшой фикс (pull request), чтобы правила не вылетали, от меня Вы тоже приняли.
остается загадкой, форматировали Вы флешку
В сообщении ранее указал, что заминка вызвана как раз смертью флешки. Это новая, opkg полностью удалялся и отключался.
Ещё по логам можно увидеть, что эти правила (с интерфейсом ikev2) создаёт как раз kvas vpn net add
, до этой команды их нет.
если правила остались, то необходимо их удалить командой
Сначала тоже хотел удалить через iptables -D
, но потом заметил, что kvas vpn net del
с перезагрузкой их очищают. Поэтому и указал в списке команд 3го блока reboot
, да и по kvas_manual_iptables.txt видно, что этих правил больше нет.
Если все так, как Вы пишите прошу предоставить доступ к своему устройству до 10 декабря включительно, чтобы я смог выявить проблему на месте, так как у меня на моем тестовом устройстве данная проблема не появляется и указанные Вами правила с сетью ikev2 не создаются - все работает штатно с созданием и удалением правил подсказанными Вами в своих сообщениях Выше.
Здравствуйте! Хотел сэкономить Вам время и сел поотлаживать сам (хотя мой профиль — веб). Выяснилась проблема — после 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
).kvas vpn net add
вызывает сброс настроек IKEv2. Прям в админке роутера это видно. Методом исключения выяснил, что к этому приводит дёргание curl -s -d
. Вызов curl с параметром -d отправляет POST-запрос, что API Кинетика воспринимает как присвоение новых значений. Наверное, вы хотели указать dns-server; но при этом сбрасываете в дефолт настройки пулла адресов и «Множественный вход». Если какие-то параметры не указаны, то они сбрасываются. Может оставить тут просто предупреждение, чтобы человек сменил руками DNS в админке? А то, если появятся новые настройки IKEv2 (а они недавно появлялись), то они будут теряться, код будет неустойчивым, требовать внимания.И Вы здравствуйте. Благодарю Вас за столь подробный "разбор" кода.
По пункту первому - функция ip4_add_selected_guest_to_ssr_network устарела и не используется в коде (есть только ее описание), потому от куда может появляться правило с названием интерфейса ikev2 пока для меня загадка. У меня на тестовом устройстве таких правил нет.
По пункту второму, прошу Вас привести, пример подобных изменений. могу предположить, что здесь могут добавляться какие либо параметры, но менять имена переменных вряд ли будут, ради сохранения совместимости. Так же пока не понял, почему сброс параметров является проблемой для корректной работы команды kvas vpn net add
. Поясните пожалуйста.
По первому пункту.
Ну хорошо, при перезапуске роутера какая функция пересоздаёт правила расшаривания? Читает настройки из конфига и повторяет их. Вот она и не знает, что в случае IKEv2 правила делаются по-другому.
Суть ситуации ещё раз: Вы отправляете POST-запрос на смену DNS у IKEv2, сетевые интерфейсы роутера перезапускаются; КВАС после этого дёргает эту функцию из файла ndm, а она в логе роутера оставляет сообщение Подключаем правила маркировки гостевого трафика для SHADOWSOCKS
.
По второму пункту.
В админке роутера у IKEv2 сервера есть 6 настроек. Когда Вы curl'ом делаете POST-запрос лишь с DNS-сервером, то другие настройки (Начальный IP-адрес, Пул IP-адресов, Множественный вход) сбрасываются в значения по-умолчанию. Т.е. сохранённые настройки перезаписываются.
Я вижу тут 2 выхода:
считывать все настройки, регуляркой заменять dns-адрес и отправлять JSON обратно (тогда сменится лишь dns)
Если DNS сервер IKEv2 уже был верным, то POST-запрос на изменение можно и вовсе не отправлять, зачем лишний раз рестартовать сетевые интерфейсы? Сразу эта мысль почему-то не пришла в голову, поэтому отправил отдельным комментарием.
Ну хорошо, при перезапуске роутера какая функция пересоздаёт правила расшаривания?
в файле /opt/apps/kvas/bin/libs/vpn начиная с 783 строки и ниже
Если DNS сервер IKEv2 уже был верным, то POST-запрос на изменение можно и вовсе не отправлять, зачем лишний раз рестартовать сетевые интерфейсы?
Добавил и перебрал в 1.1.5-final-23 - обновитесь пожалуйста.
Прошу дать обратную связь по данному вопросу.
Здравствуйте, огромное спасибо за быструю обратную связь!
Сделал 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}"'"}' \
-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 ли перед нами и добавлять иные правила.
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}"
Могу попытаться к выходным собрать pull-request, если описал не понятно и/или у Вас недостаточно времени. Ибо в местах кода разобрался, и все ситуации воспроизвожу довольно легко. Больше времени уходит на составление таких текстов)
Здравствуйте, благодарю за столь подробный анализ кода. Одно только мне пока не ясно, почему взяли именно eth3, а не eth21 (как пример)?
В любом случае, попробуйте сейчас обновиться на 26 релиз.
Одно только мне пока не ясно, почему взяли именно eth3, а не eth21 (как пример)?
eth3 — интерфейс WAN-порта. Сам Keenetic вешает свои политики обработки IPSec именно на него, поэтому мы пытаемся заворачивать трафик IKEv2/IPSec (полное название) тоже там. Но на этом интерфейсе весь трафик роутера в интернет фактически, поэтому отделить IKEv2шный мы можем лишь по диапазону IP.
Здравствуйте!
Отправки 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 — для них всех и гостевой сети второй блок.
Здравствуйте, С 1-6 пункты согласен, изменения внес в 27 релиз.
Относительно 7 пункта, логика работы другая для гостевых сетей; Они начинают самостоятельно работать без добавления каких либо правил, в случае если их интерфейс начинает прослушиваться работающим в текущий момент DNS сервером.
Прошу дать обратную связь, решена ли проблема?
Здравствуйте, опять извиняюсь за задержку.
В пункте 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.
Исправления внес, обновитесь пожалуйста.
Смущает, этот момент при обновлении, но к этому вопросу (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/')
}
Решил ещё записать протокол проверки обхода гостевой сети (подходит для любой); чтобы в будущем, если понадобится, алгоритм не пришлось вспоминать.
Правила 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 командой из начала текста, проверяем восстановление правил обхода гостевой.
Благодарю Вас за желание помочь и Ваш опыт.
Исправления по пп. 2-4 внес - обновитесь пожалуйста.
2-4 внес
А ведь действительно, нужно было в 3ем проверку изменить, а не убирать вовсе (как Вы и сделали). Сразу не заметил, что есть вызовы ikev2_net_access_del dont_del_config
.
Когда-то просил добавить в документацию примечание:
Если используется VPN-сервер IKEv2/IPsec, то в его настройках нужно изменить служебный DNS 78.47.125.180 на IP-адрес роутера, например, на 192.168.1.1 (по умолчанию).
Сейчас это уже не актуально, КВАС всё проверяет и изменяет сам. Поэтому предлагаю удалить, чтобы не путать пользователей.
Сейчас это уже не актуально, КВАС всё проверяет и изменяет сам. Поэтому предлагаю удалить, чтобы не путать пользователей.
Убрал.
Все ли работает?
Обновил протокол проверки обхода гостевой сети, сделал его более универсальным, не только для IKEv2. И расписал более подробно. Предлагаю им (с какими-то доработками от Вас) и отвечать на будущие вопросы из разряда «не работает обход для такой-то сети». 6 логов для разных случаев (только что добавили, перезагрузились, удалили и т.д.) позволят лучше понять в какой именно части проблема.
Все ли работает?
Как раз проходил по составленному списку. Все 6 пунктов отработали, ура! Вопрос можно закрывать.
Благодарю Вас за усидчивость и проделанную работу.
Обновил Wiki и включил туда Ваш протокол проверки, с небольшими изменениями косметического характера. Тикет закрываю.
IPSec, в отличии от привычных VPN-решений, не создаёт сетевые интерфейсы, только политики обработки. Поэтому через ssr guest и vpn guest на него обход блокировок не добавить.
1. При выводе списка
Состоящего из сетевых VPN-интерфейсов и guest сети, можно дёрнуть из API Keenetic'а (команды оттуда КВАСом поддерживаются) show running-config. Если есть блок crypto map VirtualIPServerIKE2 и в нём есть 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
Собственно, сверяем 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):
Итого
Расшаривание на клиентов IKEv2 сервера роутера, по сути — 2 правила и одна настройка. Поддержка IKEv2 для vpn guest, скорее всего, не сложнее. Просто нужно помнить, что сейчас не свой собственный интерфейс -i sstp0, а весь сетевой порт -i eth3 плюс правило диапазона IP у клиентов VPN-сервера -s 192.168.2.0/24.