vasek00

https://help.keenetic.com/hc/ru/articles/360001434079-Настройка-правил-межсетевого-экрана-из-командного-интерфейса

Подправил под 4.3. Вариант когда клиент в своем профиле. Получим первое упоминание для блока его правил по MAC и прибавим +1 iptables -t mangle -L --line-numbers | awk '/E8:_MAC_CLIENTA_:74/ {print $1; exit}' получил номер первого упоминнаия -> +1 = 58 iptables -t mangle -I _NDM_HOTSPOT_PRERT 58 -m mac --mac-source E8:_MAC_CLIENTA_:74 -m dscp --dscp 0x3f -j MARK --set-xmark 0xffffaab/0xffffffff В итоге, нужное правило dcp = 63 или 0x3f (профиль для него 0хffffaab), чтоб оно было после основного правила для профиля (0хffffaaa). Данный раздел ниже это весь блок для данного клиента, что у него и куда. 57 MARK all -- anywhere anywhere MAC E8:_MAC_CLIENTA_:74 MARK set 0xffffaaa 58 MARK all -- anywhere anywhere MAC E8:_MAC_CLIENTA_:74 DSCP match 0x3f MARK set 0xffffaab 59 CONNMARK all -- anywhere anywhere MAC E8:_MAC_CLIENTA_:74 CONNMARK save 60 RETURN all -- anywhere anywhere MAC E8:_MAC_CLIENTA_:74 Фишка так и осталась, но уже только при передаче по основному профилю и в момент приема на другом проф. Это уже на LAN клиенте.

Проверил на 4.3 (чуток изменения) и вот такую картину получил #!/bin/sh [ "$table" != "mangle" ] && exit 0 if [ -z "$(iptables-save | grep 'dscp')" ]; then iptables -t mangle -I _NDM_HOTSPOT_PRERT -m mac --mac-source e0:клиент_ПК:e0 -j RETURN iptables -t mangle -I _NDM_HOTSPOT_PRERT -m mac --mac-source e0:клиент_ПК:e0 -j CONNMARK --save-mark --nfmask 0xffffffff --ctmask 0xffffffff iptables -t mangle -I _NDM_HOTSPOT_PRERT -m mac --mac-source e0:клиент_ПК:e0 -m dscp --dscp 0x3f -j MARK --set-xmark 0xffffaab/0xffffffff iptables -t mangle -I _NDM_HOTSPOT_PRERT -m mac --mac-source e0:клиент_ПК:e0 -j MARK --set-xmark 0xffffaaa/0xffffffff fi exit 0 Для dscp 0х3f сервиса клиента выбран канал Inet-2, сервис для проверки torrent на клиенте ПК по wifi и проф. aab. Все остальное с данного клиента в aaa (на данном профиле поднят только WG который на канале РТ). Итог все работает, но есть маленькая фишка, падение скорости на канале Inet-2 во время работы по другому.

На пороге 2025год и на сегодня в прошивки все есть для реализации - "Создание политики обслуживания клиента" или можно назвать по другому. В моем случае есть два канала хотелось бы завернуть приложение клиента на Windows через канал отличный от default канала клиента. На Windows клиенте ставим метку на нужный сервис/приложение, а роутер по этой метке отправляет пакетики в нужный нам канал Ранее делал так [ "$table" != "mangle" ] && exit 0 if [ -z "$(iptables-save | grep 'dscp')" ]; then iptables -t mangle -I _NDM_HOTSPOT_PRERT -i br0 -s 192.168.1.2/32 -j RETURN iptables -t mangle -I _NDM_HOTSPOT_PRERT -i br0 -s 192.168.1.2/32 -j CONNMARK --save-mark iptables -t mangle -I _NDM_HOTSPOT_PRERT -i br0 -s 192.168.1.2/32 -j MARK --set-mark 0xffffaaa iptables -t mangle -I _NDM_HOTSPOT_PRERT -i br0 -s 192.168.1.2/32 -m dscp --dscp 63 -j MARK --set-mark 0xffffaab fi т.е. политика1 "--set-mark 0xffffaaa" (будет основная) и политика2 для приложения на клиенте "--set-mark 0xffffaab" (будет вторая). Именно в такой последовательности, так как правила iptables будут сначала для "0xffffaab", а потом для "0xffffaaa". Сам клиент должен находится в основном профиле. Сейчас в 4.3 опять хотелось бы вернуться к этой "плюшке", но нужен USB порт и Entware. Не плохо бы иметь возможность реализации хотя бы через cli то было бы хорошо.

Опытным путем выяснил, что IP "зависает" от другого соединения. При наличие нескольких каналов/интерфейсов то это перестройка маршрута, т.е. смена одного default (выход в интернет) на другой. На пальцах пров.1 (основной/интерфейс ppp0) и пров2 (резервный/интерфейс eth2.9). Вариант 1 когда на основном то имеем default на ppp0 (пров1) ~ # ip ro default dev ppp0 scope link 10.IP_пров2.0/24 dev eth2.9 proto kernel scope link src IP_от_Интерфейс_eth2.9 xxx.xxx.xxx.1 dev ppp0 proto kernel scope link src IP_от_Интерфейс_ppp0 ... Вариант 2 когда на другом провайдере то имеем смену default (тут просто смена в основной политики каналов/местами, второй выше первого) ~ # ip ro default via 10.IP_пров2.1 dev eth2.9 10.IP_пров2.0/24 dev eth2.9 proto kernel scope link src IP_от_Интерфейс_eth2.9 xxx.xxx.xxx.1 dev ppp0 proto kernel scope link src IP_от_Интерфейс_ppp0 ... Вариант 3 - настройка выбора интерфейса через параметр "ip global _ПРИОРИТЕТ_", т.е. чем цифра выше -> имеем приоритет на данном интерфейсе (в WEB чем выше позиция, ниже пров1 приоритетней) interface PPPoE0 ip global 65387 ***************** 65387 interface GigabitEthernet0/Vlan9 ip global 65382 ***************** 65382 Вы описываете свои действия так когда подключаюсь к WISP (основное соединение отключаю) когда отключаю WISP и включаю Ethernet после удаления WISP-соединения При таком действие - это тоже самое -> смена default с одного на другой интерфейс, вопрос только "баг" это или нет. Сделал подключение через телефон (WISP) в итоге ~ # ip ro default via 192.168.226.12 dev apcli0 ********************************************* def через телефон 10.IP_пров2.0/24 dev eth2.9 proto kernel scope link src IP_от_Интерфейс_eth2.9 xxx.xxx.xxx.1 dev ppp0 proto kernel scope link src IP_от_Интерфейс_ppp0 .... 192.168.226.0/24 dev apcli0 proto kernel scope link src 192.168.226.161 ********* телефон/сеть "host": "ndss.keenetic.ru", "wan-ip": "192.168.226.161", "sent-wan-ip": "192.168.226.161", Выключаю WISP (WEB роутера) и как итог переход на пров1 ~ # ip ro default dev ppp0 scope link 10.IP_пров2.0/24 dev eth2.9 proto kernel scope link src IP_от_Интерфейс_eth2.9 xxx.xxx.xxx.1 dev ppp0 proto kernel scope link src IP_от_Интерфейс_ppp0 ... "host": "ndss.keenetic.ru", "wan-ip": "IP_от_Интерфейс_ppp0", "sent-wan-ip": "IP_от_Интерфейс_ppp0", Все сработало как и надо. Маленькая ремарка - на ppp0 произошла смена IP это говорит о переподключение для данного канала, но во время второго теста проблем на возникло (переподключения не было). interface WifiMaster0/WifiStation0 description Aa73 dyndns nobind security-level public authentication wpa-psk ns3 *** encryption enable encryption wpa2 ip address dhcp ip dhcp client dns-routes ip global 65515 ********************************** приоритет по умолчанию встал такой ip name-servers ssid Aa73 standby no enable standby timeout 600 up От себя сейчас в 4.3 (draft канала) по настройкам данного подключения куча настроек

Роутер в основном режиме но подключен как ТД по LAN к другому/основному На основном Покажите ваши маршруты "show ip route", потом в конфиг файле посмотреть разделы "interface" (согласно вывода пред.команды) и поле найти "ip global _ПРИОРИТЕТ_" (где приоритет это набор цифр и чем он выше по отношению к другому интерфейсу он и главный, ip global - выход в интернет, если их много то смотрим приоритет). Почему может отправляться внутренний ip? Без понимания что и как у вас подключается к интернету тут можно только гадать, почему не вернулся на канал провайдера после пропажи или что-то переключили/настроили, может надо было перегрузить роутер и т.д.

Про его я понял Устройство действительно EU - через тех поддержку специально переводил в регион EU, чтобы пользоваться одним приложением Keenetic, т.к. имею устройство еще в Европе. В посте ответ был другому пользователю.

Не отклоняйтесь от темы данного поста. Ровно 2 недели назад впервые возникла проблема. Перестал работать KeenDNS и пропала связь с сервером обновлений. При этом интернет работает и на подключенных устройствах, и на Keenetic-е. Сервера NDSS пингуются. В тот раз решилось подключением через WISP к телефону. Сервера Keenetic увидел, я обновил его до последней версии и в течение 2 недель всё работало. Сегодня снова та же проблема. Подключаю через WISP к телефону - KeenDNS работает, обновления видно. Переключаю обратно на Ethernet - всё пропадает.

Не проясните как запросто ?

Почитать наверное где в базе знаний есть, а так я же показ конф файл ТД interface Bridge0 rename Home description HomeLan inherit GigabitEthernet0/Vlan1 include AccessPoint include AccessPoint_5G .... ip address 192.168.1.3 255.255.255.0 ip address dhcp ip dhcp client fallback static ip dhcp client dns-routes ip dhcp client name-servers interface Bridge0 - ip address 192.168.1.3 255.255.255.0 если проблема при "ip address dhcp/ip dhcp client fallback static"

Вопрос, на 43B2 перестал подключаться WG на второго провайдера при перезагрузки роутера. Инет1-провайдер РТ и WG0 - все ОК Инет2-провайдер провод и WG1 - проблемка, требуется передергивания соединения. На некоторых весриях ПО все нормально, например на 43B1 теперь на 43B2 опять проблема. Передергивание и итог WG2 на втором провайдере Ранее на 43B1 При переводе WG1 на РТ канал, проблем не возникает (основной РТ и default на него, Inet-2 резерв).

192.168.1.3 данный адрес используется при проблеме на DHCP сервере или его отсутствие, т.е. точка не получила IP и был назначен по умолчанию. interface Bridge0 rename Home description HomeLan inherit GigabitEthernet0/Vlan1 include AccessPoint include AccessPoint_5G .... ip address 192.168.1.3 255.255.255.0 ip address dhcp ip dhcp client fallback static ip dhcp client dns-routes ip dhcp client name-servers Смотрим лог Возможно лог прояснит ситуацию по данному вопросу.

Можно и штатными -> тогда ручками менять def мвршрут в WEB или как описывали на форуме через vlan. О каких дебрях идет речь ????? На втором роутере def на основной ~ # ip ro default via 192.168.1.100 dev br0 proto static После подключения модема к нему, def на модем ~ # ip ro default via 192.168.8.1 dev cdc_br0 Смена def c модема на основной ~ # ip ro del default ~ # ip route add default via 192.168.1.100 dev br0 ~ # ip ro default via 192.168.1.100 dev br0 Смена обратно на модем ~ # ip ro del default ~ # ip route add default via 192.168.8.1 dev cdc_br0 ~ # ip ro default via 192.168.8.1 dev cdc_br0 Проконтролировать модемный интерфейс ~ # ifconfig | awk '/cdc_br0/ {print $1}' cdc_br0 ~ # ~ # ip route | awk '/default/ {print $3}' 192.168.8.1 ~ # ~ # ping -c2 -I cdc_br0 8.8.8.8 | awk '/packets received/ {print 4}' 4 ~ # а что сломает, потому что заменяет собой функционал Т.е. если вы прописываете свой стат маршрут заворачивая его на нужный интерфейс то вы что-то ломаете в функционале? описанное выше Инет1----Keenetiс/ТД---------Основной/Keenetic----Инет2

Такое поведение было много раз и видел на 42 и т.д. Так как в стандартном WG никаких "левых/мусорных" пакетов быть не может, то поведение сервера который ориентирован на "стандартный" WG не предсказуемо. Так же для примера который был выше при

Работает на 43B2 Что там у вас за хитрые настройки в asc, с самыми простыми все работает. 1. Перезапуск роутера, интерфейс WG0 поднят и есть соединение. 2. Спустя некоторое время соединение WG0 пропадает. 3. Спустя некоторое время соединение WG0 поднимается само (лог после перезапуска ниже) 4. Поднял второй на Нидерланды WG - так же все ОК, но согласно системного монитора и того что выше второй WG по сессии на 2 минуты дольше. WG0 - 2:45, а WG1 - 4:47 Повторюсь ОБА подняты после перезагрузки роутера. Ремарка по debug есть кой какие не понятки на WG0 (но он хитрый и работает). Позже перейду на основном на 43B2.

Делал когда то Инет1----Keenetic1[LAN]-------[LAN]Keenetic2---Инет2 1. Так как для клиента важен адрес шлюза, т.е. если IP Keen1 то на Инет1, если IP Keen2 то тогда Инет2. 2. Есть основной маршрут на любом из Keen1 или Keen2 который в таблице "default". 3. При пропадание Инет1 на Keen1 надо просто на нем сменить "default" на -> "default" на Keen2, при появление Инет1 (тут зависит от вида подключения провайдера, речь просто DHCP от провайдера или ppp) "default" на Keen1 может просто смениться сам и будет указывать на Инет1, если нет (не смотрел как сейчас на 4.3 c подъемом default) то ручками сменить default. 4. На роутере Keen1 нужен Entware (пакет ip route) и пара скриптов или один.

Да и 3-5 многовато, для скорости и "1" сойдет

Два WG (с asc, один специфиц. так же на asc) проблем нет на обоих 43B1. Оба поднимаются, что после перезагрузки роутера, что так (например передергивание канала на котором они подняты, правда один на одном другой на другом) Ремарка при настройках параметра "keepalive-interval 120" на специфиц. WG была проблема с handshake ... try (т.е. держался чуть менее суток или менее 12часов, но поднимался каждый раз сам) при установки "keepalive-interval 60" проблема ушла (держится несколько дней). Никаких ping-check

https://github.com/MicrosoftDocs/windowsserverdocs/blob/main/WindowsServerDocs/storage/file-server/file-server-smb-overview.md

для начала в selftest есть такие строки, чтоб определить на каком порту и какой USB устройство подключено по USB3 (Spd=5000) Второе - Я выше вел речь про - какой протокол активен, подключаемся к 1810 (к его диску можно просто проводником войти в любую папку) и PowerShell набрать Get-SMBConnection вывод команды версия SMB используемая для подключения ServerName столбец Dialect. В моем случае 3.1.1 Вторая команда Get-SmbConnection | ft ServerName,ShareName,Dialect,Encrypted,UserName про SMB шифрование, столбец Encrypted в моем случае "false" Так же для Win11 можно попробовать проверить на Подписывание (ну это для успокоения просто) Пока это.

Начните с проверок настроек на клиенте SMB.

вариант 1 Стат маршруты в основном профиле на WG - ОК не пропадают, как ранее работало, так и на любой 4.3.х вариант 2 Стат маршруты в созданном профиле и в нем клиенты - ОК не пропадают, как ранее работало, так и на любой 4.3.х auto - тогда, когда станет доступен указанный в нем шлюз reject - включить, чтобы использовать только выбранный интерфейс к указанному месту назначения, если указанный интерфейс не активен, то трафик не передается по другим возможным маршрутам, только в месте с auto. Маршруты прописываются ручками - а не каким то добавлением из файла.

Чтоб понять как правильно то нужно чуток времени и чуток понимания, что и как. Начать с клиента, т.е. на клиенте запускаем то что нужно и отлавливаем его запросы DNS. Нам нужны ответы сервера DNS на эти запросы в которых указаны IP адреса. Далее пробить этот IP адрес и выяснить по нему - один он или сеть (какая маска). Может получиться так что для вашего клиента и его работы нужно всего-то 7-10 маршрутов.

Скрипт запуска данного сервиса /opt/etc/init.d/S89qbittorent #!/bin/sh ENABLED=yes PROCS=qbittorrent-nox ARGS="--webui-port=9080 --profile=/opt/etc --configuration=entware -d" PREARGS="" DESC=$PROCS PATH=/opt/sbin:/opt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin export LC_ALL=en_US.UTF-8 . /opt/etc/init.d/rc.func Далее согласно "--profile=/opt/etc --configuration=entware -d" идем в "/opt/etc/qbittorrent_entware" в нем есть каталог "config", а в нем "qBittorent.conf"