KorDen

В частности 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

Попробуйте для начала поиграться с установкой-удалением 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 трубку).

Динамический проброс (ssh -D 1234 с последующим socks-прокси на этот порт с выходом куда угодно через роутер, в т.ч. в инет) работать будет, или только статический/с ограничениями?

Пока - нет, но stv6110.ko уже есть в модулях, да и учитывая "Drivers are included in kernel branch 2.6.39", чую, поддержка скоро появится, если будете тестировщиком @McMCC, похоже тему надо переименовывать в "Смотрим цифровое телевидение (DVB) через кинетик" и указывать кто какие стандарты поддерживают

@McMCC, я уже собрал у себя 4.0.9 с поддержкой DVB, всё работает на Ultra II (ну, еще надо будет работоспособность DVB-S ради интереса проверить..)

Ага, @Александр Рыжов подсказывает, что в Entware tvheadend собран без поддержки DVB, а я видимо действительно уже запутался где я что видел. @McMCC, уже готового tvheadend с поддержкой dvb у вас случаем нет?

Я пользовался тем, что есть в Entware-3x, т.е. 4.0.9. На ультре он вроде успешно видел T230C, сейчас воткнул на экстре только T230C - тоже не видит напрямую, что-то где-то поломано похоже.. Edit: Так, на 2.12.A.4.0-2 вроде тюнеры завелись (вообще, не в tvheadend), пошел обновлять ультру на проверку...

О, на драйвере tbs похоже взлетело, по крайней мере по логу Update: Работает DVB-C minisatip -> tvheadend, напрямую в tvheadend тюнер что-то не подхватывается, но это уже детали