Comments 21
А при чём тут аналог зарубежных межсетевых экранов и Pfsense? Или лицензия Apache2 позволяет, делаем свой форк, меняем лого и получаем зарубежный аналог?
А ннет, сел, перечитал статью:
Hidden text
Чтобы учесть потребности бизнеса, мы в Selectel решили создать собственный межсетевой экран, который не зависит от крупных вендоров. Взяли open source, собственную инфраструктуру и компетенции специалистов компании. Под катом рассказываем, как мы реализовали выгодный по цене и функционалу МЭ на выделенных серверах Selectel.
Т.е. взяли pfsense, поставили на свои виртуалки, научили своих админов какие кнопочки нажимать (применительно к собственной инфраструктуре) и назвали "собственный сетевой экран"
Ну что-то вы совсем уж обесцениваете работу с open source. Это все-таки не тетрис на мобилку поставить.
Ну на самом деле с этим и эникей справится.
Да, не тетрис, но опишите потенциального покупателя данной услуги?
Хороший сетевик - врядли: Cisco VM100, Mikrotik CHR, Palo Alto Virtual NG FW и много чего другого
Рядовой пользователь - хомячок, купивший ресурсы в облаке. Врядли даже задумывается о фаерволе.
Какой-то опытный пользователь - возможно, но для настройки Pfsense есть куча мануалов.
Я понимаю, что есть сложности с лицензирование в текущих реалиях, но Pfsense. Хотя на безрыбье и рыбу... Как-то иначе надо позиционировать данный продукт, как частичную замену современных фаерволов, но это же не так.
Как по мне позиционирование должно быть на уровне:
мы заботимся о наших клиентах
поскольку лицензий нет, предоставим opensource
есть куча мануалов (и вот тут надо подумать, как аккуратно перевести на следующий пункт)
при помощи нашего саппорта за небольшую денюжку мы вам поможем
Но заявлять о том, что это аналог зарубежных межсетевых экранов - неправильно, т.к. это и есть зарубежный межсетевой экран, пусть и доступный по лицензии Apache 2.0
А почему тогда коробочные решения находят так много покупателей, если мануалов много?(
Кажется, вы видите в этом тексте больше, чем там есть. Просто описание всех процессов, никто не скрывал, что здесь open source, и нет нигде позиционирования, что это убойный брандмауэр, который вытеснит фортигейты с рынка.
Спасибо за комментарий.
Давайте по порядку:
- Хороший сетевик будет брать другое решение.
Да, но в текущей ситуации покупка лицензий может быть невозможна либо очень затруднена, то же самое про поддержку от вендора. К тому же, как показано в сценариях использования, предлагаемое решение можно использовать на железном сервере, что в случае использования виртуального FW, вынуждало бы разворачивать гипервизор на выделенном сервере для разворачивания одной VM, если потребуется защищать сервисы, развернутые на выделенных серверах (усложнение сетевой схемы).
- Рядовой пользователь.
Для очень маленькой инфраструктуры настроек хостового межсетевого экрана может быть достаточно, но при появлении доп сетевых сервисов - лучше делать что-то отдельное.
- Какой-то опытный пользователь.
Цель статьи - не очередной мануал по pfsense)
Основная цель - предложить доступную и достойную альтернативу существующим межсетевым экранам. Понятно, что бессмысленно сравнивать предлагаемое решение с мировыми лидерами на топовом железе. Но рассмотрите решение как доступный межсетевой экран на выделенном железе с функционалом pfsense, его стабильностью работы, количеством доступной документации и возможностью масштабирования.
Все озвученные претензии легко решаются требованием на уровне законодательства приобретать лицензии исключительно на ПО из реестра Рос-что-нибудь-там.
А Pfsense точно NGFW?
«Как мы настроили pfsense» звучит более верно.
Как с поддержкой плагинов pfSense (PFS) после кастомизации?
Ведь, ценность PFS не столько в нем самом, сколько в доп. плагинах.
Если за ширмой PFS, плагины PFS, то зачем переходить на ваше решение?
У PFS большое community, можно получить бесплатную или платную поддержку.
Ваше решение - vendor lock-in на продукт, который вполне может остаться на базе PFS 2.6.
В чем ценность для народа, кроме наличия у Selectel допиленного под свои нужды PFS за деньги?
У pfsense и форк имеется - opnsense.
То есть вы просто развернули у себя pfsense, подняли на нем ovpn, ipsec и продаете на этой основе vpn-сервис. Также установили squid и squidguard + suricata\snort как idps.
А что, так можно было? (с)
P.s. У pfsense еще и wireguard есть отдельным пакетом. Можете и его "продавать")
P.p.s. Цикл заметок по работе с pfsense, proxmox etc https://forum.netgate.com/topic/163435/proxmox-ceph-zfs-pfsense-и-все-все-все-часть-2/
И как у вас в тестах ovpn и ipsec в скорости сравнялись практически?
Я к тому, что ipsec в ядре, ovpn в user space.
На данный момент скорость ограничивает только пропускная способность интерфейса. В будущем у нас будут 10G-интерфейсы, которые обеспечат еще большую скорость в VPN. Производительности выбранного конфига точно хватит.
Статья в целом хорошо оформлена, но отвязана (возможно специально) от типа используемого процессора/ов, и самое главное от связки графиков: утилизации CPU от скорости в режиме IPSec и его типов .
Уже на предоставленных графиках заметно, что утверждение "Производительности выбранного конфига точно хватит." - ошибочно. Это даже откидывая, что я, как заказчик, в силу внутренних нормативных документов, могу запросить либо самостоятельно включить использование шифрования длинным ключом (например AES-256 GCM), в соответствии с рекламным отступлением в вашей статье "Гибкая настройка протоколов шифрования и хэширования для IPSec позволяют построить туннель с различными устройствами." и... сильно растроиться. А в случае использования "выбранного конфига" МЭ в шаред режиме на несколько клиентов растроить ещё и их.
Цитата "В будущем у нас будут 10G-интерфейсы" - я предполагал, что в подобных ЦОДах всё весьма бюджетно, но после прочтенного степень повергает в тихий ужас.
И пробегаясь по статье, действительно возникла ассоциация с произведением "назад в будущее", но мы щас не о политике либо её следствиях.
Лет 10-12 назад у pf были проблемы с работой в многопоточных архитектурах, много времени утекло, может быть и решили эту проблему, но что там с тестами на 10Гбит ? Я помню проблема уже была заметна при 2.5-5Гбит транзитного трафика(т.е. по 5-10Гбит суммарно на два интерфейса) при nat трансляциях.
Ну и да, заголовок кликбейтный, я уж думал увидеть тут реализацию на dpdk, на которой многие фаерволы начали пилить как раз лет 10 назад, впрочем, и на малолитражки тоже есть спрос...
Open source, собственные серверы и экспертиза: доступный межсетевой экран для инфраструктуры в Selectel