Кластер высокой доступности или отказоустойчивость в OPNSense

Print Friendly, PDF & Email

Задача:

Настроить отказоустойчивый кластер высокой доступности на двух файрволах OPNSense, один из которых является виртуальной машиной среды ESXi

---------------------------------------------------------------
Статья пережила несколько редакций, тестировал настраиваемое на протяжении нескольких дней и в процессе произошло несколько изменений. Поэтому в дальнейшем считайте указанные ниже изменения равными:
- 192.168.178.111 = 192.168.178.254
- 192.168.17.111 = 192.168.17.254
- pfSync = HA

Резервирование OPNSense основано на нескольких технологиях:

  • CARPCommon Address Redundancy Protocol, протокол объединения группы маршрутизаторов в один виртуальный маршрутизатор путём назначения им общего IP-адреса. Аналогично с протоколом транспортного уровня VRRP (Virtual Router Redundancy Protocol) используется протокол IP 112. Для передачи информации о текущем состоянии OPNSense другим участникам сети кластера, используются multicast (мультикаст) пакеты.
  • pfsync – это протокол обеспечивающий высокую доступность, используется для синхронизации состояний брандмауэра между машинами, на которых запущен фильтр пакетов PF. Применяется вместе с протоколом CARP. Pfsync гарантирует, что информация на обоих (основной и резервный) межсетевых экранах будет одинакова. Если основной файрвол в кластере выходит из строя, резервная машина может продолжить принимать текущие соединения без потерь.
  • XMLRPC synceXtensible Markup Language Remote Procedure Call, стандарт/протокол вызова удалённых процедур, использующий XML для кодирования своих сообщений и HTTP в качестве транспортного механизма. Нужен для синхронизации конфигурации (настроек файрволов)

В идеале оба брандмауэра должны использовать одинаковые обозначения интерфейсов для одних и тех же сетей. Например, если внутренняя сеть (LAN) на первом устройстве подключена через интерфейс vmx1, аналогично должно быть и на втором OPNSense.
В нашем случае, так как используем физическое и виртуальное устройства, получаем ряд отличий:

OPNSense 1 – gwmOPNSense 2 -gws
LANvmx0em3
WANvmx1em2
pfSyncacl0em0

С разными сетевыми картами и следовательно именами интерфейсов, можно настроить LAGG как обходной путь. LAGG позволяет агрегировать (объединять) каналы, такое объединение позволяет увеличивать пропускную способность и надежность канала. Добавлять можно только неназначенные интерфейсы.

Ещё из ограничений, для pfSync рекомендуется использовать выделенный интерфейс на обоих брандмауэрах, это увеличит безопасность (отсутствует вариант внедрения в состояние) и производительность. VLAN придёт вам на помощь, если отсутствует возможность выделить отдельный физический интерфейс

И так, мы определили что, OPNSense способен работать в режиме кластера высокой доступности (High Availability Cluster) и что для этого необходимо использовать.

Будем реализовать сеть с картинки:

Для локальной сети, вы можете использовать следующие диапазоны сетевых адресов:

  • 10.10.0.0 – 10.255.255.255 — сеть класса A с возможностью до 16121856 хостов.
  • 172.16.0.0 – 172.31.255.255 — сеть класса B, можно использовать до 1048576 хостов.
  • 192.168.0.0 – 192.168.255.255 — сеть класса C, возможно до 65536 хостов.
  • Так же существуют петлевые интерфейсы с интервалом адресов 127.0.0.0 — 127.255.255.255, которые не используются для обмена между узлами сети.

Останавливаться на этом не буду, все подробно описаны в “RFC1918 — Address Allocation for Private Internets” (RFC 1918 — Распределение адресов для частного интернета)

Возвращаясь к особенности реализуемого варианта состоящую в том, что отказоустойчивость будет настраиваться между виртуальной и физической машинами. Для этого виртуальной машине должно быть разрешено изменять MAC-адреса. Это требуется для использования протокола общего резервирования адресов (CARP). Открываем веб-интерфейс ESXi и настрайваем в Security policy:

  • Allow forged transmits -> Yes
  • Allow MAC changes -> Yes
  • Allow promiscuous mode -> Yes (Активируем если будут возникать проблемы в работе, или можете активировать сразу. Он аналогичен параметру “Неразборчивый режим” из статьи “High Availability OPNsense в виртуальной среде VirtualBox“)

На всякий случай аналогичная настройка для среды Hyper-V.

Все настройки буду проводить на файрволах, где были привязаны интерфейсы и настроен NAT. Советую сразу изменить имена файрволов. Можно сделать на этапе начальной настройки, при помощи wizard (помощника по настройке)

Или в меню: System > Settings > General

Это касалось предварительных настроек.

Настраиваем главный маршрутизатор OPNSense, на карте сети он отмечен как Master (GWM).

Добавляем виртуальные WAN (внешний) IP-Адрес: Interfaces > Virtual IPs > Settings

  • Режим: CARP
  • Интерфейс: WAN
  • Адрес: 192.168.17.111/24
  • Виртуальный пароль: генерируем пароль до 30 символов, который используется для аутентификации CARP сообщений.

Для генерации пароля из консоли компьютера Linux или FreeBSD, можно воспользоваться одним из вариантов:

$ cat /dev/random | hexdump -n 30| cut -d \  -f 2-| head -n 1 | tr -d " "
56fad049e589a76b6115ae5f61f204fc
$ openssl rand -base64 30
HP9qydg3Aydi4kVyPJ3PHNdSogq8LVYH4GVDmeRQ
  • VHID Группа: Virtual Host ID необходим для идентификации хостов, имеющих подключение в одном сегменте сети. В нашем случае необходимо на обоих OPNSensen указать один и тот же VHID. Также, это число используется как последний октет (6th octets) MAC-адреса для виртуального IP-адреса. В нашём случае, получится 00:00:5e:00:01:01
  • Advertising Frequency Base (advbase) – частота рассылки CARP-сообщения.
  • Advertising Frequency Skew (advskew) – 0 определяет мастер устройство в группе.Чем больше число, тем меньший приоритет оно имеет. Необходимо для определения хоста, который в случае выхода из строя мастер-устройства, подменить его.

Настройки для локальной сети (LAN).

Всё по аналогии, за исключением Virtual Host ID. Установив VHID 3, мы определяем MAC-адрес как 00:00:5e:00:01:03

Должно получиться два виртуальных интерфейса. Если вы переезжаете, к примеру, на новое оборудование, то для LAN интерфейса можно добавить “IP Alias” старого маршрутизатора. Это предотвратит пропажу интернета на устройствах где прописаны статические сетевые настройки. После настройки и вворода нового оборудования в эксплуатацию, можно при помощи tcpdump отследить устройства обращающиеся к алиасу и перенастроить на новый шлюз.

Настраиваем исходящие правила NAT. Выбираем “Manual outbound NAT rule generation” и сохраняем.

Manual outbound NAT rule generation
(no automatic rules are being generated)

Кнопкой “Add” добавляем новое правило

Настраиваем согласно картинки ниже.

Если вы используете OPNSense как DHCP сервер в локальной сети, то следует учесть некоторые особенности. Все клиенты должны использовать виртуальный адрес вместо физического адреса DHCP сервера. Также следует знать, что одновременно будут активны два сервера (Dynamic Host Configuration Protocol — протокол динамической настройки узла), которые должны знать пулы друг друга. Аналогично для DNS сервера. Все запросы из локальной сети должны быть адресованы виртуальному адресу. Убедитесь, что DHCP-сервер отдаёт правильный IP-адрес.

Если коротко:

  • DNS servers: 192.168.17.254
  • Gateway: 192.168.17.254
  • Failover peer IP: 192.168.17.109

На обоих файрволах необходимо добавить правило для HA (pfSync), которое разрешает любой трафик в этой сети. Добавляем кнопкой “Add” новое правило для интерфейса “HA” и сразу же сохраняем. Должно получится правило разрешающее всё.

Оба OPNSensen должны иметь одинакового пользователя для синхронизации. Советую завести отдельного пользователя с правами администратора, дать ему соответствующее имя и забыть про его существование.

Ну и наконец, настраиваем High Availability

на втором практически аналогичные настройки. Настройки раздела “Configuration Synchronization Settings (XMLRPC Sync)” оставляем пустыми.

После сохранения сразу можно проверить статус (показывается только на главном файрволе)

На “Dashboard” можно добавить соответствующий виджет

На втором (резервном) OPNsensen должен быть статус “Backup”. Он изменится на “Master” , если главный файрвол выйдет из строя или будет выключен.

В заключении настройки стоит упомянуть о настройках из официальных источников. В документации указано, что протоколы используемые для работы кластера могут использоваться на разных интерфейсах, поэтому для WAN и LAN интерфейсов стоит разрешить протокол CARP. У меня работает без этого, хотя настроит наверно стоило бы.

Для теста я выключил главный файрвол. Ниже логи со второго OPNsensen в моменты переключения со SLAVE на MASTER и обратно

root@GWS:~ # clog -f /var/log/system.log
Jan 11 23:19:33 OPNsense kernel: carp: 3@em0: BACKUP -> MASTER (master timed out                                   )
Jan 11 23:19:33 OPNsense kernel: carp: 1@em1: BACKUP -> MASTER (master timed out                                   )
Jan 11 23:19:34 OPNsense opnsense[58902]: /usr/local/etc/rc.syshook.d/carp/20-op                                   envpn: Carp cluster member "192.168.17.254 - LAN Virtual IP (3@em0)" has resumed                                    the state "MASTER" for vhid 3
Jan 11 23:19:34 OPNsense opnsense[58902]: /usr/local/etc/rc.syshook.d/carp/20-op                                   envpn: Resyncing OpenVPN instances for interface 192.168.17.254 - LAN Virtual IP                                   .
Jan 11 23:19:34 OPNsense opnsense[89404]: /usr/local/etc/rc.syshook.d/carp/20-op                                   envpn: Carp cluster member "192.168.178.254 - WAN Virtual IP (1@em1)" has resume                                   d the state "MASTER" for vhid 1
Jan 11 23:19:34 OPNsense opnsense[89404]: /usr/local/etc/rc.syshook.d/carp/20-op                                   envpn: Resyncing OpenVPN instances for interface 192.168.178.254 - WAN Virtual I                                   P.
Jan 11 23:21:12 OPNsense kernel: em2: link state changed to DOWN
Jan 11 23:21:12 OPNsense opnsense[97933]: /usr/local/etc/rc.linkup: Hotplug event detected for HA(opt1) but ignoring since interface is configured with static IP (10.168.17.109 ::)
Jan 11 23:21:14 OPNsense kernel: em2: link state changed to UP
Jan 11 23:21:15 OPNsense opnsense[82514]: /usr/local/etc/rc.linkup: Hotplug event detected for HA(opt1) but ignoring since interface is configured with static IP (10.168.17.109 ::)
Jan 11 23:21:15 OPNsense opnsense[13685]: /usr/local/etc/rc.newwanip: IPv4 renewal is starting on 'em2'
Jan 11 23:21:15 OPNsense opnsense[13685]: /usr/local/etc/rc.newwanip: On (IP address: 10.168.17.109) (interface: HA[opt1]) (real interface: em2).
Jan 11 23:21:15 OPNsense opnsense[13685]: plugins_configure hosts ()
Jan 11 23:21:15 OPNsense opnsense[13685]: plugins_configure hosts (execute task : dnsmasq_hosts_generate())
Jan 11 23:21:15 OPNsense opnsense[13685]: plugins_configure hosts (execute task : unbound_hosts_generate())
Jan 11 23:21:24 OPNsense kernel: em2: link state changed to DOWN
Jan 11 23:21:25 OPNsense opnsense[46530]: /usr/local/etc/rc.linkup: Hotplug event detected for HA(opt1) but ignoring since interface is configured with static IP (10.168.17.109 ::)
Jan 11 23:21:27 OPNsense kernel: em2: link state changed to UP
Jan 11 23:21:27 OPNsense opnsense[41185]: /usr/local/etc/rc.linkup: Hotplug event detected for HA(opt1) but ignoring since interface is configured with static IP (10.168.17.109 ::)
Jan 11 23:21:28 OPNsense opnsense[89186]: /usr/local/etc/rc.newwanip: IPv4 renewal is starting on 'em2'
Jan 11 23:21:28 OPNsense opnsense[89186]: /usr/local/etc/rc.newwanip: On (IP address: 10.168.17.109) (interface: HA[opt1]) (real interface: em2).
Jan 11 23:21:28 OPNsense opnsense[89186]: plugins_configure hosts ()
Jan 11 23:21:28 OPNsense opnsense[89186]: plugins_configure hosts (execute task : dnsmasq_hosts_generate())
Jan 11 23:21:28 OPNsense opnsense[89186]: plugins_configure hosts (execute task : unbound_hosts_generate())
Jan 11 23:21:51 OPNsense kernel: carp: 1@em1: MASTER -> BACKUP (more frequent advertisement received)
Jan 11 23:21:51 OPNsense kernel: em1: deletion failed: 3
Jan 11 23:21:52 OPNsense opnsense[74049]: /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "192.168.178.254 - WAN Virtual IP (1@em1)" has resumed the state "BACKUP" for vhid 1
Jan 11 23:21:52 OPNsense opnsense[74049]: /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface 192.168.178.254 - WAN Virtual IP.
Помогла статья? Есть возможность отблагодарить автора

QR Link:

QR Code

Вам может также понравиться...

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *