21/09/2019
Pfsense – отличные опенсорсные межсетевые экраны. Я писал в своем блоге уже о них в статье “Сложный NAT на pfsense”. В их процессе эксплуатации возникает ряд нюансов, про которые лучше знать заранее. И, учитывая их, заблаговременно планировать свою инфраструктуру. Между тем, виртуализация вычислительных ресурсов под управлением систем VMware преобладает в современном IT мире. С моей точки зрения и опыта, другие системы виртуализации не дают таких возможностей, а также удобства в работе. Все что написано в этой статье, почерпнуто из опыта работы на продуктах Vsphere. Тем не менее, я думаю, что это будет полезно, даже если Вы используете pfsense и в других виртуальных средах.
В статье расскажу о том, как избежать некоторых неприятных нюансов при работе с межсетевыми экранами pfsense. Это касается добавления новых сетевых интерфейсов в наш фаервол. Как оказалось это не совсем тривиальная задача. Потом затрону проблему с измененим очередности виртуальных сетевых интерфейсов после перенастройки фаервола. Также рассмотрим простоту и удобство кластеризации pfsense. И затронем проблему, которая возникает если в Вашей сети или сети Вашего провайдера работает также протокол VRRP.
Добавление новых сетевых интерфейсов
В процессе работы возникает иногда необходимость подключения новых подсетей к межсетевым экранам. Вроде бы обыденная задача. К тому же в виртуализированной среде. С учетом того, что pfsense работает на ядре FreeBSD, которое поддерживает горячее добавление сетевых устройств, проблем казалось бы не должно быть. Однако, на практике все оказывается немного по-другому. Автоматическое добавление виртуальных NIC не срабатывает. То есть, в интерфейсе VMware добавление нового сетевого интерфейса проходит успешно. Однако операционная система фаервола этого интерфейса никак не видит. Как ни странно перезагрузка системы проблему нисколько не решает.
Решение данной проблемы следующее. Для успешного добавления виртуального NIC в наш межсетевой экран, нужно сперва выключить его. Потом на не работающем pfsense настроить новую сетевую карточку в интерфейсе VMware. После этого включить. И вуаля мы достигнем желаемого результата.
Изменение очередности сетевых интерфейсов после реконфигурации
После того, как мы добавили новые виртуальные NIC в нашем межсетевом экране, мы столкнемся с еще одной проблемой. Очередность сетевых интерфейсов, после такой модернизаии поменяется. А с учетом того, что привязка направления сетевого сегмента в pfsense происходит с номером сетевого интерфейса, то происходит потеря работоспособности нашего межсетевого экрана. То есть, если до модернизации WAN у нас был привязан к vmx0, то после перезагрукзи vmx0 может быть уже NIC, который смотрит в LAN. Путем несложных умозаключений с учетом данных о MAC адресах, производим перенастройку привязки сетевых устройств (vmx0, vmx1 и т.д.). После этого наш фаервол начнет работать в нормальном режиме. Однако, тут надо не забыть, что в системе мониторинга после всего этого произойдет также смена интерфейсов. Соответственно, например, внешний трафик в системе мониторинга будет отображаться в статистике уже другого физического интерфейса.
Обобщив написанное, хотелось бы посоветовать более тщательно планировать внедрение и использование межсетевых экранов в своей виртуальной среде. Это позволит свести к минимуму лишние манипуляции и проблемы в процессе эксплуатации.
Кластеризация pfsense
Работа пары виртуальных pfsense в одном кластере – дело не слишком хитрое. Но построив кластер, вы получите реально отказоустойчивый солюшен, который ничем не уступает коммерческим продуктам от Cisco или CheckPoint. Два межсетевых экрана способны обмениваться текущими состояниями сессий, которые проходят через них. Это позволяет довольно таки быстро восстановить прохождение трафика, в случае проблем на основной ноде межсетевого экрана. Реальные примеры показывают пропадание одного-двух пингов при срабатывания механизма high availability кластера.
Вообщем, всем рекомендую, в продакшене использовать именно пару нод pfsense в кластере. Это сэкономит Вам нервы и средства в случаях возникновения каких-либо проблем с одной из нод. А также сильно поможет при необходимости каких-либо серьезных перенастроек межсетевого экрана.
Конфликт CARP и VRRP
Протокол CARP используется системой FreeBSD, которая лежит в основе pfsense, для создания отказоустойчивости на уровне сети. То есть несколько устройств с FreeBSD используют этот протокол для выбора мастер ноды. Именно она используется для обработки трафика, который генерируется в данном сегменте сети. Но у протокола CARP есть один большой недостаток. Он не признан IANA и использует тот же номер протокола, что и VRRP. Так же это отностися к формату MAC адреса, который использется протоколами CARP и VRRP. Поэтому если в этом сегменте сети есть пара маршрутизаторов, которые задействуют VRRP в своей работе, то возможны конфликты работы протокола сетевой отказоустойчивости.
Для того, чтобы избежать данной проблемы, рекомендуется использовать номер группы CARP в нестандартном дипазоне. Этот номер не должен совпасть с номером VRRP группы, который может использоваться в этом участке сети. Например, указать этот параметр 215 или 187. Также использовать при настройке CARP группы сложный пароль. Две этих настройки позволят Вам избежать конфликтных ситуаций при работе CARP и VRRP в одном сегменте сети.
Заключение
В этой статье затронул несколько практических моментов, с которыми придется столкнуться любому администратору при работе с pfsense в среде VMware. При этом, текущие версии ПО pfsense на данный момент – 5.4.4, а VMware vSphere – 6.7. Надеюсь, что данный материал будет полезен читателям моего блога.
