-
Posts
42 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Everything posted by kersantinov
-
Дико плюсую, просил еще года два назад...
-
Доброго дня. Хочу вернуться к своим баранам) Поведение все то-же и на 2.15.C.5.0-0 Правила на вкладке ISP режут так-же и трафик на IPSec соединении. Что вроде-бы и логично, так как отдельной вкладки для правил на IPSec соединения в межсетевом экране нет. Т.е. если прописать 2 данных правила, телефоны за IPSec отпадут, так как udp/5060 будет заблокирован, дополнительно прописываю разрешающие правила для всех подсетей за IPSec. Баг\фича?
-
Это понятно. Но задачи изолировать диапазоны друг от друга нет)
-
Конечно можно. Но хотят клиентов размазать по подсети. мух в один диапазон, котлетки в другой. Фигней страдают в общем, капризы)
-
Настроить руками что именно? CLI ругается: ip dhcp pool _WEBADMIN range 192.168.200.0 192.168.202.254 Dhcp::Pool error[983043]: size: "_WEBADMIN": range is too big, the maximum is 250 addresses.
-
Предлагаю рассмотреть возможность увеличения пула DHCP. 250 хорошо, но иногда хотелось бы использовать 23\22 подсеть.
-
Эво как всех забомбило то) Естественно в сети не 250+ девайсов. Но выдавать IP адреса хотелось бы именно из 22 подсети. Всем спасибо за сочувствие, тему можно закрыть)
-
Доброго дня. Есть гига 3. Сменилии подсеть с 24 на 22 и рассчитывали увеличить число клиентов в сети. Но наткнулись на ограничение со стороны DHCP сервера. ip dhcp pool _WEBADMIN range 192.168.200.0 192.168.202.254 Dhcp::Pool error[983043]: size: "_WEBADMIN": range is too big, the maximum is 250 addresses. Есть варианты обойти, оставшись на встроенном DHCP?
-
Обовил гигу 3 с 2.12.C.1.0-3 до 2.13.C.0.0-3 Изменилось поведение firewall. Есть ISP подключение 1, ISP подключение 2, LAN 10.10.11.0/24 и несколько IPSec ISP1 и ISP2 - старый и новый провайдеры, ISP1 сейчас отключен физически от порта. С давних времени времен есть проброс портов с ограничением по IP В переадресации на интерфейсе ISP1 tcp/9776-9786 to 10.10.11.2 В переадресации на интерфейсе ISP2 tcp/9776-9786 to 10.10.11.2 В сетевом экране интерфейсе ISP1 разрешено tcp/9776-9786 с нужного IP. В сетевом экране интерфейсе ISP1 запрещено tcp/9776-9786 с любого ардеса. (1) В сетевом экране интерфейсе ISP2 разрешено tcp/9776-9786 с нужного IP. (2) В сетевом экране интерфейсе ISP2 запрещено tcp/9776-9786 с любого ардеса. При этом раньше через ипсек я всегда мог ходить до 10.10.11.2 tcp/9776-9786 После обновления - отлуп. Для доступа через IPSec нужно прописать еще одно правило на интерфейсе ISP2, между (1) и (2), разрешающее доступ из удаленной подсети на той стороне IPSec. Это баг или фича? Может стоить дать возможность правила для тоннельных интерфейсов указывать отдельно?
-
Так и оказалось. Настройки веб-морды имеют приоритет над командой option 6 Помогает ip dhcp pool {name} dns-server disable
-
Где можно использовать IPSec с IP в качестве идентификаторов - там успешно их и используем. Проблема возникла когда появилась вторая точка с динамическим IP, поэтому и небыло там возможности использовать в качестве идентификатора IP. Селф-тест с конкретно той ситуации уже не смогу выложить, так как выбили статический IP и все успешно перенастроили. Попробую все сломать перенастроить)
-
Я понял, я больше не буду засорять форум своими проблемами с IPSec. Все проблемы из за баб из за керио, который умеет только ikev1 в качестве site-to-site, а выбор пал в его пользу из за необходимости иметь user-friendly шлюз в среде Hyper-V По теме: -приходится использовать ikev1 -кроме site-to-site Ipsec никак не используется больше. - число кинетиков в марте превысит 20 штук, страшно а я люблю подольше поспать. На самом деле ясно что в моей ситуации надо отказываться от IPSec между кинетиками и переходить на другой тип тоннелей, оставив ипсек только для керио. Изучим, подумаем, запланируем переход. Спасибо.
-
Доброго. Есть Гига 3, которая собирает на себе IPSec VPNs, есть 2 Лайт3 с белыми дин IP (IPoE) Соответсвенно на Гига3 выбрано у обоих тоннелей: Ожидать подключение от удаленного пира. На обоих лайтах впн подымается и горит зеленым. На гиге "первое" соединение горит зеленым и работает, "второе" горит красным, но по факту пинг есть c потерями с постоянными вклиниваниями Destination Unreachable. Везде 2.10.C.1.0-0 Ну и да, при установке галки Ожидать подключение от удаленного пира у меня нет возможности указать идентификатор удаленного шлюза, встает Any. Настройки 1 и 2 фазы одинаковые везде, тоннельный режим. ключи пробовал одинаковые и менять для разных пар ВПН соединений - результат одинаков. пс: пишу по памяти, выбили статический IP на одной из точек. ""
-
Все о туннелях IPIP, GRE и EoIP
kersantinov replied to Le ecureuil's topic in Обсуждение IPsec, OpenVPN и других туннелей
Я плохо слежу за roadmap видимо, упустил о возможности gre over ipsec у кинетиков) Спасибо! -
Все о туннелях IPIP, GRE и EoIP
kersantinov replied to Le ecureuil's topic in Обсуждение IPsec, OpenVPN и других туннелей
Я месседж уловил. Но на всякий случай, если вдруг будет время на костыли: в пролете остается керио(да и фиг с ним), и juniper SRX серии. И ваши же ZyWall, которые до сих пор в двух филиалах трудятся честь им и хвала. Да и дофига еще железок, которые кроме IPSec ничего не умеют. -
Все о туннелях IPIP, GRE и EoIP
kersantinov replied to Le ecureuil's topic in Обсуждение IPsec, OpenVPN и других туннелей
Ясно, понял. Будем так перебиваться) просто есть 2 ноды со специфичным продуктом, который умеет только IKEv1. Спасибо. -
Все о туннелях IPIP, GRE и EoIP
kersantinov replied to Le ecureuil's topic in Обсуждение IPsec, OpenVPN и других туннелей
Доброго дня. Хотелось бы иметь возможность маршрутизировать трафик на несколько подсетей через IPSec VPN. Трюк с маской знаю, но, как вы понимаете, далеко не всегда прокатывает. Есть ли смысл создать топик в этой ветке? Спасибо. -
Коллеги, доброго. Не могу добиться работы 6 опции DHCP сервера - хочу переопределить DNS для клиентов в консоли пишу: ip dhcp pool _WEBADMIN option 6 ascii 192.168.1.3,192.168.1.4,10.10.10.3,10.10.10.7 system configuration save Если в веб-морде прописаны ДНС для клиентов - получаем то, что прописано в веб-морде. Если в веб-морде не прописаны ДНС для клиентов - получаем в качестве DNS сервера - ip маршрутизатора: 10.10.209.1 Куда еще можно посмотреть? Проверял на Lite 3 и Giga 3 на 2.10.C.1.0-0
-
да, SNMP walk данные видит, в заббиксе community в макросах хоста переопределен. подопытная железка Keenetic Lite III Версия NDMS 2.10.C.1.0-0 Завтра на Giga III попробую.
-
Это то да, я пробовал. Но кроме ICMP Ping шаблоны ничего не обнаружили: ни интерфейсов и статистики интерфейсов, ни cpu\mem, хотя community я переопределял. Буду ковырять дальше. Спасибо.
-
Случаем шаблонов для мониторинга кинетикоd по SNMP для zabbix никто не делал? А то чет не растет кокос у меня с этими MIB и OID ами..
-
Снял дамп трафика камеры с нормально работающей гиги. И с другой гиги, с коряво работающей камеры . И там и там трафик идентичный. Выглядит примерно так, пакет в 1450 байт + хвостик. 4 0.000249 192.168.202.166 192.168.1.14 IPv4 1450 Fragmented IP protocol (proto=UDP 17, off=0, ID=be11) [Reassembled in #5] 5 0.000268 192.168.202.166 192.168.1.14 UDP 66 8320 → 63750 Len=1440 Вот только сквозь один тоннель Гига-керио он долетает, через другой - нет. UPD Изменение MTU до 1280 на интерфейсе камеры не помогло
-
Нет, через тоннель ограничние 1410 байт.
-
Речь об одной камере, а не о суммарном потоке с камер. Видео-поток вообще не воспроизводится, даже не пытается. Аудио кстати идет, только-что случайно заметил. На машине в локали - все ок. За ВПН - глухо. Причем попробовал с другого филилала зацепиться к камере - тоже видео нет, это я к тому что керио не при делах... Как проверяю - VLC. rtsp://auth@10.10.11.51:554/Streaming/Channels/1 - воспроизводит только звук rtsp://auth@10.10.11.51:554/Streaming/Channels/2 - звук и видео, все ок. upd: кстати в обратную сторону - из офиса в филиал, жирный поток проходит. И еще один момент. Ipsec же в любом случае фрагментирует большие пакеты. Значит дело не в провайдере?