vasek00

Включил dnscrypt-proxy2 проверку на "счет виновника" и не нашел нечего : /opt/etc/init.d # netstat -ntulp | grep dnscrypt-proxy tcp 0 0 192.168.1.1:53 0.0.0.0:* LISTEN 2355/dnscrypt-proxy tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 2355/dnscrypt-proxy udp 0 0 192.168.1.1:53 0.0.0.0:* 2355/dnscrypt-proxy udp 0 0 127.0.0.1:53 0.0.0.0:* 2355/dnscrypt-proxy /opt/etc/init.d # Ни каких блокировок дополнительно нет. По системному монитору нет ни чего на что следовало бы обратить внимание - огромный трафик. При выключенной опции "server_names" ######## server_names = ['cloudflare', 'google', 'yandex'] в итоге согласно скаченных файлов "relays.md" и "public-resolvers.md" и например так же "quard9-resolvers.md" (в конфиге они включены) [sources.'public-resolvers'] urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md', 'https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md'] cache_file = 'public-resolvers.md' minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3' refresh_delay = 72 prefix = '' ## Anonymized DNS relays [sources.'relays'] urls = ['https://github.com/DNSCrypt/dnscrypt-resolvers/raw/master/v2/relays.md', 'https://download.dnscrypt.info/resolvers-list/v2/relays.md'] cache_file = 'relays.md' minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3' refresh_delay = 72 prefix = '' ## Quad9 over DNSCrypt - https://quad9.net/ [sources.quad9-resolvers] urls = ['https://www.quad9.net/quad9-resolvers.md'] minisign_key = 'RWQBphd2+f6eiAqBsvDZEBXBGHQBJfeG6G+wJPPKxCZMoEQYpmoysKUN' cache_file = 'quad9-resolvers.md' prefix = 'quad9-' и переменной "refresh_delay = 72" будет происходить тестирование всех серверов согласно списка в этих файлов, да еще потом refresh_delay На основании ответов "ms" будет выбран основной - быстрый для работы (в данном случае sth-doh-se = rtt: 46ms) Рекомендация выбрать три наиболее быстрых по ответу, и включить строку "server_names" и проверить утверждение Обнаружил у себя аналогичную проблему - огромный исходящий трафик, видимый в странице "Системный монитор" в WEB-интерфейсе.

В моем случае настроил на такой режим и он устраивает в таком варианте, релиз 3.4 (но и ранее работало так же) Роутер cifs share D3-2 fc5d.......401: share D3-1 D3-1: automount permissive Windows 10, SMB1 выключен PowerShell 1 Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB2 -Type DWORD -Value 1 –Force 2 Get-SmbServerConfiguration | Select EnableSMB2Protocol EnableSMB2Protocol ------------------ True 3 Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters | ForEach-Object {Get-ItemProperty $_.pspath} EnableAuthenticateUserSharing : 0 NullSessionPipes : {} ServiceDll : C:\Windows\system32\srvsvc.dll ServiceDllUnloadOnStop : 1 autodisconnect : 15 enableforcedlogoff : 1 enablesecuritysignature : 0 requiresecuritysignature : 0 restrictnullsessaccess : 1 Guid : {98, 21, 51, 217...} SMB2 : 1 PSPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Service s\LanmanServer\Parameters PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Service s\LanmanServer PSChildName : Parameters PSProvider : Microsoft.PowerShell.Core\Registry 4 sc.exe qc lanmanworkstation [SC] QueryServiceConfig: успех Имя_службы: lanmanworkstation Тип : 20 WIN32_SHARE_PROCESS Тип_запуска : 2 AUTO_START Управление_ошибками : 1 NORMAL Имя_двоичного_файла : C:\Windows\System32\svchost.exe -k NetworkService -p Группа_запуска : NetworkProvider Тег : 0 Выводимое_имя : Рабочая станция Зависимости : Bowser : MRxSmb20 : NSI Начальное_имя_службы : NT AUTHORITY\NetworkService Далее доступ - локальная сеть Итог перезапуск ПК все так же Клиент смартфон доступ на ПК win10

Вариант А IP-CAM----wifi/lan---KN1711(VPN-клиент)-----Интернет------Роутер(VPN-сервер)----wifi/lan---Клиент IP-CAM----wifi/lan---KN1711(wireguard)------Интернет------Роутер(wireguard)----wifi/lan---Клиент IP-CAM----wifi/lan---KN1711(wireguard)------Интернет------Клиент(VPN-сервер/wireguard) Нужен белый IP на второй стороне, маршрутизация даст проход в лок.сеть 1711 Вариант B IP камера может работать работать по http/https, то есть в ee WEB есть доступ к SD карте

При наличие Giga-III т.е. USB порт + "Entware flash хотя бы на 1-2Gb + cron + ndmq" и отключайте/включайте как хотите (хоть через cli хоть минуя cli) в автомате и в нужное время.

Ждать 3.5. А так при включение/подключение устройства оно будет подключаться к точке у которой rssi лучше (в данном случае к менее отрицательному), т.е. если у основного роутера он равен -50 а у ретранслятора -45 то подключение будет к ретранслятору у которого -45. Если надо подключение к основному то уменьшить уровень у ретранслятора, так чтоб он был -55 -60 для данного клиента или можно изменить его расположение - ретранслятора.

Что-то все у вас как то сложно. Пример ниже все находиться в одной сети LAN, за интернет отвечает другое устройство у которого IP х.х.х.100 на нем же и DNS, далее в сети есть KN18 на котором WAN не используется но он управляет wifi системой KN30. При схеме Интернет---Роутер(LAN)----(LAN)KN18(LAN/wifi)-----(LAN/wifi)KN30 Роутер - x.x.x.100 KN18 - x.x.x.97 KN30 - x.x.x.98

При чем тут управляющий не управляющий wifi роуминг Инет----WAN[роутер1]LAN---LAN[Роутер2]LAN---LAN[Роутер3]LAN---LAN[Роутер4] На роутер4 WAN порт выключен (по барабану какой режим на нем), для того чтоб на нем был интернет достаточно маршрут на роутер1 и DNS адрес от роутера1

Для работы какого либо устройства на котором нет интернета нуже маршрут по умолчанию, т.е.нужно указать маршрут на основной роутер http://192.168.1.хх/controlPanel/staticRoutes "Статические маршруты" - "По умолчанию" - "IP_нужного_роутера_на_котором_выход_Интернет" - "Имя_домашнего_сегмента" http://192.168.1.хх/controlPanel/secureInternet "Интернет-фильтр" - "Указать адрес DNS сервера" - "IP_нужного_роутера_на_котором_выход_Интернет"

Рассмотрим вариант на два провайдера проводные с pingcheck только на основном канале : 1. Основной PPTP (интерфейс его PPP1), поднят pingcheck на данном интерфейсе 8.8.8.8 2. Резервный PPPoE (интерфейс его PPP0) Путем смены адреса в сервисе pingcheck будем им управлять, в данном случае адрес 8.8.8.8 в качестве доступного и 100.100.100.100 в качестве не доступного. Статус рабочей системы, default на основном канале PPP1 и pingcheck 8.8.8.8 / # ip r default dev ppp1 scope link 1хх.ххх.ххх.1 dev ppp0 proto kernel scope link src 1хх.ххх.ххх.хх4 ... IP_DNS1_Inet dev ppp1 scope link IP_DNS2_Inet dev ppp1 scope link хх3.хх6.ххх.хх6 dev ppp1 proto kernel scope link src ххх.ххх.ххх.хх2 / # Меняем адрес на PPP1 для pingcheck 100.100.100.100 через некоторое время смена default маршрута на резервный default dev ppp0 scope link 1хх.ххх.ххх.1 dev ppp0 proto kernel scope link src 1хх.ххх.ххх.хх4 ... хх3.хх6.ххх.хх6 dev ppp1 proto kernel scope link src ххх.ххх.ххх.хх2 ppp0 Link encap:Point-to-Point Protocol ... RX bytes:18446185 (17.5 MiB) TX bytes:3035527 (2.8 MiB) ppp1 Link encap:Point-to-Point Protocol ... RX bytes:46472 (45.3 KiB) TX bytes:60282 (58.8 KiB) канал основной доступен PPP1 но default не на него Идем в WEB на данную страницу настройки канала, а там все красно 1. Параметры IP и DNS === Получен адрес ххх.ххх.ххх.хх2 2. Аутентификация у провайдера (PPPoE / PPTP / L2TP) === Интернет недоступен (Ping Check) Ждемс у моря погоды, а в ответ то же самое, ну тут как бы другого и не следует ожидать, так как по данному каналу PPP1 адрес для pingcheck 100.100.100.100 не доступен default dev ppp0 scope link 1хх.ххх.ххх.1 dev ppp0 proto kernel scope link src 1хх.ххх.ххх.хх4 ... хх3.хх6.ххх.хх6 dev ppp1 proto kernel scope link src ххх.ххх.ххх.хх2 И так будет до тех пор default на PPP0 пока для pingcheck на PPP1 не будет доступный адрес, меняем его на 8.8.8.8 и получаем возврат на основной канал PPP1 ppp0 Link encap:Point-to-Point Protocol ... RX bytes:18552799 (17.6 MiB) TX bytes:3096056 (2.9 MiB) ppp1 Link encap:Point-to-Point Protocol ... RX bytes:3742 (3.6 KiB) TX bytes:1659 (1.6 KiB) / # ip r default dev ppp1 scope link 1хх.ххх.ххх.1 dev ppp0 proto kernel scope link src 1хх.ххх.ххх.хх4 ... IP_DNS1_Inet dev ppp1 scope link IP_DNS2_Inet dev ppp1 scope link хх3.хх6.ххх.хх6 dev ppp1 proto kernel scope link src ххх.ххх.ххх.хх2 / # Единственное фишка, это полученные адрес DNS провайдера для PPP1 основного канала (IP_DNS1_Inet, IP_DNS2_Inet) в данной обработке, т.е. когда pingcheck на 100.100.100.100 канал есть но адресов DNS провайдера нет.

О каких проблемах может идти речь в данном случае : 1. "Качественная проработка band-steering" - со стороны кого - клиента/роутера 2. "какую-то не стандартизированную фич" Можете то же почитать И ссылка была выше или повторю тут https://wi-cat.ru/wi-fi-roaming/migraciya-rouming-v-wi-fi-setyah-chast-2-band-steering/ так же от разработчика ПО для роутеров (на базе Meditek). Прочитав можете сделать вывод для себя о видении данной реализации "band-steering" двух разработчиков ПО по данному направлению.

Ping-check наблюдает за подключением (сетевым интерфейсом), к которому привязан. Независимо от маршрутной таблицы, он отправляет пакеты ICMP или TCP в свой интерфейс, и в дополнение к физическому линку, является критерием: пригоден этот интерфейс или нет

Тогда ваши слова не уместны так как вы не в теме, как и не в курсе про своего клиента, что у него есть а чего нет. реализовали какую-то не стандартизированную фичу, а рядовой пользователь страдать должен? Нехорошо...)) Как вы говорите для голосящих, то всем своим знакомым или на форумах рекомендую при наличие 2.4 и 5 данный функционал отключить, мало того wifi ssid еще и разделен 2.4 и 5. Если хотят по баловаться то могут попробовать своих клиентов. А если одним роутером не получается то устанавливается второй.

1. Основной канал при наличие нескольких определяется простой переменной "ip global 20000" чем выше данное значение тем приоритетней канал, т.е. основной тут RT 2. Отработка включения резервного канала работает и без включенной ping check 3. Профиль доступа и приоритеты варианты 4. Повторюсь про ping check Как это выглядит т.е. если будет отлуп по ping на данном интерфейсе или канале PPPoE1 то нужно принять меры по его восстановлению. Тут как бы два вопроса : 1. проблема у провайдера на его оборудование (тут контроль в самом протоколе "lcp echo 30 3" и алгоритм его установки) 2. у провайдера все нормально, т.е. линк есть, но какие то проблемы в самом интернете (где то там далеко, после провайдера т.е. на выбранный сервер запросы не прошли) Его и можно использовать как триггер отсутствия интернета по проводу. По этому еще раз осмыслите, у вас понятие переключение на 4G при не работающем основном/проводном но он работает и поднят, у вас заблокирован далее провайдером. Где взять исходники этого чудесного кода и переписать его под себя? Роутер не много не тот, при наличие OPTWARE могли бы написать скрипт для своего случая. На текущем может вариант - создать второй профиль, поменять в нем местами каналы, сделав основным 4G и перекидвать пользователей - ручной.

По пробуйте осилить https://wi-cat.ru/wi-fi-roaming/migraciya-rouming-v-wi-fi-setyah-chast-2-band-steering/ (Роуминг миграция клиентов между ТД в Wi-Fi сетях — Часть 2 – Band Steering), а при желании можно и весь комплект статей про роуминг, что и как. Много интересного можно найти и на верное ответ про "Band Steering".

Не понятно, что вы хотите от использования "ping check", осмыслите еще раз. Настройте без "ping check". На пальцах есть сетевой интерфейс и команда ping через этот интерфейс например ping -c4 -I ppp1 1хх.ххх.ххх.ххх т.е. -с4 четыре пакета будут посланы через -I ppp1 интерфейс на нужный IP 1xx.xxx.xxx.xxx, хотя default маршрут через ppp0 в отличие от простого "ping". ping 1хх.ххх.ххх.ххх default dev ppp0 scope link

https://help.keenetic.com/hc/ru/articles/360010592379-WireGuard-VPN https://help.keenetic.com/hc/ru/articles/360012075879

Интернет1-роутер1(LAN)-----(LAN)роутер2-Интернет2 1 Для клиента важен маршрут по умолчанию (default) это Роутер1 или Роутер2 - можно менять на клиенте. 2. Или менять маршрут по умолчанию (default) на роутере при пропадании интернета на другой роутер - нет Инте1 на роутер1 маршрут по умолчанию на роутер2 - появился Инет1 на роутере1 он сам сменит маршрут Вопрос как отследить пропажу на роутер1 - если мне не изменяет память "хук-скрипты" и это https://github.com/ndmsystems/packages/wiki/Opkg-Component -> ndm/wan.d можно отследить падение WAN и в этот момент сменить маршрут на роутер2, т.е. наличие OPKG. Так же примеры скриптов https://gist.github.com/top4ek/0c3de14a73f0313221522430407e9d83

О каком обновлении протокола идет речь если конф TSMB релиз 3.4 [global] ... dialect_max = SMB3.1.1 ... [/global]

Где что слушается и слушалось ранее на текущем 3.4 / # netstat -ntulp | grep :445 tcp 0 0 192.168.1.1:445 0.0.0.0:* LISTEN - tcp 0 0 :::445 :::* LISTEN - / # netstat -ntulp | grep :139 tcp 0 0 192.168.1.1:139 0.0.0.0:* LISTEN - tcp 0 0 :::139 :::* LISTEN - / # Аналогичный расклад на релизах 33A3, 33B2, 301A, 215C1, 215A4 Релиз 214А2 tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 542/nqcs tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 542/nqcs

(сервер)WG---Интернет--WG(клиент)-------LAN------Клиент На клиенте WG и клиент на LAN делает ping nwg0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.16.131.100 P-t-P:10.16.131.100 Mask:255.255.255.0 UP POINTOPOINT RUNNING NOARP MTU:1420 Metric:1 RX packets:912 errors:0 dropped:0 overruns:0 frame:0 TX packets:1425 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:50 RX bytes:1077824 (1.0 MiB) TX bytes:122772 (119.8 KiB) ip ro default dev ppp0 scope link 10.16.131.0/24 dev nwg0 proto kernel scope link src 10.16.131.100 192.168.1.0/24 dev nwg0 scope link 192.168.130.0/24 dev br0 proto kernel scope link src 192.168.130.100 где 192.168.1.0/24 удаленная сеть (сервер)WG или она же через туннель nwg0 192.168.130.0/24 локальная сеть WG(клиент) На клиенте 192.168.130.10 в сторону 192.168.1.2 Обмен пакетами с 192.168.1.2 по с 32 байтами данных: Ответ от 192.168.1.2: число байт=32 время=34мс TTL=62 Ответ от 192.168.1.2: число байт=32 время=34мс TTL=62 Ответ от 192.168.1.2: число байт=32 время=38мс TTL=62 Ответ от 192.168.1.2: число байт=32 время=34мс TTL=62 Статистика Ping для 192.168.1.2: Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь) Приблизительное время приема-передачи в мс: Минимальное = 34мсек, Максимальное = 38 мсек, Среднее = 35 мсек Пакет идет не по default маршруту а по записи 192.168.1.0/24 dev nwg0 scope link На второй стороне чтоб был ответ запись так же должна быть в сторону сети 192.168.130.0

На любом устройстве есть таблица маршрутов => т.е. нужно описание с двух сторон. На клиенте описать вашу удаленную сеть к которой нужен доступ чтоб отправленный "пакетик" знал с какого интерфейса он должен уйти для нужной вам сети. Например команды route add -net 192.168.10.0 netmask 255.255.255.0 gw 10.16.10.100 Или смотрите команду "ip route add 192.168.10.0/24 via 10.16.10.100" LAN---192.168.1.0/24--[192.168.1.1(роутер)IP_nwg0_10.16.10.1]---туннель---[IP_nwg0_10.16.10.100(Клиент)192.168.10.1]----LAN

Обратить внимание на три места в настройке : 1. сам туннель/пир 2. межсетевой экран 3. маршрутизация (доб.стат маршрута)

Смотрите тему по дате март 2020 возможно вам поможет

Есть вариант по проще для лок.сети, разрешить одному а остальным заблокировать - на базе "регистрация устройства" и "policy".

Для PPP интерфейса (подключение к провайдеру) например PPPoE - "interface PPPoE0" использовать команду "ipcp no name-servers" В итоге загрузка роутера и как происходит по времени