0xkee

Да, там сейчас немного криво - кеш не сбрасывается... вебка имеет REST API и там встроен кеш что бы проц не мучать всякими проверками (при открытых вкладках только) Вебку перезапустите чтобы сбросить кеш.

Добрый! Не совсем. Правите /opt/keenetic-entware-extras/smartdns-geo-conf/config/dns-providers-custom.conf под себя (сохраняется при апдейтах) Как в примере: # --- Plain UDP (simplest) --- # OTHER_mydns_LABEL="My DNS" # OTHER_mydns_PROTO="udp" # OTHER_mydns_IP1="1.2.3.4" # OTHER_mydns_IP2="5.6.7.8" # # --- DoT (DNS over TLS, port 853) --- # OTHER_privatedot_LABEL="Private DoT" # OTHER_privatedot_PROTO="dot" # OTHER_privatedot_IP1="10.0.0.1" # OTHER_privatedot_IP2="" # OTHER_privatedot_TLS_HOST="dns.example.com" # # --- DoH (DNS over HTTPS) --- # OTHER_privatedoh_LABEL="Private DoH" # OTHER_privatedoh_PROTO="doh" # OTHER_privatedoh_DOH_URL="https://dns.example.com/dns-query" # OTHER_privatedoh_IP1="10.0.0.1" # OTHER_privatedoh_IP2="" # OTHER_privatedoh_TLS_HOST="dns.example.com" # # --- Zone provider (for regional DNS group) --- # ZONE_myzone_LABEL="My Zone DNS" # ZONE_myzone_PROTO="udp" # ZONE_myzone_IP1="192.168.1.1" # ZONE_myzone_IP2="" # ZONE_myzone_UDP_FALLBACK="no" Один свой днс - несколько строк. Сначала ZONE_ или OTHER_, потом идет Ваше название (ник днс) и потом заполняете все переменные, они в зависимости от типа днс разные, например : OTHER_myowndns_LABEL="My Own DNS" OTHER_myowndns_PROTO="udp" OTHER_myowndns_IP1="1.2.3.4" OTHER_myowndns_IP2="5.6.7.8" Не закоментированы должны быть, конечно. Перезапустить не smartdns, а вебку (не очень, но вебка кеширует данные чтобы экономить цпу, там есть какой-то таймаут тол и 15 минут толи час - тогда появятся новые данные сами... они там разные в разных местах. надо будет добавить сброс кеша при рестарте...) А вот эти : в вебке выберите, она их установит сама.

Старый smartdns-conf-ru-split нужно удалить (он был переименован), остальные безопасно ставить поверх.

попробуйте новуй версию 0.13.2, там улучшено + дайте 30-60 секунд устаканиться всем проверкам: в какой-то момент проверок стало много и на проце пред. поколения (mipsel) они стали грузить проц на 100% (особенно при плохой связи с провом), а на новых (arm) не критично, неделю-две назад было добавлено кеширование результатов проверок, какие то не чаще чем в раз в 15 сек, какие то 30, какие то 60, не волатильные списки типа интерфейсов вообще 1 час. Это позволило почти полностью снизить нагрузку на проц. Сама нагрузка возникает только при открытых страницах, которые отображают эти статусы. Это некий компромисс между live статусами и загрузкой проца. Что даёт некоторую тормознутось. Сток работает примерно так же. Если же это происходит постоянно - это какая то ошибка, дайте знать пожалуйста. + так же если плохой канал связи с провайдером могут выскакивать случайные ошибки проверок днс и вообще сервисов. В таком случае это нормально и не повод для беспокойства. update Всё выше перечисленное верно, но после глубокого анализа была обнаружена архитектурная ошибка - не учитывалось переключение между 2+ провайдерами. Спасибо за обратную связь. Ошибка исправлена, используйте новые версии из первого поста: keenetic-entware-extras_0.16.4_all.ipk, geo-split_0.14.0_all.ipk

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

какая-то ошибка - перезалиты вообще работают, могут быть какие-то варианты с выбором dsn пришлите, пожалуйста, bug-report сюда/в личку

Добрый день! Он кеширует, замеряет какой сервер быстрее и использует в основном его, единственно, иишка говорила, что есть нарекания у пользователей на некоторые баги, пока не сталкивались. Но он быстрее раза в 3. В новой версии можно будет, начиная с smartdns-geo-conf - 0.10.0. Сегодня-завтра будет. update Поддержка альтернативных DNS - сделано, см. user-manual.ru.md

Добрый! Не пишет... что то настройками, пришлёте bug-report?

На здоровье, ... избыточное в дальний ящик не убирайте, по всей логике (прости господи, OSI или как оно реально работает теперь), оно будет работать как надо только вместе с dns splitting ) что собственно делает первый пакет, а второй просто позволяет не менять настройки dsn кинетика (он их игнорирует), это просто удобно

Всё верно. Если никакие настройки не менялись, кроме выбора geo зоны - должно работать как в первом случае, us -> gre, all others -> stock keenetic routing (default/policies) Та же конфигурация?

Результаты отличные — всё работает: 1. ✅ Туннель ngre0 активен: RX 1.6 ГБ, TX 80 МБ — огромный объём данных 2. ✅ Маршрут 77.88.8.8 → dev ngre0 table 1001 — routing geo-split корректен 3. ℹ️ MASQUERADE в iptables пуст — это нормально для Keenetic. Прошивка делает NAT для VPN через внутренний механизм (ndmmark + _NDM_MASQ), который не виден в обычном `iptables -L` Мы проверили этот сценарий (ROUTE_OUT=ngre0) на нашем стенде — работает корректно. Вопросы: • Проблема ещё воспроизводится прямо сейчас? • Если да — какой конкретный сайт не открывается? Выполните для него: dig <домен> @127.0.0.1 -p 6053 +short ip route get <IP> from 172.16.132.100 iif br0 Это покажет, получает ли DNS адрес из российской зоны. Если сайт на иностранном CDN (Cloudflare и т.п.) — его IP может не попасть в RU-подсети, и трафик пойдёт мимо туннеля. А как проверяете, с роутера или с клиента роутера? С роутера эта штука не работает (сознательное решение), работает только для клиентов сетей указанных в Route In Реально поднял gre tunnel, проверил, всё работает... update Улучшен bug-report, теперь проверятся роутинг с точки зрения клиента, например:

awg0 поднят... а трафик через него идёт (без geo-split)? если идёт - то как это настроено: default на всё в awg0, или это это Connection Policies от кинетика? выглядит как проблема настройки самого туннеля. нужно больше информации... по интерфейсу/cli - как Вы это видите? update Улучшен bug-report, теперь проверятся роутинг с точки зрения клиента, например:

Приветствую. Запустите, пожалуйста, заново и проверьте: Судя по вашему bug-report, все компоненты geo-split работают корректно: маршруты загружены (177 domain + 9274 subnet), ip rules на месте, DNS-redirect активен. Проблема скорее всего в самом GRE-туннеле ngre0. Пожалуйста, выполните на роутере: 1) ip -s link show ngre0 → Покажет счётчики TX/RX. Если TX packets > 0, но RX = 0 — пакеты уходят, но ответа нет (remote endpoint проблема). Если TX = 0 — пакеты вообще не отправляются. 2) ip route get 77.88.8.8 from 172.16.132.100 iif br0 → Должно показать "dev ngre0 table 1001". Если показывает "via 176.195.64.1 dev eth3" — маршрут не матчится. 3) iptables -t nat -L POSTROUTING -v -n | grep ngre → Проверяем, есть ли MASQUERADE для трафика через ngre0. Без NAT на выходе из туннеля ответные пакеты не вернутся. 4) Проверьте в веб-интерфейсе Keenetic: активно ли VPN-подключение, которое создаёт ngre0? (Другие маршруты → статус соединения) Результаты этих команд помогут точно определить причину.

По состоянию на сейчас, с последними версиями: 1. Google+Cloudflare — пока не конфигурируется через UI/config. ECS не передаётся — SmartDNS не отправляет подсеть клиента upstream. Google видит только IP роутера (или VPN). Если нужна приватность от Google — включите OTHER_DNS_INTERFACES → DNS пойдёт через VPN. Поддержка выбора альтернативных DNS (Quad9, Mullvad) в планах. (Так же сам по себе ECS не так уж плох, он позволяет работать CDN и, например, отдавать Netflix с ближайшего сервера, то есть быстрее...) 2. Исключить хост — можно вручную: добавить nameserver /host.ru/default в конец zone-конфига. Более удобный механизм (файл исключений) пока не реализован — добавим. Сделаны новые версии пакетов, добавлены настройки стран/союзов, сделан web ui на 95%, из ui можно настраивать основные опции, перезапускать сервисы. Прикрепляю в этом посте новые версии, потом обновлю 1й пост. Сначала нужно удалить smartdns-conf-ru-split - он переименован в smartdns-geo-conf, иначе новый не установиться (возможно, сохраните свои настройки, если есть). По заданным вопросам можете прислать в личку use cases? Возможно, там есть что осмыслить дополнительно. Например - "исключить хост" это весьма общее, например, если речь идёт про какой-то сайт, ya.ru, то это не 1 хост, а дюжина-две хостов (которые запрашиваются самим браузером при открытии сайта, счётчики, баннеры, экосистемная авторизация, разделяемые ресурсы и так далее), список которых в общем случае может меняться от запроса к запросу и далее в течении недели глобально. И в таком случае "исключить хост" не даст полного эффекта. То есть смотря на каком уровне исключать - если ip routing, то да, если это уже касается контента, то там всё сложнее...

Поправлено, обновите, пожалуйста, 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