KorDen

Его легко обмануть при желании, если отдавать домен 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 или как?

- можно разъяснить подробнее weak/normal/strong, какие это proposals? - насколько я понимаю, чтобы ходить через другой роутер, надо на "сервере" прописать, условно "ip nat IPIP0", а на другом просто маршруты, либо задать ip global, и будет работать в том числе с логикой резервирования? - через EoIP DHCP-трафик ходит, или фильтруется? Можно ли это поведение настроить? Пример желаемой реализации я уже описывал - внутренние IP у роутеров 192.168.0.1/24 (DHCP на свои порты 2-100, def .1) и 192.168.0.101/24 (DHCP на свои порты 102-200, def .101), каждый сегмент в интернет ходит через свой роутер (с возможностью ходить по маршрутам через другой), но есть прозрачная сеть.

Мммм... Wat? На белой гиге нет VPN-сервера, или речь о подключении клиентом PPTP к вышестоящему серверу и далее классическая маршрутизация? Можно отключить NAT, поставить на соединение security-level private и настроить DHCP-Relay по идее.

А вы почитайте внимательно ченжлог. В официальном канале на 2.07.C.3-5 IPSec заявлен только для Giga III и Ultra II. Заветное тут, на форуме, читайте прикрепленные темы сверху.

В последнем обновлении 2.08 они появились, как я понимаю, только в CLI. Можно ли пример настройки? Скажем: есть два кинетика, сейчас между ними PPTP-туннель, до определенных маршрутов второй ходит через первый. Возможно ли такое теперь реализовать поверх IPsec, в том числе использование туннеля в качестве маршрута по умолчанию? Что лучше использовать и как? Второй вопрос: насколько я понимаю, EoIP - это этакий dev tap в терминологии OpenVPN, т.е. возможность построить единый L2-сегмент для работы приложений и железок, которым необходим один широковещательные домен, верно? А как в таком случае с пересечением сетей IPsec? Т.е. как я вижу, и как я уже изобретал на OpenVPN с dev tap - два роутера в разных местах, внутренние IP у роутеров 192.168.0.1/24 (DHCP на свои порты 2-100, def .1) и 192.168.0.101/24 (DHCP на свои порты 102-200, def .101) - в итоге все приложения, умеющие работать только в одном сегменте /24 прекрасно уживаются, подключенные в разных сетях. Медленно это было, но работало. Сейчас со скоростью IPsec с аппаратным ускорением на топовых моделях было бы интересно (и практически уже представляю, для чего можно применить) реализовать подобное опять, на других протоколах. Возможно ли?

Быть может, аппаратная часть мешает? Модем - это же вам не SDR (Software-Defined Radio, "как хочу, так и излучаю")

Подробнее суть кипиша: Использовать антенны-удлинители-etc не очень удобно - дело даже не в интерьере (в котором не хватает разве что 19" стойки, так что даже антенна индустриального исполнения его не испортит..), а в расположении. Экспериментально было установлено место наилучшего приема для Yota в (определенный угол балкона), и оно находится достаточно далеко от места установки ультры, чтобы туда аккуратно провести USB, и оно бы работало. Хотя есть вариант попробовать сделать кабель на CAT-6 витухе с активным хабом на конце, или что подобное.. Но это уже тема для другого раздела. Поэтому было решено поставить в этом месте какой-либо роутер. А раз роутер будет стоять возле окна, зачем умная железка будет пропадать зря? Нужно прокинуть на него гостевую сеть, которую можно включать при необходимости подключиться во дворе. Возможно еще прокинуть домашнюю сеть, вдруг захочу на балконе поставить какой-нибудь датчик, или камеру - а вот и розетка свободная! Entware стоит, но хочется максимально штатными средствами. Соответственно первый вариант, простой: делаем на этом роутере домашнюю сеть скажем 192.168.2.x, вланами пробрасываем домашнюю и гостевую сети основного роутера, а на основном роутере делаем второе IPoE с IP 192.168.2.2, таким образом управление вторым роутером через IP 192.168.2.1, соответственно для управления извне по туннелям надо добавлять дополнительный маршрут (если туннель не дефолтный маршрут). Из сети второго роутера нет доступа в сеть основного (за исключением варианта, описанного в KB, где два роутера соединяют кабелем и резирвируют друг через друга - возможно, стоит реализовать его...), кроме того, это второй NAT (192.168.1.x -> 192.168.2.x -> оператор), и по IPsec-туннелю управлять вторым роутером по идее не получится. Хочется попроще, и так уже в туннелях куча подсетей, не хочется делать еще одну подсеть. Хотя, наверное, было бы логичнее порезать сделать /28 или /27 для подобного использования с обоих сторон... Второй вариант - как-то разместить второй роутер в домашней подсети. Третий тогда уж, вытекающий из первых двух - создать на втором роутере и основную сеть для хождения в инет с первого роутера, и домашнюю подсеть первого роутера, как в режиме точки доступа...