KorDen

А что с этим не так, входящий номер вполне себе отображается

Если у вас голый IPsec и он правильно работает, то порты никакие открывать не нужно, удаленная локалка доступна по своим внутренним IP. Что вы подразумеваете под пробросом?

Внесу свои пять копеек. Вначале тоже посчитал, что упрощение обновления до кнопки или даже полного автоообновления - зло. Потом вспомнил один случай. В этом году один местный провайдер обновил свои DNS-серверы. Все было хорошо, но тут начались проблемы - что характерно, у всех были Keenetic, и иногда асусы. С длинками и прочим жалоб не было. Как выяснилось - была бага в dns-прокси на кинетике, исправленная еще зимой 2013-2014, а народ так и сидел чуть ли не на стоковой прошивке, потому что все работало. Ну а длинки на стоковой все равно что не работают, их уже до этого обновили Поэтому я бы сказал что для массового пользователя упрощение обновления прошивки крайне полезно. Не забывайте, речь идет о stable, это у нас тут "в 12.0 сломали фичу, пойду откачусь на 11.5", там критичных багов вроде не было давно. Главное не уподобляться Microsoft и не делать это обязательным. Пожалуй, реализация dual image с фоновой загрузкой прошивки - лучший вариант - ну а дальше можно даже не ребутать - ставим загрузку в другой слот и ждем как мигнет свет или пользователь сам роутер ребутнет по питанию

- Поставить описание в начало, по возможности увеличить размер этого поля - когда много правил, все-таки в первую очередь смотришь на имя, чтобы не запутаться. - объединить "Интерфейс" и "IP-адрес", переименовав скажем в "Источник (Source)" - они не могут отображаться одновременно, а место пустует, можно использовать под другие поля. - добавить отображение состояния правила - ручное вкл/выкл и имя расписания, если имеется. - добавить возможность массового включения/выключения; массового выбора расписания - в идеале - добавить массовую смену интерфейса/IP источника и IP назначения. А вообще - хотелось бы видеть компактное массовое редактирование прямо в таблице - сейчас гораздо проще это делать через CLI...

На данный момент хотелось бы предложить: - добавить коды ответа SIP на страницу истории звонков и фильтры истории по трубке/линии/удаленному номеру. - сделать возможность сохранения внутренней истории вызовов в энергонезависимую память и отображение в вебе + доступ из OPKG - в топах есть неразмеченная область, или можно было бы указывать раздел на внешней флешке (как с захватом пакетов), да и во всех моделях с поддержкой модуля вроде есть /storage, условный файлик в стиле csv на 100 кб вместит вполне достаточное количество вызовов IMO Обе хотелки пригодились бы при диагностике всяких "а вот позавчера вечером мы что-то не могли дозвониться, ребутнули роутер, вроде дозвонились, не стали беспокоить" Теперь вопросы. Из текущих планов, что видел в последнее время, не увидел того, о чем было мельком сказано ранее, поэтому хотелось бы понять: - будет ли автоустановка даты и времени на каких-либо трубках? - будет ли история вызовов, берущаяся с базы? ________________________ С трубками, правда, есть один дурацкий момент.. Гигасеты в целом по качеству связи конечно лучше, но у них есть огромная проблема - дурацкий интерфейс, как по мне. И тут получается - гигасет поддерживается лучше, но панасоники гораздо дружелюбнее, по крайней мере из тех моделей, что использовал я. После панасоников, у которых в большинстве своем в истории вызовов в три строчки на одном экране отображается номер-имя-дата, при вызове и в телефонной книге в две строчки отображаются имя и номер, а при ожидающем вызове в три строчки пишут "ожидающий вызов" и имя с номером, гигасеты с гораздо бОльшим экраном, но НЕ УМЕЮЩИЕ ВЫВОДИТЬ ИНФУ В НЕСКОЛЬКО СТРОЧЕК и вечным блужданием по меню для просмотра даты звонка, или выводом по очереди в одну строчку имени и номера дико бесят. А многострочный экран они только на домашнем экране умеют адекватно заполнять. Скажите мне, если есть что на примете - есть ли сейчас модели, которые можно сейчас купить и использовать с базовым функционалом, но в будущем будут иметь поддержку всяких планируемых фич, и в которых нет такого дурацкого интерфейса, как на недорогих гигасетах? Где нормально используется большой многострочный экран, как в панасониках?

С появлением IPIP / GRE-туннелей пожалуй (как минимум для моих задач) вопрос практически не имеет смысла, поскольку ограничение касается только чистого IPsec. Хотя мне бы хотелось видеть более гибкую настройку туннелей в плане шифрования.. Только хотелось бы понять, в чем разница между голым IPsec и IPIP/GRE/EoIP over IPsec в данном случае...

Его легко обмануть при желании, если отдавать домен www.msftncsi.com - у того же Билайна например, по крайней мере раньше, винда считала что интернет есть даже если L2TP не подключено.

На 11-3 так и не проверил, проверил сразу с 11-4 на обоих - вроде, после ребута "сервера" спустя несколько минут "клиент" подключился сам, но сервер отправлялся в перезагрузку через веб, а не по питанию.. Проверю с отключением питания позже...

По крайней мере, "клиент" Giga 2 на 11-1 (v2.08(AAFS.1)A11) за пять часов с момента ребута Ultra 2 на 11-3 так и не переподключился. Клиент только сейчас перешил на 11-3, ультру пока не могу ребутнуть для проверки той же ситуации.

Можно ли (и как) настроить проверку доступности туннеля и таймауты отвала/переподключения, для ***overIPsec? Сейчас, насколько я понимаю, если "сервер" перезагрузился, то клиент не переподключится без дополнительного пинка вообще, или все-таки это уже сейчас настраивается?

Не обязательно, есть еще уход по ping-check

У меня подобного не наблюдается. Одна сетка подключена по IPIP over IPsec (AES256/SHA1/2048), другая по PPTP (MPPE128), между роутерами без туннелей пинг 1 мс, между компами через туннели без нагрузки пинг 1000 байтами стабильно 2-3 мс в обоих случаях.

Наконец-то добрался до роутеров, обновил, IPIPoverIPsec Ultra 2 - Giga 2 после обновления обоих поднялся нормально. Впрочем, и до обновления на 11.0-0 работал неделю без проблем

Нет, вам либо уйти обратно на v1, либо купить более новый роутер.

Это он наверное ждет OPKG для белого кинетика... Хотя, для белой гиги тогда собрали, и вроде вполне работоспособно.

@Angel, забавно, хотя я ни разу не видел его в продающихся - никс, среди прочих, периодически мониторю на предмет наличия и цен на интересующие меня позиции... Похоже, действительно он успел немного побыть на полках, интересно..

Просто для понимания: модуль Keenetic Plus DSL еще не выходил в официальную продажу вообще. А то мне кажется, у вас сложилось мнение, что он продавался ранее какое-то время, но потом они закончились/продажи прекратили, и на складах где-то пылятся куча девайсов с фатальным багом, и все ждут исправления/вторую аппаратную ревизию. Хотя тут мельком появлялись пользователи, писавшие про него, но это как я понимаю, единичные тестовые экземпляры.

А может стоит сделать отдельную вкладку туннелей, и на нее поместить все нестандартное? Ведь теперь в 2.08 появились GRE/IPIP/EoIP, конфигурируемые пока только из CLI, да и L2TP/IPsec еще..

Если рассматривать фантастический вариант, что кто-то разберет камеру, прочитает флеш и найдет пароль к учетке FTP (или сделает MITM) - можно запретить LIST/RETR/DELE для учетки, под которой ходят камеры, тогда из возможностей вредительства остается только вариант переполнения диска бесконтрольным STOR. А, ну еще вариант "шарахнуть в патчкорд 220" как наименее изощренный.

def gw у камеры будет адрес кинетика в новом сегменте, т.е. .200.1 Адрес FTP-сервера останется прежним, но в кинетике с включенным isolate-private нужно будет явно разрешить 192.168.200.0/24 -> 192.168.100.100, по умолчанию камеры не смогут достучаться до FTP-шника. Чтобы не запутаться, предлагаю такую последовательность: Создаем сегмент с DHCP но без NAT, в CLI кинетика делаем "no isolate-private", опционально меняем в кинетике IP у камеры, если он в привязанных, ребутаем камеру. (либо меняем настройки на камере, если она со статикой уже, шлюз 200.1) Она получит IP из нового сегмента, но между сетями фильтрации не будет и можно будет достучаться по новому IP, плюс камера продолжит успешно слать на FTP по старому IP. Дальше можно прописать на камере статику, если была по DHCP, и отключить DHCP-сервер. В принципе, на этом этапе уже часть шутников отсеится - IP не получают, интернета нет, если пропишут IP вручную. Но все еще есть неограниченный доступ к домашней сети, правда напрямую по IP. Ну а дальше уже химичить с фильтрацией между сегментами, включив isolate-private и играясь с фаерволом

- Делаем сегмент камер: "Домашняя сеть - сегменты" убираем галки на 1 порту, создаем сегмент, например Cam, со своими айпишниками, добавляем нужный порт. Чтобы нельзя было залезть в интернет, убираем галку "использовать NAT". Можно в принципе выключить DHCP-сервер, если у камер статика. - добавляем правила в межсетевой экран, которые будут разрешать трафик из сегмента камер к FTP-серверу, можно строго портом, и трафик из Home на IP камер для управления По-умолчанию isolate-private (изоляция приватных сегментов) включен, поэтому этого достаточно. Если isolate-private выключен, добавляем правила на запрет трафика Cam->Home В особо хитром варианте - отдаем сегмент Cam тегированным VLANом на LAN-порт, куда воткнут сервер, на сервере делаем два интерфейса.. Но тогда надо будет пошаманить в консоли, веб-интерфейс штатно не дает назначить один порт тегированным в одном сегменте и нетегированным в другом, либо тегированным в двух сегментах.

Не знаю, с этим связано, или нет, но улучшения похоже не только с ребутами произошли. У меня была ситуация, когда туннель Giga 2 - Ultra 2 периодически падал (спустя 10-20 часов в среднем) и не поднимался до принудительного пинка с обоих сторон - просто переставали идти строчки о пересогласовании туннеля, а при "пинке" в логах проскакивало блаблабла "is strongswan dead?". Сейчас уже 3 дня работает без отвалов. Ребутов лично у меня не наблюдалось ни ранее ни сейчас.

Штао?! Я вас умоляю, вы какой-то неправильный параноик - настоящие тут не водятся, дюже проприетарный софт NDMSv2

Я просто запускал штатный захват пакетов на Ipip0 и смотрел, идут ли по нему пакеты, когда я пытаюсь пинговать удаленную сеть. Т.к. пакеты не шли - было ясно, что они теряются на моем роутере, дальше пошел обдумывать почему они теряются и вспомнил про isolate-private

Поднял IPIPoverIPsec между Ultra 2 - Giga 2 на v2.08(AAUX.0)A11 (до этого был IPsec 2.08-2.06) с настройками из шапки.. Долго гадал, почему трафик от компов не ходит, потом, увидев что пакеты даже не уходят с home на ipip0, вспомнил про isolate-private - надо бы напомнить о нем в шапке, IMO. Роутинг в обе стороны после ip nat ipip0 работает корректно [вроде бы].. Теперь вопрос - как запретить трафик guest->home / guest->ipip, но разрешить home-ipip? В простом случае можно поставить security-level protected для Guest, но если надо к одному Ipip доступ дать, а к другому не давать? Еще вопрос до кучи - туннели идут в лимит двух IPsec или как?