Closed wildrun0 closed 6 months ago
Есть ли какая либо информация дополнительная о проблеме?
Все что могу предоставить по теме:
- После обрыва и восстановления соединения, не работает маршрутизация
Как Вы понимаете, что соединение восстановлено?
- Маршрутизация не работает даже спустя продолжительное время (т.е. я так подозреваю kvas period команда не способна это починить? надо будет уменьшить период и посмотреть)
это устаревшая команда
Как Вы понимаете, что соединение восстановлено?
Приложение Keenetic на телефон пишет что vpn отключился/подключился. Так я и узнаю с утра что ночью был разрыв
это устаревшая команда
Пардоньте, не знал. Тогда лучше убрать ее от греха подальше в следующих апдейтах :)
Добрый день, хотел уточнить, здесь под L2TP/IKEv2 подразумевается интерфейс для обхода блокировок, не ISP?
У меня точно такая же проблема в связке stable-2 kvas + adh + Мой провайдер предоставляет WAN подключение по схеме DCHP+L2TP. Так вот, при перезапуске WAN L2TP соединения не восстанавливается обход блокировок (никогда). При ручном выполнении vpn reset все начинает работать.
Написал небольшой скрипт который проверяет обход блокировок раз в минуту на домашнем пк и фиксирует время когда обход перестал работать
#!/bin/bash
while true; do
# Выполнение traceroute и сохранение вывода в переменную
output=$(traceroute -m5 telegra.ph)
# Проверка наличия подстроки IP, через который работает обход блокировок
if [[ $output == *"94.141.168.245"* ]]; then
echo "$(date "+%Y-%m-%d %H:%M:%S"): обход блокировок работает"
else
echo "$(date "+%Y-%m-%d %H:%M:%S"): !! Обход блокировок перестал работать!! Ходим по обычному маршруту.."
exit 1
fi
# Ожидание 1 минуту перед следующей итерацией
sleep 60
done
И могу сопоставить теперь логи роутера с моментом когда обход блокировок перестал работать. Примеры:
26.12 18:49 перестал работать обход блокировок.
В логах кинетика в это время происходит переподключение L2TP WAN соединения (это происходит каждый 1440 минут). [I] Dec 26 18:49:40 pppd_L2TP0: LCP terminated by peer Вот лог кинетика для ознакомления 18-49-disconnect.log
С нерабочим обходом был записан debug выполненный в 26.12 18:56:17, прикладываю debug (2).txt
По дебагу видим ошибки в логах adh, вида 023/12/25 18:50:06.065006 [error] handling tcp: handling tcp request: talking to dns upstream: all upstreams failed to respond:
Примечание1: Может показаться, как будто adh вообще не может достучаться до dns, Но акцентирую что тут не работает только обход блокировок.
Примечание2: в логах adh есть баг?, почему то он показывает разные дни (25 и 26 декабря). На самом деле все было 26 декабря
2023/12/25 18:50:09.256604 [error] 2023/12/26 18:50:07.278464 [error]
Dec 27 03:03 Все похоже с небольшими отличиями - В логах роутера нет явного перезапуска ISP L2TP. Просто мы видим что пошли ретрансмиты на IKE интерфейсе для обхода блокировок и на несколько секунд интернет "моргнул". Видимо что то перезапустилось на оборудовании провайдера. Но этого хватило чтобы обход блокировок отвалился и больше не восстанавливался..
[I] Dec 27 03:00:01 КВАС: Запущен файл /opt/etc/cron.5mins/ipset.kvas
[I] Dec 27 03:01:01 cron[29413]: (root) CMD (/opt/bin/run-parts /opt/etc/cron.hourly^I)
[I] Dec 27 03:02:56 ipsec: 10[IKE] retransmit 1 of request with message ID 0
[I] Dec 27 03:03:05 ipsec: 05[IKE] retransmit 2 of request with message ID 0
[I] Dec 27 03:03:14 ipsec: 15[IKE] retransmit 3 of request with message ID 0
[I] Dec 27 03:03:25 ipsec: 13[IKE] retransmit 4 of request with message ID 0
[I] Dec 27 03:03:37 ipsec: 07[IKE] retransmit 5 of request with message ID 0
[I] Dec 27 03:03:44 ndm: Network::Interface::Base: "L2TP0": "ping-check" changed "ipv4" layer state "running" to "pending".
[I] Dec 27 03:03:45 ndm: Network::InterfaceFlusher: flushed IPv4 L2TP0 conntrack and route cache.
[I] Dec 27 03:03:45 ndm: Network::InternetChecker: Internet access lost (status: 0x0000).
debug второго кейса debug3.log
лог кинетика второго кейса log (2).txt
полный лог adh где видны и первый и второй кейс AdGuardHome.log
У меня провайдер (ISP) по IPoE. VPN через ipsec
Доброго дня попробуйте после подобной проблемы перезапустить AHG командой kvas adguard restart, потому как по логам явно видно, что AHG просто не может связаться с серверами. Если это решит проблему, то я постараюсь автоматизировать это в Квасе.
Есть ли нужда перезагружать adh? Тест upstream серверов работает и работа dns adh не нарушена. Проблема лечится только переустановкой iptables командой vpn reset.
Похоже adh ругается только на те dns запросы которые ходят через iptables, вот они перестают работать.
Есть ли нужда перезагружать adh? Тест upstream серверов работает и работа dns adh не нарушена. Проблема лечится только переустановкой iptables командой vpn reset.
Похоже adh ругается только на те dns запросы которые ходят через iptables, вот они перестают работать.
Какие будут предложения?
выполнять vpn reset по триггерам
после восстановления интернета - событиях типа [I] Dec 27 03:03:45 ndm: Network::InternetChecker: Internet access lost (status: 0x0000). [I] Dec 26 18:49:55 ndm: Network::InternetChecker: Internet access detected. или
[I] Dec 26 18:49:40 ndm: Network::Interface::Base: "L2TP0": "ip" changed "ipv4" layer state "running" to "disabled".
[I] Dec 27 03:04:36 ndm: Network::Interface::Base: "L2TP0": "ping-check" changed "ipv4" layer state "pending" to "running".
и при переподключении VPN интерфейсов, используемых для обхода (проблема о которой говорит wildrun0
и при переподключении VPN интерфейсов, используемых для обхода (проблема о которой говорит wildrun0
Есть мысли, как отловить это состояние? В ndm это точно есть?
и при переподключении VPN интерфейсов, используемых для обхода (проблема о которой говорит wildrun0
Есть мысли, как отловить это состояние? В ndm это точно есть?
Не могу сказать, поскольку не обладаю компетенциями по возможностям ndm. Я вижу в логах что квас интенсивно постит туда информацию, вида [I] Dec 27 03:03:48 КВАС: Маркируем VPN подключения, когда программное и аппаратное ускорение ПОДКЛЮЧЕНО [I] Dec 27 03:03:49 КВАС: Маркируем VPN подключения, когда программное и аппаратное ускорение ПОДКЛЮЧЕНО [I] Dec 27 03:03:52 КВАС: Маркируем VPN подключения, когда программное и аппаратное ускорение ПОДКЛЮЧЕНО [I] Dec 27 03:04:36 КВАС: Маркируем VPN подключения, когда программное и аппаратное ускорение ПОДКЛЮЧЕНО
И это совпадает со временем обрыва L2TP WAN. И это даёт основания предполагать что какие-то похожие триггеры квас отслеживает, значит в ndm что то полезное есть?
Обновил пакет до 1.1.7 Проверьте пожалуйста ушла ли проблема?
К сожалению, проблем стало больше - не заходит на сайты из списка. Вообще. ERR_CONNECTION_REFUSED
.
Пробовал и через разные браузеры, и с очисткой кэша, вообще никак. Причем однажды дало зайти на myip2 и оно показало мой обычный IP, не впн
Пожалуйста, выкладывайте дебаг, скриншот и ваши шаги которые были сделаны и которые привели к проблеме. Поймите, "я не волшебник, я только учусь")
Да, прошу прощения, не догадался сразу ;)
Судя по логу, у Вас "каша" из правил для VPN и SSR. Попробуйте очистить правила и оставить только для конкретного соединения. Если не знаете как, то тогда полностью удалите квас и установите его заново.
Спасибо за обновление, установил, наблюдаю
Переустановил квас заново, все работает. Жду выключеиня впн и дам знать что и как.
В моём случае, автоматического восстановления обхода после перезапуска ISP VPN не произошло. После выполнения debug обход заработал. Есть идеи как отладить?
В моём случае, автоматического восстановления обхода после перезапуска ISP VPN не произошло. После выполнения debug обход заработал. Есть идеи как отладить?
Подумаю, чуть позже выложу решение.
Как вариант, можно было бы добавить отладки в лог роутера, чтобы было видно, поймал ли "квас" момент перезапуска соединения
В моём случае, автоматического восстановления обхода после перезапуска ISP VPN не произошло. После выполнения debug обход заработал. Есть идеи как отладить?
Подскажите какая версия OS на роутере у Вас установлена?
4.0.7
тогда код следующий открываем файл /opt/etc/ndm/iflayerchanged.d/test.sh
#!/bin/sh
if [ "${1}" = "hook" ] && [[ ${id} =~ 'PPTP|L2TP' ]]; then
# Отслеживаем, когда подключается к провайдеру через соединения типа PPTP или L2TP
[ "${layer}-${level}" = "ctrl-running" ] && {
logger -t "КВАС:проверка" "Соединение ${id}::${system_name} успешно подключено."
}
[ "${layer}-${level}" = "ctrl-disabled" ] && {
logger -t "КВАС:проверка" "Соединение ${id}::${system_name} успешно завершено."
}
fi
далее, даем права на выполнение
Разрыв был 3ч назад, маршрутизация не поднялась. Прикладываю дебаг, если чем сможет помочь: conn_term.txt
тогда код следующий
Добавил скрипт, и протестировал перезагрузку соединения. Вот результат
Что я вижу:
Видимо нужно учитывать в скрипте..
Восстановление соединения тоже есть Соединение L2TP0::ppp0 успешно подключено. Соединение L2TP0::ppp0 успешно завершено.
Важный момент - VPN для обхода поднимается не сразу, он восстановился только спустя 2 минуты. А значит до этого времени даже vpn reset пользы бы не принес... [I] Jan 23 21:36:51 ndm: IpSec::Interface::Ike: "IKE0": secured tunnel is ready.
Полагаю, что проблема в отсутствии функции cmd_vpn_iptable_reset Завтра выложу исправление.
он восстановился только спустя 2 минуты.
Разве? По моему лог посекундный, нет?
Посекундный, но разница 2 минуты, просто я не весь лог выложил восстановление L2TP 21:34:35 Восстановление ipsec 21:36:51 между ними - попытки подключиться к ipsec. Закину этот вопрос в поддержку кинетиков. Что то долго кинетик не может поднять ipsec к другому кинетику..
Полагаю, что проблема в отсутствии функции cmd_vpn_iptable_reseta
Не успеваю сегодня выпустить обновление, попробуйте в файле /opt/etc/ndm/iflayerchanged.d/kvas-ips-reset в одной из первых строчек заменить имя подгружаемой библиотеки: вместо main необходимо поменять на vpn.
Исправил - попробуйте продиагностировать.
Не сработало... [E] Jan 25 21:34:46 ndm: Opkg::Manager: /opt/etc/ndm/iflayerchanged.d/kvas-ips-reset: exit code 1.
Лог кинетика
Да, нет, все в норме. Ошибки исполнения функции не вижу, зато вижу: что правила сбросились:
[I] Jan 25 21:34:55 КВАС: Производим удаление правил match-set в таблице mangle, цепочке PREROUTING для VPNREDIR [I] Jan 25 21:34:55 КВАС: Производим удаление правил match-set в таблице mangle, цепочке OUTPUT для VPNREDIR [I] Jan 25 21:34:55 КВАС: Создаем таблицу маршрутизации ID#1001 для 'IKE0'.
Если нет результата, значит проблема в другом.
Если нет результата, значит проблема в другом.
Разве проблема не в том что IKEv2 поднимается на 2 минуты позже основного L2TP, и вот после поднятия IKEv2 возможно нужно делать переустановку ipset? Может быть должна сработать какая то логика которая проверит что VPN для обхода поднялся, и только после этого переустанавливать iptables? Вот полный лог ситуации log (4).txt
Также заметил, что в новой версии при выполнении vpn reset теперь дополнительно перезапускается adguard, и теперь это все значительно дольше выполняется, чем раньше. Не понятен смысл, потому последние месяцы обход восстанавливался только переустановкой iptables, без перезапуска adh. Просто теперь это занимает больше времени, без видимой пользы. Было бы хорошо иметь опцию не перезапускать adh, а только переустанавливать iptables.
Может быть должна сработать какая то логика которая проверит что VPN для обхода поднялся, и только после этого переустанавливать iptables?
Попробуйте код ниже для файла /opt/etc/ndm/iflayerchanged.d/kvas-ips-reset
# Подключаем библиотеку с функциями обработки ndm
. /opt/apps/kvas/bin/libs/ndm_d
. /opt/apps/kvas/bin/libs/ndm
tmp_file=/opt/tmp/sub_connection
if [ "${1}" = "hook" ] && [[ ${id} =~ 'PPTP|L2TP' ]]; then
# В случае отключения PPTP|L2TP соединения через основной интерфейс
# проще говоря, в случае если подключение к интернету осуществляется
# через PPTP|L2TP соединение и оно прервалось - ставим флаг в виде создания файла
is_cli_iface_global "${id}" && [ "${layer}-${level}" = "ctrl-disabled" ] && touch "${tmp_file}"
# Отслеживаем, когда подключается к провайдеру через соединения типа PPTP или L2TP
[ -f "${tmp_file}" ] && [ "${layer}-${level}" = "ctrl-running" ] && is_cli_iface_global "${id}" && {
# После отключения PPTP|L2TP (которое используется для подключения к провайдеру)
# и при наличии файла tmp_file - переустанавливаем ipset правила для восстановления
cmd_vpn_iptable_reset
logger -t "КВАС" "Соединение ${id} успешно подключено."
rm -f "${tmp_file}"
}
fi
Также заметил, что в новой версии при выполнении vpn reset теперь дополнительно перезапускается adguard...
Да, это так и есть, только перегрузка занимает пару секунд не больше. Или Вы говорите о чем-то ином?
Спасибо, протестирую!
Да, это так и есть, только перегрузка занимает пару секунд не больше. Или Вы говорите о чем-то ином?
Ну так то да, у меня это длится секунды три-четыре, но приходится ждать) Не понятно зачем только, если без перезапуска было все ок.
В r4 решение не сработало.. обход блокировок сам не возобновляется. Прикладываю iflayerchanged.log iflayerchanged.log
Судя по коду https://github.com/qzeleza/kvas/blob/847eb5bcfd79e908d11e0d397bae9ec9d19c33fe/opt/etc/ndm/iflayerchanged.d/kvas-ips-reset#L27 идет проверка
case "${layer}-${level}" in
"ctrl-disabled" )
но судя по моим логам, такого не бывает при ежедневном разрыве провайдером.. бывает layer ipv4 - level disabled layer ctrl - level connecting
так что видимо надо проверять ctrl - connecting.
Попробую потестировать локальные изменения в коде, посмотрю как сработает.
layer ipv4 - level disabled layer ctrl - level connecting
Тут логика такая, что при отключении мы ставим флаг, что отключение было на этом интерфейсе. А затем при подключении проверяем этот флаг.
В следующем релизе подправлю сработку флага ipv4 disabled
Подправил, как и писал выше. Прошу дать обратную связь.
Тикет закрываем?
Начиная с версии 3 или 4 крайнего релиза, я перестал наблюдать проблемы после обрывов соединения. По моей части проблем больше нет - как там у badigit не знаю
На последнюю версию еще не обновлялся, протестирую.
На r7 проверить не смог - появились другие более критичные ошибки. например Таблица ipset - пуста. Откатился на r5. Откат - работает хорошо)
Тикет закрываем?
Пока что проблема есть.. Запишу сегодня свежую отладку
Проблема актуальна.. Вот свежий лог - в течении 10 минут когда было переподключение https://gist.github.com/badigit/c670f3c02e6c6f3e4b1425290e86cfa1#file-log-L133
Ключевые точки в хронологии.
[I] Feb 23 00:02:44 ipsec: 05[IKE] retransmit 4 of request with message ID 148
это момент когда реально отвалился интернет (на домашнем пк скрипт заметил что обход не работает)
[I] Feb 23 00:02:46 dropbear[4528]: Child connection from 10.9.8.92:64068
с домашнего пк пробуем сделать iptables_reset (не успешно и явно раньше времени сработал скрипт)
[I] Feb 23 00:03:34 pppd_L2TP0: No response to 3 echo-requests
pppd_L2TP0 заметил что интернет отвалился
[I] Feb 23 00:03:35 ndm: Network::Interface::Base: "L2TP0": "ppp" changed "link" layer state "running" to "connecting".
сработал iflayerchanged.d
...потом в течении минуты бурная деятельность кинетика по восстановлению подключений..
..
[I] Feb 23 00:04:53 TESTS: Проверка: iflayerchanged L2TP0 (ppp0) layer ctrl has level running
восстановление L2TP
[I] Feb 23 00:05:37 TESTS: Проверка: iflayerchanged IKE0 (nikecli0) layer link has level running
восстановление IKE VPN
Наверное надо разбить вопросы на части..
[E] Feb 23 00:05:44 КВАС: ОШИБКА::\033[1;31m[ip4_firewall_vpn_mark] Во время маркировки трафика для VPN соединений возникли ошибки.\033[m
[E] Feb 23 00:05:44 КВАС: ОШИБКА::\033[1;31m[ip4_firewall_exclude_locals] Возникла ошибка при установке правил iptables\033[m
[E] Feb 23 00:05:35 КВАС: ОШИБКА::\033[1;31mНе удалось определить IP шлюза для соединения nikecli0\033[m
2. Сам кинетик довольно часто дергает iflayerchanged и вносит неразбериху.
3. Между пропажей интернета и восстановлением l2TP + IKE прошло примерно 3 минуты..
4. Однозначно понятно что в качестве решения нужно сделать iptables_reset после того как восстановится основное соединение и VPN IKE0
Не раньше точно. Попробую поэкспериментировать в этом направлении.
На самом деле, видимо у большинства такой проблемы с провайдером нет как у меня, поэтому для вас наверное это не очень приоритетный тикет.. Но был бы благодарен за советы и какие-нибудь решения в этом направлении.
Например не очень понятна причина ошибок которые выдает квас в п.1.
изменения внесены в 1.1.8 r1 прошу дать обратную связь.
Я так полагаю обратной связи не будет. т.к. тему открывал я, закрываю, у меня проблем больше не наблюдается
Описание проблемы. После обрыва VPN соединения, пропадает маршрутизация ранее добавленных сайтов в квасе.
Информация о системе с которой происходит тестирование пакета на роутере (пожалуйста, заполните следующую информацию):
Информация о роутере (пожалуйста, заполните следующую информацию):