KorDen

Всё там есть Поправка: только если он с IPsec. Если это голый туннель, вроде бы надо открывать, т.к. ISP у нас public и автоматом правил не добавляется, как для IPsec. (давно экспериментировал с голыми туннелями, не помню точно)

Я так и не понял, что вы хотите. Причем тут iptv, что за 3 подключения? Где вы собираетесь это iptv смотреть? Первый пункт хотелок решается настройкой соединения любого типа через какого-то внешнего провайдера (Если есть свой сервер - можно какой-нибудь IPIP, у провайдеров подобных услуг наверняка будет OpenVPN либо L2TP/IPsec, последний шустрее) и дальнейшей настройкой маршрутов до нужных IP через него.

нет, там wan - одна сетевушка, lan - свич, соединенный со свторой сетевушкой. Поэтому максимум до трех,не заходя на проц. Хотя в прицнипе.. 4 на вход, 3 проходящих, 1 заходит на проц и выходит через WAN - вполне себе... Но это как-то совсем

Увидел промелькнувший в логах system failed, решил поделиться self-test'ом. Лог с "клиента", в 19:43 обновлял прошивку на "сервере" Aug 26 19:44:28 ndm: Network::Interface::SecureIPTunnel: "IPIP2": IPsec client layer is up, do start tunnel layer. [C] Aug 26 19:44:28 ndm: Network::Interface::SecureIPTunnel: "IPIP2": system failed [0xcffd02bd], unable to change tunnel: file exists. [C] Aug 26 19:44:28 ndm: Network::Interface::SecureIPTunnel: "IPIP2": system failed [0xcffd00b0]. Aug 26 19:44:28 ndm: Network::Interface::SecureIPTunnel: "IPIP2": secured tunnel is ready.

@vasek00, как вы себе это представляете (исключая L2-сегменты), если в большинстве моделей после агрегации бутылочным горлышком станет шина между CPU и свичем?

Кстати про G722.. Столкнулся со следующим, на обоих роутерах актуальные драфты 2.10: - Ultra II, трубка S850HX (номер 3), в Entware стоит астериск, прописаны простейшие линии, типа - удаленная Giga II, трубка A420H (номер 1), подключена по IPIP-туннелю к Ultra II. Адрес SIP-сервера в обоих случаях - туннельный IP ультры. Если в кодеках стоит только G722, звонок 3->1 проходит. При обратном вызове 1->3 на S850HX нажатие "поднять трубку" просто ничего не дает, трубка продолжает звонить. Если в разрешенных кодеках стоит 722 и 711, то соединение в обоих случаях вроде бы успешно устанавливается на 711. Может чего где не усмотрел я. Как будет возможность протестировать - скину все селфтесты и прочие дампы с подробностями, это пока сильно сумбурное впечатление от первых экспериментов с G722.

@morohon, а в качестве сервера какая версия ОС? И возможно глупый вопрос, но всё же - локально (без VPN) к этому серверу подключается без проблем?

Мимокрокодильно замечу про Android: постоянно подключаюсь к домашней шаре Win7 через туннель (штатный VPN Android 4.4.2 и 7.1.2) через мобильную сеть и WiFi, клиент SMB - X-Plore, никаких проблем не замечал.

DPD-интервала там нет, только tunnel-local-source: 1.2.3.4 tunnel-remote-destination: 5.6.7.8 ipsec-enabled: yes ipsec-ikev2-allowed: yes ipsec-ikev2-enabled: yes ipsec-encryption-level: strong

show ipsec ... Connections: VirtualIPServer: %any...%any IKEv1, dpddelay=20s VirtualIPServer: local: [mykeenetic.net] uses pre-shared key authentication VirtualIPServer: remote: uses pre-shared key authentication VirtualIPServer: remote: uses XAuth authentication: eap VirtualIPServer: child: 0.0.0.0/0 === dynamic TUNNEL, dpdaction=restart IPIP0: x.x.x.x...y.y.y.y IKEv2, dpddelay=30s IPIP0: local: [IPIP0] uses pre-shared key authentication IPIP0: remote: [IPIP0] uses pre-shared key authentication IPIP0: child: 0.0.0.0/0[ipencap] === y.y.y.y/32[ipencap] TRANSPORT, dpdaction=restart IPIP1: a.b.c.d...%any IKEv2, dpddelay=30s IPIP1: local: [IPIP1] uses pre-shared key authentication IPIP1: remote: [IPIP1] uses pre-shared key authentication IPIP1: child: e.f.g.h/32[ipencap] === 0.0.0.0/0[ipencap] TRANSPORT, dpdaction=restart

IP или все-таки MAC? От двух интерфейсов с одинаковыми маками вполне себе сходить с ума будет, да. Еще, не знаю как в Ultra II (такую схему не приходилось на ней вроде делать), но на гиге 1 и 2 нельзя было иметь в сети ПК с тем же MAC-адресом, который на WAN-интерфейсе роутера, иначе всё валилось - https://help.keenetic.net/hc/ru/articles/213966709-Не-работает-клонирование-MAC-адреса-в-Keenetic-Giga-Extra-Viva-Ultra-Giga-II

@intelworker, так уже есть DPD-интервал IPsec в 30 секунд, и по нему вроде бы вполне рестартуется соединение, по крайней мере у меня соединение достаточно быстро восстанавливается после рестарта роутера-сервера.

При переходе на резерв будет корректно переключаться маршрут на резервный канал? А если уже есть маршрут до этого узла? А то я теперь осмыслил, что у меня при резерве через 3G туннель-то и не работал (основной канал давно не падал, так что на практике не обнаруживал) Т.е. я рассматриваю два случая с автотуннелями с default route на туннель: 1) к серверу подключается по беляку, стандартное резервирование проводного инета мобильным модемом, при переходе на резерв маршрут перепишется? 2) Опять резерв, но уже специально жестко прописан destination ip маршрутом через проводной инет. Возможна ситуация, когда основной инет лежит, но по локалке сервер доступен (и там есть инет), т.е. мне именно надо чтобы в случае падения сети был вариант остаться на туннеле, и только потом уходить на модем. Собственно, сейчас только так и можно сделать.

Да, про это я забыл. И необходимость вполне логична. У меня маршруты уже давно были прописаны, еще когда туннелей не было.

Не-а, не перепутаны. дескрипшен показывает ЧТО подключено через это соединение, т.е. дома у вас отображается соединение _с_ Office, ну и наоборот.

Рабочий пример, чуть адаптированный вам: Дома: interface IPIP4 description Office security-level public ip address 192.168.255.2 255.255.255.252 ip global 1000 ip tcp adjust-mss pmtu ipsec preshared-key <MySecretKey> ipsec ikev2 tunnel destination 92.9.9.1 up ! ip route default 192.168.255.1 IPIP4 На работе interface IPIP4 description Home security-level protected ip address 192.168.255.1 255.255.255.252 ip tcp adjust-mss pmtu ipsec preshared-key <MySecretKey> ipsec ikev2 tunnel source ISP up ! ip nat IPIP4 ipsec ikev2 работает только на 2.10. При его использовании индексы интерфейса (в моем примере это IPIP4) должны совпадать. IP адрса интефейса надо править только если у вас где-то вдруг есть сеть 192.168.255.x, в остальных случаях достаточно оставить так, это P2P линк. Возможно потребуется указать MTU с обоих сторон (если внешний MTU 1500, то "ip mtu 1420") Вроде ничего не забыл

Для того чтобы ходить в интернет через туннель, вам нужен IPIP или GRE-туннель с IPsec. Далее на работе делаете туннель private или protected, делаете условно ip nat IPIP0; дома тип public, ставите ip global 1000 и у вас всё должно начать работать само. Однако если у вас нестабильный сигнал сети, от туннеля он стабильнее не станет, скорее наоборот, из-за инкапсуляции будет медленнее и глючнее.

iptables можно крутить из под OPKG, OPKG работает только с флешкой, на лайте нет возможности подключить флешку.

Создать новое IPoE можно без удаления из Home, он сам удалит

Похоже, на Ultra II действительно у ISP не сменить порт. на Giga II можно выбрать даже если он привязан к сегменту (он тогда сам отвязывается), на U2 не выбирается даже если убрать из сегмента. Думаю это из-за того что на U2 ISP = GigabitEthernet1 (отдельная сетевая от процессора), а на G2(3) все порты идут к свичу. Создайте отдельное IPoE подключение с нужным портом и назначьте его основным

Если порт закрыт - откуда строчкам взяться? Если уж так надо светить морду наружу, ставьте нестандртные порты, условно из 10000+ - ботов, которые долбятся по дефолтным портам, не счесть

Подсети в одном L2 сегменте или в разных? Т.е. они обе в сети Home, или же на кинетик приходит отдельная витуха от свича, куда воткнуты все камеры?

Авторизация точно проходит? Вроде как для digest-авторизации данного кода недостаточно, см. например https://stackoverflow.com/questions/31892143/php-curl-get-post-digest-authentication

Не совсем понимаю, при чем тут обратная совместимость конфига и передача обновленных правил одним запросом, с последующей обработкой логики, в том числе для обратной совместимости, на роутере?

Текущая логика ввода настроек фаервола с вебки приводит к потере удаленного управления Имеем: >20 строчек в межсетевом экране, в том числе на разрешение конкретным IP подключаться к веб-интерфейсу где-то в конце Добавляю новое правило - доступ к роутеру пропадает. Подключившись по удаленке на машину за ним, вижу что там осталось только несколько первых правил. Начинаю что-то подозревать, лезу в консоль браузера - а оно и впрямь, правила МСЭ передаются по очереди отдельными запросами /rci/access-list/permit (deny), причем каждый раз полным списком после очистки. Хто это придумал? *facepalm*