vasek00

Клиентов при данном тесте больше не было. Вопрос по клиенту более подробно про него и дрова на нем.

Нужен комментарий по статье https://help.keenetic.com/hc/ru/articles/360017046280-Выбор-класса-обслуживания-для-устройств-домашней-сети Вопрос на 409 при отключенной "Классификация трафика и IntelliQoS" или даже включенной "Классификация трафика и IntelliQoS" ~ # cat /proc/sys/net/ipv4/tcp_ecn 2 0 – disable ECN and neither initiate nor accept it 1 – enable ECN when requested by incoming connections, and also request ECN on outgoing connection attempts 2 – (default) enable ECN when requested by incoming connections, but do not request ECN on outgoing connections ~ # cat /proc/sys/net/core/default_qdisc fq_codel ~ # Вопрос по статье или я чуток не так понял И чисто для информации на 409 версии на схеме при запущенным локальном сервисе который потребляет ресурсы проца для своей работы (получение пакетиков данных). Тест три раза. [iperf3 -c ... -t2400 -P 30 -R]Клиент -- LAN --- KN1011[iperf3 -s] На KN1011 запущен ЛОКАЛЬНЫЙ сервис iperf3 Буфер размером до 30МB, есть drop пакетов, как итог из потока 1Gb получили 400МБ при загрузке проца Другой ЛОКАЛЬНЫЙ сервис (область ядра) - TSMB на запись HDD с этого же клиента ПК файла 2,3GB. В данном случае речь не о скорости записи на HDD (который 5400 об) и при той же итоговой загрузке проца.

Есть два варианта 1. ТП 2. Все делаете на свой страх и риск. По п.2 если открыть два данных конфига, чуток настроив второй на чистом роутере то нечего сложно там нет, так оба роутера на 1Гбит и оба на 2.4/5 -> имена интерфесов одинаковы, зарег клиенты вообще без проблем, wifi также и т.д.

Да, в ручную можно, если только заглядывали в него хх кол - во раз, так как нужно чуток иметь представление что за блок и за что он отвечает. Со временем понимание приходит если частенько туда заглядывать в кон файл.

Не обращайте внимание на это. Proxy loop detected: 192.168.1.1 <-> 192.168.1.1, request dropped. DNS server 192.168.1.1 inactivated.

Удалить ранее прописанный в table просто поставить del в место aďd. Я не в курсе что и как и где вы создавали. По пробуйте дошлифовать так как вам надо, может пересмотрев все настройки заново. В описанном методе она таблица создается и контролируется ПО роутера, если хотите создавать сами и контролировать ее то тут на форуме куча примеров достаточно в поиске поискать по "ip rule add"

В настройках есть поле разрешенные подсети. По конфигу они например выглядят так allow-ips 10.16.130.6 255.255.255.255 - клиент allow-ips 192.168.130.0 255.255.255.0 - сеть роутера allow-ips 0.0.0.0 0.0.0.0 - все Возьмите в базе знаний любую статью про Wireguard настройку и про значение данных полей - allow-ips Об одной единственной команде которую нужна для всего этого ее в WEB cli не прописать. Об этом было сказано в моем самом первом посту В настоящее время одну единственную команду приходиться вводить через Entware - "ip rule add" Выход из этого самый простой у вас KN1910 на нем легко ставится Entware во внутреннюю память пример с KN1910 ниже После чего нужную выполнить ОДНУ ЕДИНСТВЕННУЮ ip rule add from IP_Клиента table profile_номер_table где IP_Клиента - это берется из настроек Wireguard сервера для данного клиента, а profile_номер_teble это номер таблицы для вашего профиля (как его найти написано было ранее, без всяких команд)

Хорошо можно проще. 1. Wireguard клиент уже настроен и работает. 2. Wireguard сервер для удаленных клиентов поднят (нужен белый IP если нет то например SSTP) настроен и работает. 3. Создать профиль и поместить в него канал п.1 4. Прописать одну команду для клиента из п.2 ip rule add from IP table ПРОФИЛЯ

Где в нескольких местах уже описывал вариант как удаленного клиента завернуть в VPN канал для выхода в интернет. Опишу еще раз может что-то вам подойдет, вариант на базе профилей так как не хорошо когда все в основном профиле, легко запутаться. 1. На роутере есть поднят WARP (у вас WireGuard до сервера в Германии), можно в место WARP заменить на WireGuard до сервера в Нидерландах роли не играет. 2. Создан профиль WARP и в нем только один канал WG активен (ремарка для данного профиля маркировка пакетов будет только тогда и тогда когда появиться живой клиент в данном профиле, т.е. не помещен в него через WEB а когда сработает arp на нем и он будет добавлен в таблицу arp, но нам маркировка не нужна а нужна таблица для данного профиля а она будет создана table) 3. Так как белый адрес на роутер то поднят сервер WG (хотя так же описывал когда и серый и поднят SSTP сервер и подключается клиент) роли не играет. 4. На клиенте смартофоне поднят WG или для SSTP Max (привязка user к IP) 5. После того как все будет настроено, клиент может спокойно подключиться то на что стоит обратить внимание : - по умолчанию для данного клиента будет маршрутизация через основной прояфиль (т.е. default маршрут для данного профиля согласно приоритетам и галкам на нужных интерфейсах на странице WEB) - для созданного профиля будет созданна своя таблица маршрутизации и в которой будет свой deafult на нужный интерфейс, в данном случае это п.2 6. Теперь осталось завернуть данного клиента смартфон п.4 в данную таблицу маршрутизации. - по умолчанию в ПО роутера первый профиль получает номер table 42, следующий 43, следующий 44 и т.д. - в данном случае WARP профиль имеет table 42 - поместить смартфон в нужную table 42 Клиент удаленно подключился по WG к роутеру 10.16.130.6 dev nwg3 scope link Для него пока существует профиль по умолчанию основной ~ # ip ro default dev ppp0 scope link ...10.16.130.0/24 dev nwg3 proto kernel scope link src 10.16.130.101 10.16.130.6 dev nwg3 scope link ... т.е. выход для него через провайдера ppp0, легко проверяеться speedtest - адрес будет стоять от интерфеса ppp0 Сменим ему выход на наш профиль WARP в котором ~ # ip ro show table 42 default dev nwg0 scope link ... выполнив команду ip rule add from 10.16.130.6 table 42 выход для него теперь через профиль WARP, легко проверяеться speedtest - адрес будет стоять от интерфеса ppp0 При отключение данного клиента и заново подключение все так же работает. В настоящее время одну единственную команду приходиться вводить через Entware - "ip rule add"

Речь про чтение конф буфера в ПК для последующего ввода данных на роутер

При наличие установленного на ПК - Shadowsocks-4.4.1.0 - после его запуска -> Сервера -> Импорт адреса из буфера обмена. Потом Серверы -> Редактировать серверы. Потом выбираете нужный и все параметры у вас на экране.

Если сайты известны то заверните это AGH+ipset (там же образец по ссылке которую давали), если неизвестны то после первого же запроса станут известны что не доступны и ручками в ipset (опять же как использовать список есть выше по ссылке) прописать. Дам еще некое решение у вас WG от Proton если вы его подняли и поместили в профиль для него то и table для него так же есть (таблица маршрутизации) так что маркированный трафик можете заводить сразу в нее.

На ПО 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 нет.

Пожелания в виду того что на текущий момент в прошивки реализовано использование профилей (маркировка пакета и таблица маршрутизации) то хотелось бы например, клиент 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