0xkee

Поправлено, обновите, пожалуйста, geo-split + webui рекомендуются новые версии всех пакетов ps по выхлопу диагностики, кстати, всё работает идеально...

Доброго дня! Возможно не установлен пакет `coreutils-touch` (BusyBox `touch` не поддерживает `-d @epoch`. Если `coreutils-touch` не установлен (новая зависимость), `update-domains.sh` падает с ошибкой.) Добавлен в версию 0.12.1+ Если `coreutils-touch` не помогает, пожалуйста, пришлите вывод диагностики

Доброго времени суток! Возникла техническая сложность разделения запуска/останова и включения/выключения сервисов, штатный механизм Entware enable/disable фактически отсутствует (есть переменная ENABLED=yes|no внутри init-скрипта + файл rc.func), поэтому были внесены небольшие архитектурные изменения: - теперь разделены start/stop и enable/disable, start/stop оставлены для запуска при рестарте роутера как штатный механизм entware - для permanent user disable используйте новые disable/enable (вебка сама знает, что использовать) - при этом используйте пути типа: /opt/keenetic-entware-extras/<пакет>/init.d/S##пакет enable/disable - при этом в папке /opt/etc/init.d/ теперь находятся симлинки на реальные скрипты из пакетов, например /opt/keenetic-entware-extras/scripts # ls -l /opt/etc/init.d/ -rwxr-xr-x 1 root root 232 May 23 2025 S10cron -rwxr-xr-x 1 root root 194 Mar 16 12:22 S38smartdns lrwxrwxrwx 1 root root 74 Jun 1 22:43 S39smartdns-redirect -> /opt/keenetic-entware-extras/smartdns-redirect/init.d/S39smartdns-redirect -rwxr-xr-x 1 root root 749 Feb 13 16:54 S51dropbear -rw-r--r-- 1 root root 518 Mar 16 12:22 S80nginx lrwxrwxrwx 1 root root 56 Jun 1 22:43 S80nginx-webui -> /opt/keenetic-entware-extras/webui/init.d/S80nginx-webui lrwxrwxrwx 1 root root 58 Jun 1 22:43 S99geo-split -> /opt/keenetic-entware-extras/geo-split/init.d/S99geo-split -rw-r--r-- 1 root root 2842 May 24 2025 rc.func -rwxr-xr-x 1 root root 950 May 24 2025 rc.unslung /opt/keenetic-entware-extras/scripts # при disable этот симлинк удаляется, при enable - добавляется - cron, hooks, watchdog остаются, но проверяют наличие симлинка (как выше), и если его нет, сервис считается выключенным пользователем перманентно (до дальнейшего ручного включения пользователем), и в таком случае - скрипты тут же завершаются (ничего не делают) - при обновлении пакетов сервисы автоматически переходят в режим enabled и запускаются всегда (соглашение - если они не нужны, то их и не обновляют...) *** иишка *** 7. Нюанс для cryoPanda по поводу лога cron Даже при disable, cron entry остаётся в /opt/etc/crontab — поэтому строки: cron[xxx] (root) CMD (/opt/keenetic-entware-extras/smartdns-redirect/scripts/watchdog.sh) будут появляться в syslog всегда (это cron логирует сам факт запуска job). Но watchdog тут же делает exit 0 на первой проверке is_service_enabled и ничего не трогает. Если пользователю мешает даже видеть строки в syslog, можно добавить удаление cron-записи в disable и восстановление в enable

Готово.

Да, это ошибка. Делаю патч... **Проблема:** `smartdns-redirect/scripts/watchdog.sh` (cron */5) видит «iptables rules missing» после ручного `stop` → восстанавливает правила + рестартует SmartDNS через ≤5 мин. geo-split `refresh` безвреден (заполняет таблицы, но не ставит ip rules). NDM hooks тоже могут восстановить.

У Вас похоже, ситуация следующая: - выключен доступ к веб снаружи - прошивка оставляет только доступ из LAN - прошивка не считает 127.0.0.1 роутера ланом (что в целом правильно) Если это так, попробуйте, пожалуйста: **Решение — изменить upstream на LAN IP:** Сначала проверяем что stock httpd доступен с LAN IP: ```sh curl -s -o /dev/null -w '%{http_code}' http://192.168.10.1:80/ ``` Если ответ 200 (или 401 — значит просит авторизацию, это нормально), исправляем upstream: ```sh # Открыть конфиг nginx-webui vi /opt/keenetic-entware-extras/webui/config/nginx.conf ``` Найти строку: ```nginx upstream keenetic_ui { server 127.0.0.1:80; keepalive 4; } ``` Заменить на: ```nginx upstream keenetic_ui { server 192.168.10.1:80; keepalive 4; } ``` Перезапустить: ```sh /opt/etc/init.d/S80nginx-webui restart ``` **Проверка:** ```sh # Должно вернуть 200 или 302 (перенаправление на login) curl -s -o /dev/null -w '%{http_code}' http://192.168.10.1:8080/auth ``` После этого зайти в браузере на `http://192.168.10.1:8080/` — должна появиться стандартная форма логина Keenetic. Учётные данные те же, что для штатного WebUI. > **Примечание:** `listen.conf` у вас правильный (`listen 192.168.10.1:8080;`), менять его не нужно. Проблема была только в upstream (куда проксируется auth). *** Если так, то ситуация повторяемая, нужен патч...

Первый отзыв, что работает 👍 1. бывает... я выше не сообразил, что белая коробочка с wifi антеннами, sim слотом и навязывающеюся роутером при включении в обычный eth является обычным хостом и ей надо задавать gw... 🤦‍♂️ 2. это ошибка (артефакт) в доке, поправлю ### 1. Порядок остановки и запуска сервисов **Почти.** Порядок остановки верный, но порядок запуска нужно скорректировать — geo-split при старте резолвит домены через SmartDNS (вызывает `update-domains.sh` → `dig @localhost -p 6053`). Поэтому SmartDNS должен быть запущен **до** geo-split. **Остановка** (от зависимых к базовым): ```sh # === ОСТАНОВКА === /opt/etc/init.d/S99geo-split stop # 1) снять ip rules и маршруты /opt/etc/init.d/S39smartdns-redirect stop # 2) снять iptables DNAT (DNS) /opt/etc/init.d/S38smartdns stop # 3) остановить SmartDNS ``` **Запуск** (по S-номерам — каждый сервис зависит от предыдущего): ```sh # === ЗАПУСК === /opt/etc/init.d/S38smartdns start # 1) поднять DNS-резолвер /opt/etc/init.d/S39smartdns-redirect start # 2) перехватить LAN DNS → SmartDNS /opt/etc/init.d/S99geo-split start # 3) загрузить подсети + резолв доменов через SmartDNS ``` > **Почему S99 последний при запуске:** `geo-split start` вызывает `update-domains.sh`, который резолвит домены из списка через SmartDNS (порт 6053). Если SmartDNS не запущен — домены отрезолвятся через системный ndnproxy, и CDN-адреса могут быть «не те». **Альтернатива — быстрое отключение только маршрутизации (без DNS):** Если нужно только отключить split-routing, но DNS оставить через SmartDNS: ```sh /opt/etc/init.d/S99geo-split stop # трафик пойдёт обычным путём /opt/etc/init.d/S99geo-split start # вернуть обратно ``` + в webui есть переключалки + в webui есть кнопки refresh или /opt/etc/init.d/S99geo-split update... их можно использовать по необходимости ### 2. Обязателен ли SmartDNS? Совместимость с интернет-фильтром **SmartDNS + smartdns-redirect НЕ обязательны для работы geo-split.** Они решают разные задачи: | Компонент | Роль | Обязателен? | |-----------|------|-------------| | **geo-split** | Маршрутизация по IP-подсетям (через nwg0) | ✅ Основной | | **smartdns-conf-ru-split** | Конфиг SmartDNS: резолвит RU-домены через РФ DNS | Рекомендуется | | **smartdns-redirect** | iptables DNAT: DNS клиентов → SmartDNS (порт 6053) | Рекомендуется | **Зачем SmartDNS нужен:** Без него geo-split работает **только по IP-подсетям** (CIDR из geo-списков). Многие CDN-домены (vk.com, mail.ru, yandex.ru) отдают разные IP в зависимости от DNS-сервера. Если DNS-резолвер за рубежом — вернёт зарубежный CDN-адрес, и он может не попасть в RU-подсети. SmartDNS решает эту проблему: для RU-доменов запрашивает DNS через РФ-сервер → получает корректный российский IP → geo-split маршрутизирует его правильно. **Насчёт встроенного интернет-фильтра Keenetic:** - Интернет-фильтр (профили защиты, AdGuard DNS, Яндекс.DNS) — это **DNS-фильтрация контента** (блокировка порно, рекламы и т.д.) - SmartDNS — это **split-resolving** (разные DNS-серверы для разных доменов) - Это **разные функции**, они не взаимозаменяемы **Рекомендация:** | Сценарий | Рекомендация | |----------|-------------| | Нужен только split-routing по подсетям | geo-split достаточно | | Нужен надёжный доступ к RU-сайтам через CDN | geo-split + SmartDNS + redirect | | Используете интернет-фильтр Keenetic для детей | Можно оставить, но `PRESERVE_FILTER_PROFILES` пока не реализован — дети получат нефильтрованный DNS через SmartDNS | **Если нужен и фильтр, и split-routing:** Пока `PRESERVE_FILTER_PROFILES` не реализован, есть обходной путь — в `smartdns-redirect` config указать `INTERFACES="br0"` — это перенаправит DNS **только с основного LAN**. Если детские устройства на отдельном VLAN (br1/Guest), их DNS не тронется. + надо уточнить, что технически это ответ верный для случая направления какой-то гео зоны в туннель ### 3. WebUI: ошибка авторизации на порту 8080 WebUI на порту 8080 — это **reverse proxy** к штатному Keenetic WebUI (порт 80). Авторизация работает через стандартный механизм Keenetic (`x-ndw2-interactive` challenge-response). Авторизация работает напрямую на порту 8080 — при первом заходе появится стандартная форма логина Keenetic. Учётные данные — те же, что для штатного WebUI (обычно `admin` + ваш пароль). > **Подсказка:** Если сначала зайти на штатный WebUI (`http://<ip>:80`) и залогиниться там, то на порту 8080 авторизацию спрашивать не будет — сессионная cookie (RFC 6265) шарится между портами одного IP. **Возможные причины ошибки «неверные данные»:** 1. **Несоответствие realm** — пароль в Keenetic хешируется вместе с realm (имя устройства). Если роутер был переименован после создания пароля, может быть рассогласование. Попробуйте сбросить пароль admin через штатный UI. 2. **listen.conf не сгенерирован** — nginx не может корректно проксировать auth. 3. **Штатный httpd на порту 80 недоступен с 127.0.0.1** — наш nginx проксирует `/auth` на `127.0.0.1:80`. **Диагностика:** ```sh # На роутере: проверить что nginx-webui запущен /opt/etc/init.d/S80nginx-webui status # Проверить что штатный UI доступен локально curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:80/ # Проверить listen.conf (должен содержать LAN IP) cat /opt/keenetic-entware-extras/webui/config/listen.conf # Полная диагностика /opt/keenetic-entware-extras/webui/scripts/status.sh ``` **Если `listen.conf` пустой или содержит неверный IP:** ```sh # Пересоздать (подставьте IP роутера в LAN) echo 'listen 192.168.1.1:8080;' > /opt/keenetic-entware-extras/webui/config/listen.conf /opt/etc/init.d/S80nginx-webui restart ```

Доброго времени суток! Да, этот штатный (второй) режим, должно работать... Проверьте пожалуйста: 1. **Проверьте имя интерфейса:** на Keenetic это `nwg0`, не `ngw0` 2. **Конфиг должен быть в `config.conf`**, не в `defaults.conf`: ```sh vi /opt/keenetic-entware-extras/geo-split/config/config.conf ``` (!) defaults.conf переписывается при апдейтах vi - любой редактор, mcedit для любителей midc (mc) Содержимое: ```sh ROUTE_OUT="nwg0" ``` или даже без редактора echo "ROUTE_OUT=\"nwg0\"" >> /opt/keenetic-entware-extras/geo-split/config/config.conf 3. **Перезапустить:** `/opt/etc/init.d/S99geo-split restart` 4. **Проверить:** интерфейс `nwg0` должен быть поднят (VPN-подключение активно) ```sh ip link show nwg0 ``` должно быть UP Если не поможет, пожалуйста, запустите диагностический скрипт для сбора инфы на роутере и пришлите вывод: /opt/keenetic-entware-extras/scripts/bug-report.sh что-то можно заменить на *** по желанию

да, похоже ошибка для случая с uplink via eth... (во-первых, не проверялось, это только для "прямого", не PPP-like соединения... обычно это маленькие провы, большие поднимают PPP или аналог ради авторизации, маленькие ставят фильтры по MAC; во-вторых, не очевидная вещь - пока модемные интерфейсы работают фактически как ptp и просто форвардят всё непонятное дальше, классический eth на стороне клиента (linux ярдо кинетика) без явного gw считает что "mail.ru" прямо в eth сегменте, отправляет его прову, а тот, проверив arp, логично дропает, т.к. mail.ru у него в сегменте (с пользователями) точно нет, и таким образом надо инструктировать ядро кинетика не считать таргеты локальными явно указывая gw, а ptp-like ifaces можно отправлять без gw как и прежде... есть длинный ответ от ии-шки, если кому интересно могу выложить) Из-за этого ядро Linux считает, что адреса 2.56.24.X находятся прямо на вашем L2-сегменте, и пытается отправить ARP-запрос за IP-адрес назначения. На Ethernet-провайдерах (в отличие от LTE-модемов) это не работает — провайдер не отвечает на ARP за чужие IP. ## Верификация Чтобы убедиться, что причина именно в этом, сделайте простой тест: **Шаг 1.** На роутере по SSH: ```sh ip route replace 77.88.8.8/32 via 176.65.44.1 dev eth2.4 table 1001 ``` **Шаг 2.** На ПК (Windows) откройте `cmd` и выполните: ``` ping 77.88.8.8 ``` Если пинг прошёл — причина подтверждена на 100%. Маршрутам не хватает gateway. (77.88.8.8 уже есть в table 1001 как часть подсети, но без `via` — мы заменяем на host-route с gateway.) ## Временный workaround (до выхода исправления) ```sh # Определяем gateway: GW=$(ip route show dev eth2.4 | grep "^default" | grep -o 'via [^ ]*' | awk '{print $2}') [ -z "$GW" ] && GW=$(ip route show default dev eth2.4 table all | grep -o 'via [^ ]*' | head -1 | awk '{print $2}') echo "Gateway: $GW" # Перезаливаем таблицу с gateway: ip route flush table 1001 while read -r cidr; do ip route add "$cidr" via "$GW" dev eth2.4 table 1001 2>/dev/null done < /opt/var/cache/geo-split/subnets.txt echo "Done. Routes with gateway:" ip route show table 1001 | head -3 ``` После этого RU-сайты должны заработать. Эффект сохранится до перезагрузки или перезапуска geo-split. (это не batch load - может долго грузить таблицу (пару-тройку минут)) ## Статус исправления Это баг в geo-split — маршруты должны добавляться с `via <gateway>` для Ethernet-провайдеров. Исправление уже в работе, выйдет в следующей версии. (если подтвердится, хотя бы одним ip route replace 77.88.8.8/32 via 176.65.44.1 dev eth2.4 table 1001 + ping OK)

Привет! Спасибо за подробный вывод. ## Что происходит geo-split определил **eth2.4** как ISP-интерфейс и маршрутизирует через него RU-трафик. Но этот интерфейс отвечает "узел недоступен" — значит либо это **не тот интерфейс** (не интернет, а, например, IPTV), либо ISP-подключение ещё не успело подняться (uptime всего 49 секунд). YouTube работает потому что идёт через VPN (не попадает в RU-подсети). ## Диагностика Подключись по SSH и выполни **одной командой** (скопировать целиком): echo "=== INTERFACES ===" && ip -br link show && \ echo "=== ADDRESSES ===" && ip -br addr show && \ echo "=== DEFAULT MAIN ===" && ip route show default && \ echo "=== DEFAULT ALL ===" && ip route show table all 2>/dev/null | grep "^default" && \ echo "=== TABLE 1001 ===" && ip route show table 1001 2>/dev/null | head -3 && \ echo "=== PING eth2.4 ===" && ping -c2 -W3 -I eth2.4 77.88.8.8 2>&1 && \ echo "=== NDM ===" && ndmc -c "show interface" 2>/dev/null | grep -E "interface-name:|description:|connected:" | head -30 Скинь полный вывод — станет ясно, в чём дело. ## Быстрый workaround (если не хочешь ждать) Если в выводе `ndmc` видно, что у Ethernet-интернета другой interface-name (например `eth2.2` или `eth3`) — можно сразу указать его явно: cat > /opt/keenetic-entware-extras/geo-split/config/config.conf << 'EOF' ROUTE_OUT="eth2.2" EOF /opt/etc/init.d/S99geo-split restart Замени `eth2.2` на реальное имя ISP-интерфейса из вывода `ndmc`. ## Либо: просто подожди 2-3 минуты Uptime 49 секунд — ISP-подключение могло ещё не полностью подняться. Попробуй повторить `tracert mail.ru` через пару минут после загрузки. *** Скорее всего, неправильно авто определился интерфейс к провайдеру. eth2.4 - это один из ethernet на роутере, такое подключение - прямое, без ppp (когда вводятся логин/пароль для подключения), это маловероятно, если провайдер более-менее большой, у них у всех ppp over eth (т.е. должен определяться типа ppp0). То, что isp ещё не поднялся - это маловероятно. Если так - самое простое, поправить в конфиге ROUTE_OUT на правильный интерфейс (от провайдера) и рестартануть geo-split. Если это поможет - доработаю логику авто определения выходного интерфейса.

Разобрался с совместной работой geo-split и awg-manager. Если коротко — всё должно работать вместе без дополнительных настроек. Единственное, что не нужно — это DNS от awg-manager, но он и так не требуется при использовании geo-split. Подробности — в приложениях. В процессе нашлась причина, по которой geo-split мог не работать совместно с awg-manager. Суть проблемы: некоторые российские провайдеры блокируют доступ к сайтам с гео-списками. Чтобы обойти такую блокировку, geo-split умеет пробовать загрузку через разные сетевые интерфейсы. Раньше список этих интерфейсов был зашит вручную — туда входили только «родные» подключения роутера, потому что сторонние пакеты не предполагались. Из-за этого интерфейсы, созданные awg-manager, просто не учитывались — скорее всего именно это и приводило к проблемам. Исправил: теперь geo-split автоматически перебирает все активные интерфейсы, включая те, что создаёт awg-manager. Обновите geo-split до последней версии. ps сорри за ии-фильтр текста awg-manager-compatibility-post.md compatibility-analysis.md

Красивое, изучу возможность совместимости. Видел, тут (пока) принципиально иное решение: мухи отдельно, котлеты отдельно. И в этом есть масса плюсов - что нетфликс, что банки думают то, что им и положено думать. (Но в процессе эксплуатации возникла проблема, что топология (что ли) сетей меняется чаще, чем дефолтные обновления гео (7 дней) и доменов (1 час). Возможно, некий гибрид on-demand+full-split наиболее оптимален в будущем) У меня, к сожалению, нет железки с 4.х. Пока исследовал по прошивке, должно работать. Если есть какая-то железка с 4.х, куда можете дать ssh - могу всё проверить и добавить поддержку за час-два... как вариант. Либо фидбеки. Уточню на всякий случай, у Вас уже должен быть Кинетик/Неткрез + entware + a tunnel (типо vpn/proxy или что-то такое), оно всё должно быть настроено и работать. А эти пакеты добавляют [global] geo splitting на 2х уровнях (иначе никак): ip routing (по крону загружаются/обновляются официальные таблицы + резолвятся домены из определённого списка, это фактически на будущее) + dns geo resolving (это делается с помощью конифга smartdns, которые такое умеет), поэтому несколько пакетов. Плюс добавлено куча настроек в конфиги, большая часть из которых в 99% сетапов менять не потребуется, но дают бОльшую гибкость и позволяют сплиттить из любого интефейса в любой любую гео зону (в перспективе несколько одновременно, пока не реализовано). Плюс обходятся стоковые dns службы, т.к. они не очень. Вот как-то так...

Пока нет отзывов, что работает. Вопрос в сетапах/конфигурации сетей, всего не предусмотреть, если и не работает, то скорее всего по этому. Глючит. Нет, планируется.

Это же одно и тоже? Подробный ответ на все остальные вопросы (совместно с нейросеткой, резюме в конце, не сочтите за слоп) В 2х словах, скорее всего "core" заработает на 4.х, webui нет, но можно допилить после 2.х очень старая (13 лет) и планов её поддерживать нет (и не факт, что это можно сделать простыми способами)

При проблемах: 1. Опишите проблему словами — что делали, что ожидали, что получили (чем подробнее, тем лучше) 2. Запустите скрипт диагностики и приложите вывод (под спойлер): /opt/keenetic-entware-extras/scripts/bug-report.sh Скрипт собирает версии, статус всех сервисов, проверки DNS и маршрутов, хвосты логов. В выводе нет паролей, ключей или внешних IP — безопасно постить на форуме. > Доступен начиная с `keenetic-entware-extras` ≥ 0.9.5.