KorDen

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-модем"?

Вроде в 2.12 клиенты не должны кикаться с 5 при слабом сигнале. Однако как минимум на 2.12.A.4.0-9 и -6 (и вроде -5) у меня на KN-1010 смарфтон вылетает с 5 прямо при передаче с логами вида bndstrg: band steering: client .... is NOT allowed to connect to 5GHz band (Low RSSI: -80) Причем дальше смарт кучу раз переподключается на 2.4, отключаясь с "reason: STA is leaving or has left BSS" Так и должно быть? (в self-test это в частности промежуток с 15:21)

Либо у провайдера какие-то движения с GGC, либо роутер чудит с определением IP ближайшего GGC. Ради интереса: кто-нибудь пользуется нестандартными DNS-серверами, Яндекс/AdGuard, и проч?

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

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

Попробуйте для начала поиграться с установкой-удалением SIP ALG со стороны клиента

Окей, после ребута он преестал лезть в старую репу..

Так это уже после двойного update-upgrade я делаю update и он грузит помимо новых списков еще и старые.

А это нормально, что хотя в opkg.conf остались прописаны только новые пути, при opkg update он продолжает стучаться и по старому пути? ~ # opkg update Downloading http://entware-3x.zyxmon.org/binaries/mipsel/Packages.gz Updated list of available packages in /opt/var/opkg-lists/keen3x Downloading http://bin.entware.net/mipselsf-k3.4/Packages.gz Updated list of available packages in /opt/var/opkg-lists/entware Downloading http://bin.entware.net/mipselsf-k3.4/keenetic/Packages.gz Updated list of available packages in /opt/var/opkg-lists/keendev

Сделайте sh run и посмотрите что у вас там сейчас на интерфейсе. Если я правильно понял вашу последовательность действий - IP с интерфейса вы всё-таки не удалили, сделайте no ip address на туннеле

Ну вон же: (config-if)> ipsec preshared-key mytestingkey Ага. А вы что хотите сделать, чтобы была общая broadcast-локалка? Оно вам надо для чего-то конкретного, что не умеет в IP-маршрутизацию? Может вам и не нужно EoIP, сбриджованное с Home?

Словил странный глюк (сейчас 2.12.A.4.0-6), пока не было времени поэкспериментировать и выявить, нужно было срочно починить. Две линии с разными номерами с одного сервера, две S850HX. Линия 1 - IN/OUT с трубок 1 и 2, Линия 2 - IN/OUT только с трубки 2. В итоге получилось, что звонки на первую линию так же идут только на трубку 2, первая трубка при входящем вызове молчит, т.е. ощущение что правило для входящих для 2 линии применилось и для 1 линии. Исходящие можно было делать с обоих. Перезагрузка не помогла, починилось удалением второй линии (не пробовал разрешить входящие со 2 линии на 1 трубку).