KorDen

А разве пчела уже перестала выдавать динамические беляки? Или это отголоски купленных сеток?

Речь про раздельные инстансы роуминга для каждого SSID (e.g. Main/Guest)

Роуминг будет отстрелом как я понимаю? Будет ли совместимость с Band Steering + учтено ли, что доп.точки могут быть 2.4-only например? Рассматривается ли роуминг для дополнительных SSID (гостевая)?

В компонентах прошивки есть сенсор Netflow, позволяющий сливать инфу по соединениям на внешний сервер.Теоретически коллектор можно поставить и на роутер. Вы же понимаете, что сейчас бОльшая часть трафика - HTTPS, максимум отслеживаемый по имени домена в SNI при установлении соединения?

У них поговаривают сегодня после вброса и выброса 1к IP что-то поплохело очень сильно.

Стоп. Речь про именно галку components auto-update, а не про components commit. Каково её поведение?

Предлагаю добавить возможность по нажатию кнопки делать usb power-cycle нужного порта (без привязки к интерфейсу модема, просто порт 1/2) и/или (re)mount устройства в указанном порту. Лично мне это надо для возможности примонтировать обратно флешку (и запустить сервисы на ней) без физического перетыкания (и входа в CLI). На практике так же может пригодиться для быстрого ручного ребута модема, если роутер и USB-удлинитель закреплены на стене и заходить в морду долго, а роутер вон на стенке висит

Там в идеале не только шторку, а надо все padding'и уменьшать вдвое и так далее, потому что даже на FullHD дашборд занимает три экрана, а можно было уместить всё в одном 1366*768. Но этот чертов тренд win10 чтобы скороллить-скроллить-скроллить и поменьше текста на квадратный сантиметр, иначе хомячки выпадают от переизбытка информации.

В последней прошивке поломан TypeError: f.getComponentsList is not a function at new e (http://192.168.0.1/scripts/app-07faaf8788.js:16:12241) at Object.u [as instantiate] (http://192.168.0.1/scripts/vendor-5e0d2f978f.js:12:21637) at http://192.168.0.1/scripts/vendor-5e0d2f978f.js:13:16401 at Object.<anonymous> (http://192.168.0.1/scripts/vendor-5e0d2f978f.js:32:16587) at http://192.168.0.1/scripts/vendor-5e0d2f978f.js:12:5956 at bt (http://192.168.0.1/scripts/vendor-5e0d2f978f.js:13:11367) at h (http://192.168.0.1/scripts/vendor-5e0d2f978f.js:13:3774) at a (http://192.168.0.1/scripts/vendor-5e0d2f978f.js:12:31414) at http://192.168.0.1/scripts/vendor-5e0d2f978f.js:12:30945 at http://192.168.0.1/scripts/vendor-5e0d2f978f.js:13:1708

Насколько мне известно, роутер сам после автоматического обновления в перезагрузку не уходит.

А, как я понимаю, каждая копия смотрит на DNS, доступные конкретной политике? Т.е. если политика на IPIP0, то нужны либо глобальные DNS (без "on ISP"), либо "on IPIP0", чтобы работали девайсы в политике?

В курсе. Решается прописью в качестве name-server 192.168.1.1. Но каким тут боком это? Ничего не понял, что вы хотели всем этим сказать, и как это опять же относится к политикам? Собственно нюанс, что все локальные сервисы продолжают работать с прошивочным резолвером - известен. Что еще-то?

Хм. На роутере включен opkg dns-override и стоит свой DNS-сервер в Entware. Попробовал сейчас создать политику и закинуть в него смарт - у него отвалился DNS, после прописки вручную внешнего DNS-сервера всё заработало... Откуда начинать копать..?

В частности S850HX сохраняет несколько баз (работает только одна выбранная), и при выборе есть настройка "Лучший блок", но на практике я её не проверял.

Я говорил про чистый IPsec-туннель site-to-site, он через NAT ходит Классический IPsec-туннель, который настраивается из web-интерфейса, работает через политики. Как следствие, нельзя нормально настроить взаимодействие более двух сетей (например, если у вас два роутера подключаются к третьему-серверу и надо чтобы все могли заходить ко всем), нельзя сделать нормально проброс порта с белого IP за серый и проч. Оно пока возможно вам не нужно, но потом обязательно что-нибудь может захотеться Поэтому проще сразу сделать туннель на классической маршрутизации.

IPIP over IPsec, нацеленный на KeenDNS-имя Keenetic II (он будет работать в прямом режиме т.к. IP белый). Прошивка естественно должна быть минимум delta. В общем случае, скажем локалка Keenetic II - 192.168.1.1/24, локалка Giga II - 192.168.2.1/24, если не заморачиваться с фаерволом: Keenetic II: interface IPIP0 description Giga security-level private ip address 172.31.255.1 255.255.255.252 ip tcp adjust-mss pmtu ipsec preshared-key <ключ> ipsec ikev2 tunnel source <имя интерфейса с интернетом> up ! ip route 192.168.2.0 255.255.255.0 172.31.255.2 IPIP0 auto no isolate-private Giga II: interface IPIP0 description Keen2 security-level private ip address 172.31.255.2 255.255.255.252 ip tcp adjust-mss pmtu ipsec preshared-key <ключ> ipsec ikev2 tunnel destination <keendns-имя Keenetic II> up ! ip route 192.168.1.0 255.255.255.0 172.31.255.1 IPIP0 auto no isolate-private ну и на всякий случай выполнить на обоих "crypto engine hardware" хотя должно быть по-умолчанию включено Можно и просто IPsec-туннель без маршрутизации, но у него есть ограничения

Возможно соглашусь, хотя при наличии OPKG... (Впрочем, OpenVPN тоже издавна был сторонним пакетом..) Поддержу. Как минимум section/begin нужны, у некоторых Cisco-like интерфейсов еще есть универсальный поиск "show run <...>" типа "show run interface" Фломастеры. Мне например вообще больше нравится D**'ая простейшая идеология tagged/untagged, без всяких излишних переключений trunk/access Я бы еще добавил в хотелки исправление старой болячки - автодополнение второго и последующих уровней не работает, если предыдущие написаны сокращенно: sh -> show show run -> show running-config sh run -> сейчас ничего, а хотелось бы как в предудщем, чтобы по 10 раз tab не жать.

Чисто по VPN - напрямую нельзя, но при наличии где-то (с той стороны VPN например) socks-прокси (1.2.3.4:5678) можно по идее сделать такое вот (0.0.0.0 0.0.0.0 - подсеть и маска) ip static tcp 0.0.0.0 0.0.0.0 80 1.2.3.4 5678

Со стороны сервера - возможно. Со стороны роутера - в последних прошивках туннели уже упрощены максимально tap tcp/443 имеет смысл только если выходите в интернет через http-прокси или еще через какую-то "трудную" сеть. В остальных случаях лучше udp на любом нестандартном порту В последних прошивках уже давно есть OpenVPN из коробки ... а маршруты были всегда. Маршруты через OPKG имеют смысл только при использовании ipset и прочей экзотики.

php7-fastcgi не содержит файлов и не создает скрипт в init.d ~ # opkg files php7-fastcgi Package php7-fastcgi (7.2.2-1) is installed on root and has the following files: ~ # opkg info php7-fastcgi Package: php7-fastcgi Version: 7.2.2-1 Depends: libc, libssp, librt, libpthread, php7, php7-cgi Status: install user installed Section: lang Architecture: mipsel-3.4 MD5Sum: ff7acd63ca70817d3b2ccd0cb837379a Size: 746 Filename: php7-fastcgi_7.2.2-1_mipsel-3.4.ipk Description: As FastCGI support is now a core feature the php7-fastcgi package now depends on the php7-cgi package, containing just the startup script. Installed-Time: 1523257518

Из виндовых как минимум в uTorrent и qBittorrent можно указать диапазон исходящих портов, и оно правильно работает, проверено. Скажем, есть основной толстый проводной инет; резерв LTE-модем; VPN через текущий дефолтный канал. Большинство клиентов ходят через текущий дефолт. Для торрентов (source-based) и другого тяжелого, но не критичного трафика (скажем, онлайн-видеонаблюдение, при наличии локальной записи - тут уже destination ip:port based) задан жестко только толстый инет, и при его падении они должны дохнуть, чтобы не забить резерв и не выкачать лимит. При этом я например могу независимо закинуть условно ПК где крутятся торренты ходить в сеть через канал VPN, но торренты должны продолжить ходить через инет (по задаваемому приоритету правил или по принципу наиболее точного правила) Дальше думаю о том, что вроде как нельзя рулить destination ip/port, Мыcль улетает в сторону традиционных цисковских access-list или -t mangle -j mark, потому что как-то не совсем ясно, как будут указываться разные диапазоны входящих/исходящих портов в Ip hotspot. Скажем, правило "только толстый канал" в моем представлении бы содержало что-то типа (имена переменных условны) src_host aa:bb:cc:dd:ee:ff src_port tcp 20000 through 21000 src_host aa:bb:cc:dd:ee:ff src_port udp 20000 through 21000 dst_host 1.2.3.4 dst_port tcp 8443 dst_host 5.6.7.8/24 При этом у этого правила высший приоритет, дальше с приоритетом пониже я могу добавить для src aa:bb:cc:dd:ee:ff правило "ходить только через vpn" а условные торренты и пакеты в сетку 5.6.7.8/24 продолжат ходить мимо VPN (последнее это по сути обычный маршрут через заданный, добавлено для наглядности и чтобы были понятны приоритеты) Короче, типичный mangle/mark, только интегрированный с существующей системой резервирования инета.

По порту со стороны клиента же, как я и написал... Ну т.е. в клиенте строго указываем исходящий порт (диапазон), входящий трафик уже идет на один конкретный порт. А дальше политика на tcp/udp стримы с диапазона портов. В том числе в идеале хитрую политику на распределение по двум каналам... Или выделение по tcp/udp порту - тяжелая нагрузка?

Возможно ли в дальнейшем расширение до полноценного PBR по портам? Типа "не гнать торренты (source host aa:bb:cc:dd:ee port 1234) в 3G-модем"?

В SOHO-роутере на 5 портов? Вы ничего не путаете?

Подозреваю, возможности мониторить состояние хостов с точки зрения роутера. Скажем, банально измерять пинг/процент потерь до яндекса, или через прокси забирать данные по мониторингу локальных железок с офиса без использования туннелей. Но всё же это в сторону Entware, до тех пор пока в младших моделях флеш маленький и нет нормальной ФС для хранения настроек-сертификатов-etc, будет отчасти так же костыльно, как сейчас с конфигом OpenVPN