vasek00

На ПО 407 в WEB настройках профиля для двух каналов : Все настройки в WEB роутера 1. Настроены каналы по приоритету In-2 (eth2.9) и ниже PPPoE (ppp0) в итоге имеем маршруты для данного профиля ~ # ip ro show table 43 default nexthop via 10.10.10.1 dev eth2.9 weight 254 nexthop dev ppp0 weight 254 2. В настройках профиля меняем местами по приоритету PPPoE (ppp0) и ниже In-2 (eth2.9) в итоге имеем маршруты для данного профиля ~ # ip ro show table 43 default nexthop dev ppp0 weight 254 nexthop via 10.10.10.1 dev eth2.9 weight 254 default nexthop via 10.10.10.1 dev eth2.9 weight 254 nexthop dev ppp0 weight 254 3. В настройках профиля меняем местами по приоритету In-2 (eth2.9) и ниже PPPoE (ppp0) в итоге имеем маршруты для данного профиля ~ # ip ro show table 43 default nexthop dev ppp0 weight 254 nexthop via 10.10.10.1 dev eth2.9 weight 254 default nexthop via 10.10.10.1 dev eth2.9 weight 254 nexthop dev ppp0 weight 254 4. В настройках профиля меняем местами по приоритету PPPoE (ppp0) и ниже In-2 (eth2.9) в итоге имеем маршруты для данного профиля ~ # ip ro show table 43 default nexthop dev ppp0 weight 254 nexthop via 10.10.10.1 dev eth2.9 weight 254 default nexthop via 10.10.10.1 dev eth2.9 weight 254 nexthop dev ppp0 weight 254 Последующая смена каналов не чего не меняет ~ # ip ro show table 43 default nexthop dev ppp0 weight 254 nexthop via 10.10.10.1 dev eth2.9 weight 254 default nexthop via 10.10.10.1 dev eth2.9 weight 254 nexthop dev ppp0 weight 254 5. Убираю на канале PPPoE галку, т.е. остается активным только один канал In-2, в итоге ~ # ip ro show table 43 default via 10.10.10.1 dev eth2.9 default nexthop dev ppp0 weight 254 nexthop via 10.10.10.1 dev eth2.9 weight 254 default nexthop via 10.10.10.1 dev eth2.9 weight 254 nexthop dev ppp0 weight 254 6. Убираю на канале In-2 галку и ставлю на PPPoE канале, остается активным только один канал PPPoE-2, в итоге ~ # ip ro show table 43 default dev ppp0 default nexthop dev ppp0 weight 254 nexthop via 10.10.10.1 dev eth2.9 weight 254 default nexthop via 10.10.10.1 dev eth2.9 weight 254 nexthop dev ppp0 weight 254 7. Делаю активными оба : PPPoE и In-2 в итоге ~ # ip ro show table 43 default nexthop dev ppp0 weight 254 nexthop via 10.10.10.1 dev eth2.9 weight 254 default nexthop via 10.10.10.1 dev eth2.9 weight 254 nexthop dev ppp0 weight 254 Сброс роутера и таблица маршрутизации правильная, согласно настроек ~ # ip ro show table 43 default nexthop dev ppp0 weight 254 nexthop via 10.10.10.1 dev eth2.9 weight 254 Ни как не мог понять в чем фишка multipath на профиле, вчера решил посмотреть и в итоге наблюдал тройную запись "default nexthop" Возможно конечно и не влияет кол-во записей "default nexthop" всегда используется первая "default" но встроенный торрент не хочет работать в такой таблице set net.ipv4.fib_multipath_hash_policy 1 interface PPPoE0 description RT role inet ... ip global 65431 pppoe service RT connect via ISP up interface GigabitEthernet0/Vlan9 description Inet-2 ... ip global 65380 up ip policy Policy1 description In-2 permit global GigabitEthernet0/Vlan9 permit global PPPoE0 multipath torrent rpc-port 8090 peer-port 51413 directory D-1:/Torrnet policy Policy1 Убирание галок на каналах и даже галки на "многопутевой передачи" не приводит к изменению таблицы ~ # ip ro show table 43 default nexthop dev ppp0 weight 254 nexthop via 10.10.10.1 dev eth2.9 weight 254 default nexthop via 10.10.10.1 dev eth2.9 weight 254 nexthop dev ppp0 weight 254 Привести в чувство можно еще так Удаление default -> в WEB галки убраны на интерфесах Удаляем одну запись default ~ # ip route del default table 43 ~ # ip ro show table 43 default nexthop via 10.10.10.1 dev eth2.9 weight 254 nexthop dev ppp0 weight 254 Удаляем вторую запись default ~ # ip route del default table 43 ~ # ip ro show table 43 10.10.10.0/24 dev eth2.9 scope link ... Галки ставим на интерфейсах и в итоге все ОК ~ # ip ro show table 43 default nexthop via 10.10.10.1 dev eth2.9 weight 254 nexthop dev ppp0 weight 254 10.10.10.0/24 dev eth2.9 scope link

Возможно как то это и можно, так как прошивка же создает table при создание профилей. Но читая cli и единственную команду "ip route" она не позволяет это сделать

1. Поднять Entware (+ ip route) для того чтоб прописать маршрут на нужную table 2. Клиент sstp получает IP от сервера sstp 3. Так как есть профиль Создано подключение wireguard к личному серверу. Устройства, которые подключены к keenetic 1711 через профиль прописан доступ в интернет через wireguard - все работает. то есть таблица маршрцтизации для данного профиля 4. нужно для данного клиента sstp маршрут в данную таблицу маршрутизации данного профиля *************** Клиент подключился к SSTP серверу в итоге он получил например 172.16.13.1 (согласно настроек VPN сервера SSTP) Проверяем выход данного клиента через speedtest и смотрим какой IP показывает, он должен быть от РТ. На роутере стоит Entware делаем маршрутизацию данного клиента на профиль Wireguard, в моем случае это table 42 (в ПО Keenetic нумерация table идет с 42, далее 43, далее 44 от кол-ва профилей) Профиль Wireguard ~ # ip route show table 42 default dev nwg0 scope link Основной профиль через РТ ~ # ip ro default dev ppp0 scope link ~ # ip rule add from 172.16.13.1 table 42 В итоге получаем Данную инструкцию проверял ранее 3.9.х и проверил сейчас 4.0.х на мобильном клиенте - все работает

А не поделитесь решением данного вопроса и в чем "земля и небо".

Бесплатно до 300 тыс. запросов. Кто еще - не в курсе, может в интернете что то и найдете. Вы сильно углубились в данном вопросе и придаете какое то крутое значение. Оставьте tls.

В догонку так же работает и nextdns DNS-over-TLS/QUIC --- c.....d.dns.nextdns.io quic://c.....d.dns.nextdns.io

Если вписать сервера самого Adguard после регистрации на adguard-dns.io DNS-over-HTTPS https://8...9.d.adguard-dns.com/dns-query DNS-over-TLS tls://8...9.d.adguard-dns.com DNS-over-QUIC quic://8...9.d.adguard-dns.com то на странице настройки "Upstream DNS-серверы" прописать например один quic://8....9.d.adguard-dns.com то все работает. На бесплатной регистрации 300тыс. запросов.

При чем тут easy mesh, вы хоть как это назовите Denis-mesh принципа работы это не меняет. Да используйте что хотите, хоть без 802.11 k и v, достаточно иметь одно имя на разных ТД остальное это плюшки улучшения для роуминга клиента. Миграция клиента с одной ТД на другую ТД с разрывом сессии то же считается роумингом клиента.

Понял, сайт то доступен только вот вопрос по статьям и конкретно роуминг. 400 Bad Request Request Header Or Cookie Too Large nginx/1.22.0 Тогда поправлю если это у меня.

Не большая ремарка, 802.11krv это конечно хорошо но есть фишка в IAPP https://www.manualsdir.ru/manuals/235308/planet-technology-wrt414.html?page=57 или или или https://union-z.ru/articles/novyy-td-i-tekuschiy-td-chto-znachit-wifi.html в реале если это пользователя устроит при работе - для серф. интернета и не будет "зависона" всей wifi сети или отвала клиентов и т.д., то почему бы нет. Но в каждом случае все индивидуально.

Появилась (или была ранее на 4.x) старая болячка "флуд на WG" по описанному п.3 т.е. - основной канал PPPoE поднят и он основной - WG канал в резерве отключаю основной канал PPPoE на и WG появляется "флуд" под wifi клиентом на WEB роутера не войти, под LAN клиентом без проблем. После восстановления каналов интернета - клиент wifi основного bridge0 сегмента без проблем подключился, почему основного потому что есть доп. сегмент bridge1 с wifi 2.4 и своими клиентами, но про них речь уже ниже. ****** Так же заметил проблему после такого эксперимента с октлючением PPPoE канала и флудом на WG. Есть доп.сегмент wifi 2.4 для умного дома и чуток клиентов. Так после описанной выше "болячки" когда все поднялось PPPoE/WG и клиент wifi основного сегмента подключился без проблем, то клиенты доп.сегмента bridge1 умного дома отказались подключаться (в этом сегменте только wifi 2.4 клиенты). Пришлось передернуть Wifi данного сегмента (вкл/выкл.) тогда один клиент подключился сразу же (марка всех одинакова), а другие курили. Фев 4 08:36:07 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:5f) had deauthenticated by AP (reason: PTK 4-way handshake timeout). Фев 4 08:36:12 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:99) had associated successfully. Фев 4 08:36:12 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:5f) had associated successfully. Фев 4 08:36:18 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:99) pairwise key handshaking timeout (msg 1 of 4-way). Фев 4 08:36:18 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:99) had deauthenticated by AP (reason: PTK 4-way handshake timeout). Фев 4 08:36:18 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:5f) pairwise key handshaking timeout (msg 1 of 4-way). Фев 4 08:36:18 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:5f) had deauthenticated by AP (reason: PTK 4-way handshake timeout). через некоторое время еще одному удалось подключиться Фев 4 08:38:06 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(......:5f) set key done in WPA2/WPA2PSK. Фев 4 08:38:06 ndhcps DHCPDISCOVER received from .....:5f. Фев 4 08:38:06 ndhcps making OFFER of 192.168.150.4 to .....:5f. Фев 4 08:38:06 ndhcps DHCPREQUEST received (STATE_SELECTING) for 192.168.150.4 from ....:5f. Фев 4 08:38:06 ndm Netfilter::Util::Conntrack: flushed 52 IPv4 connections. Фев 4 08:38:06 ndhcps sending ACK of 192.168.150.4 to ......:5f. Фев 4 08:38:07 ndhcps DHCPREQUEST received (STATE_SELECTING) for 192.168.150.4 from ....:5f. Фев 4 08:38:08 ndhcps sending ACK of 192.168.150.4 to .....:5f. Фев 4 08:38:08 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(.......:99) had associated successfully. с момента первой записи о проблеме на клиентах Подъем каналов - PPPoE и WG ранее [I] Feb 4 08:30:06 kernel: br1: port 2(ra1) entered disabled state [I] Feb 4 08:30:06 ndm: Network::Interface::Base: "WifiMaster0/AccessPoint1": "base" changed "conf" layer state "running" to "disabled". [I] Feb 4 08:30:06 ndm: Network::Interface::Base: "WifiMaster0/AccessPoint1": interface is down. [I] Feb 4 08:30:06 ndm: Core::System::StartupConfig: saving (http/rci). [I] Feb 4 08:30:06 kernel: br1: port 2(ra1) entered disabled state [I] Feb 4 08:30:06 ndm: Network::Interface::Base: "Bridge1": "l2-base" changed "link" layer state "running" to "pending". [I] Feb 4 08:30:06 ndm: Hotspot::Discovery::Explorer: "Bridge1": Interface Bridge1 IPv4 neighbour explorer stopped. [I] Feb 4 08:30:10 kernel: IPv6: ADDRCONF(NETDEV_UP): ra1: link is not ready [I] Feb 4 08:30:10 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): ra1: link becomes ready [I] Feb 4 08:30:10 kernel: br1: port 2(ra1) entered blocking state [I] Feb 4 08:30:10 ndm: Network::Interface::Base: "WifiMaster0/AccessPoint1": "base" changed "conf" layer state "disabled" to "running". [I] Feb 4 08:30:10 kernel: br1: port 2(ra1) entered listening state [I] Feb 4 08:30:10 ndm: Network::Interface::Base: "WifiMaster0/AccessPoint1": interface is up. [I] Feb 4 08:30:10 ndm: Core::System::StartupConfig: saving (http/rci). [I] Feb 4 08:30:10 kernel: br1: port 2(ra1) entered blocking state [I] Feb 4 08:30:10 kernel: br1: port 2(ra1) entered listening state [I] Feb 4 08:30:10 ndm: Core::System::StartupConfig: configuration saved. [I] Feb 4 08:30:10 ndm: Network::Interface::Base: "Bridge1": "l2-base" changed "link" layer state "pending" to "running". [I] Feb 4 08:30:10 ndm: Hotspot::Discovery::Explorer: "Bridge1": Interface Bridge1 IPv4 neighbour explorer started. [I] Feb 4 08:30:11 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(.....:99) had associated successfully. .... После ожидания все подключились Фев 4 08:41:02 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(......:99) set key done in WPA2/WPA2PSK. Фев 4 08:41:02 ndhcps DHCPDISCOVER received from .....:99. Фев 4 08:41:02 ndhcps making OFFER of 192.168.150.2 to ......:99. Фев 4 08:41:02 ndhcps DHCPDISCOVER received from ......:99. Фев 4 08:41:02 ndhcps making OFFER of 192.168.150.2 to ......:99. Фев 4 08:41:02 ndhcps DHCPREQUEST received (STATE_SELECTING) for 192.168.150.2 from ......:99. Фев 4 08:41:02 ndm Netfilter::Util::Conntrack: flushed 60 IPv4 connections. Фев 4 08:41:03 ndhcps sending ACK of 192.168.150.2 to .....:99. Время на раздумье около 10минут при таком поведение хватило. В итоге делаю вывод что оценка интернет каналов (состояние) приводит ????? на других интерфейсов не связанных с данными каналами - например bridge1 доп.сегмент в котором только 2.4 wifi. Все как бы ОК но в WEB роутера "шторка" с надписью "Потеря соединения с интернет центром". Придется перезапустить его. Настройки доп.сегмента простые

Проверю на новой версии. Update. Сейчас все ОК, перезапуск TSMB не нашел. Проверил во всех своих ракурсах : 1. выключение/включение интерфейсов WG которые подняты на провайдере PPPoE 2. при shed на Wifi по расписанию все ОК так же, хотя ранее было передергивание 3. выключение основного канала PPPoE и ожидание WG (3 мин) - тут то же все нормально Вопросов по TSMB нет.

А в чем проблема Единственная фишка - он этот стат.маршрут пропишется везде, т.е. во всех таблицах маршрутизации. Таблица маршрутизации привязана к профилю.

Любая политика - это маршрутизация через нужный интерфейс. Клиент находится в созданной политики например WARP в моем случае это таблица маршрутизации 42, вторая политика это для Proton и его таблица 44 (в ней данного клиента нет, интерфейс nwg4) но канал активен. Нужно направить wildberries.ru например на Proton для данного клиента который в политике WARP. Идем в WEB на маршрутизацию и прописываем нужные два маршрута : ip route 185.138.0.0 255.255.0.0 Wireguard4 auto reject !wbl-2 ip route 185.62.200.0 255.255.254.0 Wireguard4 auto reject !wbl-1 в итоге имеем show ip route table 44 { "route": [ { "destination": "0.0.0.0/0", "gateway": "0.0.0.0", "interface": "Wireguard4", "metric": 0, "flags": "U", "rejecting": false, "proto": "boot", "floating": false, "static": false }, ... { "destination": "185.62.200.0/23", "gateway": "0.0.0.0", "interface": "Wireguard4", "metric": 0, "flags": "U", "rejecting": false, "proto": "boot", "floating": false, "static": false }, { "destination": "185.138.0.0/16", "gateway": "0.0.0.0", "interface": "Wireguard4", "metric": 0, "flags": "U", "rejecting": false, "proto": "boot", "floating": false, "static": false }, ... "prompt": "(config)" } show ip route table 42 { "route": [ { ... { "destination": "185.62.200.0/23", "gateway": "0.0.0.0", "interface": "Wireguard4", "metric": 0, "flags": "U", "rejecting": false, "proto": "boot", "floating": false, "static": false }, { "destination": "185.138.0.0/16", "gateway": "0.0.0.0", "interface": "Wireguard4", "metric": 0, "flags": "U", "rejecting": false, "proto": "boot", "floating": false, "static": false }, ... "prompt": "(config)" }

Пожелания в виду того что на текущий момент в прошивки реализовано использование профилей (маркировка пакета и таблица маршрутизации) то хотелось бы например, клиент Windows : 1. в котором настроена DSCP Marking Override (например 62) для определенного приложения отправить в нужный профиль 2. остальные приложения данного клиента как обычно (или в основном профиле или в любом другом) На данном форуме есть много примеров по созданию маркировки пакетов и отправки этой "маркировки" в нужную таблицу маршрутизации. Так как в ПО этот механизм уже есть, то возможно ли через WEB роутера на странице "Приоритеты подключений" - "Политики доступа в интернет" продумать настройку создать профиль в котором просто вводится параметр прописанный в п.1 например 62 по ее отлову "DSCP Marking Override" + нужный интерфейс куда направить (это уже есть в WEB). Есть маленькая фишка все правила для маркировки создаются только при наличии клиента в профиле, тут же в профиле не клиент а код DSCP отлова ну и так же IP данного клиента лок.сети то же есть. Или то же самое но в уже готовый какой либо профиль. Для Windows использовал инструкцию https://www.atraining.ru/qos-windows-nt/ но таких много в интернете, да и пару раз полазить все запоминается. Это интересно при наличие например двух каналов или поднятых VPN каналах и в текущих реалиях отправить приложение клиента не по стандартному маршруту. Александр Рыжов уже разбирал пример в своей статье "Роутинг для отдельных приложений Windows" https://keenetic-gi.ga/2020/11/25/winapp-routing.html

Вопрос зачем вам Dnscrypt proxy ?????? Ставите Entware потом dnscrypt-proxy, освобождаете 53 порт от прошивочного. Делаете нужную вам настройку через его конф (*.toml) файл и запускаете его скрипт на запуск.

Все написано выше, если не понятно то поиск по интернету, что искать опять же написано выше. У dnsmasq как и у многих сервисов есть конф.файл.

Активация vpn правильней сказать это "подъем/up" сетевого интерфеса wireguard/openvpn/pptp/l2tp и т.д. Есть клиент в данном профиле или нет не имеет значения. Помещая клиента в данный профиль в нем есть маршрут по умолчанию через данный сетевой интерфейс wireguard/openvpn/pptp/l2tp и т.д. В другом профиле через другой интерфейс. Проблему с подъемом данного интерфейса можно увидеть в логе. Проблема не возможности клиентом в данном профиле открыть страницу в интернете если нет ошибок в логе связана с настройками dns/фильтрами.

О какой активации идет речь, вы про что, я даже не писал про это. В данном профиле уже все давно активировано, вы просто перемещаете пользователя из одного профиля в другой.

Есть клиент и два профиля в которых WG - постоянно один, а иногда другой другой канал WG, при перемещение пользователя по профилям без проблем все меняется (уточню тут не сразу, сек. до 3-5 тут и вопросов не должно возникнуть по этим 3-5сек.). Как работало всю жизнь на draft c 3.9 так и работает на draft c 4.0.х. С Wireguard от Proton так же вопросов нет. То что используется без проблем про то и заладили.

По 4.0.5 хотя думаю и ранее это было Янв 29 10:33:53 ndm Network::Interface::Base: "Wireguard3": interface is down. Янв 29 10:33:53 ndm Core::System::StartupConfig: saving (http/rci). Янв 29 10:33:53 kernel wireguard: Wireguard3: peer "Z8c.....bTY=" (4) (ххх.ххх.160.ххх:39045) destroyed Янв 29 10:33:53 kernel wireguard: Wireguard3: peer "y09....JMCA=" (5) (10.16.130.18:ххххх) destroyed Янв 29 10:33:55 kernel TSMB module stopped. Янв 29 10:33:56 ndm Core::System::StartupConfig: configuration saved. Янв 29 10:33:57 kernel TSMB module version 3020.9.24.13 started from process 9004! Янв 29 10:34:01 ndm Cifs::ServerTsmb: service started.

Весь конф файл в одном файле - AdGuardHome.yaml, если в нем есть ссылки на доп. файлы ipset_file: /opt/........conf Далее используемые фильтры попадают в каталог где размещен AdGuardHome -> data/filters В моем случае все просто, так как все размещено в каталоге /opt/home/AdGuardHome там же и конф файл то достаточно сохранить каталог /opt/home/AdGuardHome + скрипт запуска /opt/etc/init.d. Тот который лежит в Entware после установки имеет следующие каталоги : - /opt/etc/AdGuardHome (в нем конф файл) - /opt/bin (сам файл, AdGuardHome) - /opt/etc/init.d (сам файл, S99adguardhome)

Разговор и пожелания этого ведется давно https://translated.turbopages.org/proxy_u/en-ru.ru.03a125f4-63d0bb45-57bb5eb9-74722d776562/https/github.com/AdguardTeam/AdGuardHome/issues/951

Я не в курсе где и что у вас стоит (только то что Между устройствами около 10 метров.). Могу только гадать, но и это проблематично так как это 2.4 судя по вашему скрину выше, который 2.4 обычно забит соседями или не забит соседями. У меня дома Меш система из двух устройств кто тогда контроллер и т.д. Так же можно было посмотреть и в лог Спидстера что там. Сижу на кухне в непосредственной близости от Спидстера, кручу ленту в ВК или Ютубе. это пока рано, для начала как у вас установлено и настроено. Вы пробовали от него отойти на х метров, данным клиентом. Можно для пробы не отходить, а просто убавить мощность 75% это -1dB, 50% это -3dB. Из ходя из того что написано выше плюс то что ниже на скрине - роутер контроллер (точка 2) + ТД (точка 1). Клиент смартфон рядом с ТД как и положено подключился к ней так как его (1) он слышит лучше RSSI -33 чем контроллер (2) RSSI -50. Всеми правдами и не правдами ему клиенту не захочется со соскакивать с ТД (1) или отключаться от нее, если только помеха не пробежит (в виде работы соседского роутера на соседнем канале, так как сосед рядом с ТД, но дальше от роутера и помеху он будет создавать разную на них). Если это проблематично то попробуйте обратиться в ТП, но и туда чем больше информации дадите тем больше шанса на решение вашего вопроса.