-
Постов
2 268 -
Зарегистрирован
-
Посещение
-
Победитель дней
38
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент KorDen
-
@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.
-
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
-
При переходе на резерв будет корректно переключаться маршрут на резервный канал? А если уже есть маршрут до этого узла? А то я теперь осмыслил, что у меня при резерве через 3G туннель-то и не работал (основной канал давно не падал, так что на практике не обнаруживал) Т.е. я рассматриваю два случая с автотуннелями с default route на туннель: 1) к серверу подключается по беляку, стандартное резервирование проводного инета мобильным модемом, при переходе на резерв маршрут перепишется? 2) Опять резерв, но уже специально жестко прописан destination ip маршрутом через проводной инет. Возможна ситуация, когда основной инет лежит, но по локалке сервер доступен (и там есть инет), т.е. мне именно надо чтобы в случае падения сети был вариант остаться на туннеле, и только потом уходить на модем. Собственно, сейчас только так и можно сделать.
-
Рабочий пример, чуть адаптированный вам: Дома: 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 работает только с флешкой, на лайте нет возможности подключить флешку.
- 3 ответа
-
- 2
-
-
-
Похоже, на 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*
-
Тут желание общее - прибить легаси ip static с его причудами и неочевидными вариантами работы, о которых уже говорилось, и сделать управление NAT интуитивнее и функциональнее.
-
Тут проблема из той же оперы, что и у вас использование прошивочного strongswan вместо opkg install strongswan - нужна флешка, не везде есть свободный USB, следовательно это + хаб еще, дальше добавляется вероятность глюков хаба и флешки на каждом из узлов и возможное поведение после этого глюка.
-
Упс, действительно. SOHO-роутер не готов к ассиметрии траффика, так и до BGP недалеко Хотя какой-нибудь OSPF уже напрашивается, надоедает все ручками вбивать.