Назад | Перейти на главную страницу

Правила Secure IPTables для Corosync

У меня два балансировщика нагрузки HA (hollywood и wolfman) под управлением Corosync и Pacemaker. В eth1 интерфейсы подключены к WAN, а eth0 взаимодействует с локальной сетью, используя виртуальный IP-адрес в качестве шлюза для внутренних серверов. В eth1 IP из hollywood является xxx.xxx.195.45, а eth1 IP из wolfman является xxx.xxx.195.46. В bindnetaddr в Corosync есть xxx.xxx.195.32, то же самое, что и сетевой адрес WAN, а порт Corosync по умолчанию 5405.

Соответствующие правила IP-таблиц на обоих серверах:

*filter

--flush

:INPUT DROP

--append INPUT --protocol udp --destination-port 5404 --jump ACCEPT
--append INPUT --protocol udp --destination-port 5405 --jump ACCEPT

Кажется, эта настройка работает нормально, но сначала я добавил --in-interface eth1 и --source xxx.xxx.195.46 к wolfman, и --source xxx.xxx.195.45 к hollywood. В большинстве случаев это работало, но перезагрузка пассивного балансировщика иногда приводила к прерыванию связи между балансировщиками нагрузки, записывая эти ошибки в системный журнал:

[TOTEM] Totem не может сформировать кластер из-за сбоя операционной системы или сети. Наиболее частая причина появления этого сообщения - неправильная настройка локального брандмауэра.

Таким образом, похоже, что либо мое упрощенное убеждение, что весь трафик Corosync находится непосредственно между двумя балансировщиками нагрузки, либо eth1 неправильно, или что-то другое вызывает проблему.

Я хочу заблокировать порт 5404/5405 в IPTables до кластера. Что мне нужно сделать, чтобы это произошло?

Редактировать: corosync.conf как просили. Все это Ubuntu по умолчанию, кроме bindnetaddr.

# Please read the openais.conf.5 manual page

totem {
        version: 2

        # How long before declaring a token lost (ms)
        token: 3000

        # How many token retransmits before forming a new configuration
        token_retransmits_before_loss_const: 10

        # How long to wait for join messages in the membership protocol (ms)
        join: 60

        # How long to wait for consensus to be achieved before starting a new round of membership configuration (ms)
        consensus: 3600

        # Turn off the virtual synchrony filter
        vsftype: none

        # Number of messages that may be sent by one processor on receipt of the token
        max_messages: 20

        # Limit generated nodeids to 31-bits (positive signed integers)
        clear_node_high_bit: yes

        # Disable encryption
        secauth: off

        # How many threads to use for encryption/decryption
        threads: 0

        # Optionally assign a fixed node id (integer)
        # nodeid: 1234

        # This specifies the mode of redundant ring, which may be none, active, or passive.
        rrp_mode: none

        interface {
                # The following values need to be set based on your environment
                ringnumber: 0
                bindnetaddr: xxx.xxx.195.32
                mcastaddr: 226.94.1.1
                mcastport: 5405
        }
}

amf {
        mode: disabled
}

service {
        # Load the Pacemaker Cluster Resource Manager
        ver:       0
        name:      pacemaker
}

aisexec {
        user:   root
        group:  root
}

logging {
        fileline: off
        to_stderr: yes
        to_logfile: no
        to_syslog: yes
        syslog_facility: daemon
        debug: off
        timestamp: on
        logger_subsys {
                subsys: AMF
                debug: off
                tags: enter|leave|trace1|trace2|trace3|trace4|trace6
        }
}

При использовании многоадресной связи (по умолчанию для Corosync) трафик IGMP должен быть разрешен, а пакеты Corosync могут быть разрешены с правилами, которые намного более конкретны, чем в другом ответе. Достаточно следующих правил (при условии, что OUTPUT цепочка не блокирует трафик):

iptables -A INPUT -p igmp -i $corosync_interface -j ACCEPT
for src_addr in $ip_addr_self $ip_addr_partner1 $ip_addr_partner2; do
  iptables -A INPUT -i $corosync_interface -s $src_addr -d $ip_addr_self \
    -p udp --source-port $(($corosync_port - 1)) \
    --destination-port $corosync_port -j ACCEPT
  iptables -A INPUT -i $corosync_interface -s $src_addr -d $ip_addr_mcast \
    -p udp --source-port $(($corosync_port - 1)) \
    --destination-port $corosync_port -j ACCEPT
done

В этом примере предполагается, что определены следующие переменные:

  • $corosync_interface: сетевой интерфейс, который используется Corosync.
  • $ip_addr_self: IP-адрес, к которому Corosync привязывается локально (указывается как bindnetaddr в corosync.conf)
  • $ip_addr_partner1, $ip_addr_partner2: IP-адреса других узлов Corosync - можно добавить больше, если в кластере более трех узлов.
  • $ip_addr_mcast: многоадресный адрес, используемый для Corosync (указанный как mcastaddr в corosync.conf)
  • $corosync_port: порт (назначения), используемый Corosync (указанный как mcastport в corosync.conf)

На одном узле, где интерфейс, используемый Corosync, является портом, который является членом моста Open vSwitch, некоторые из многоадресных пакетов были получены на интерфейсе моста вместо того, который имел IP-адрес. Поэтому мне пришлось добавить дополнительное правило, разрешающее многоадресные пакеты на этом интерфейсе:

for src_addr in $ip_addr_self $ip_addr_partner1 $ip_addr_partner2; do
  iptables -A INPUT -i $bridge_interface -s $src_addr -d $ip_addr_mcast -p udp --source-port $(($corosync_port - 1)) --destination-port $corosync_port -j ACCEPT
done

Если OUTPUT chain не принимает пакеты по умолчанию, необходимо добавить правила, разрешающие трафик IGMP и позволяющие отправлять пакеты Corosync:

iptables -A OUTPUT -p igmp -o $corosync_interface -j ACCEPT
for dst_addr in $ip_addr_self $ip_addr_mcast $ip_addr_partner1 $ip_addr_partner2; do
  iptables -A OUTPUT o $corosync_interface -s $ip_addr_self -d $dst_addr \
    -p udp --source-port $(($corosync_port - 1)) \
    --destination-port $corosync_port -j ACCEPT
done

По умолчанию Corosync использует многоадресную рассылку IP для связи между узлами:

mcastaddr: 226.94.1.1
mcastport: 5405

Либо настройте свой брандмауэр, чтобы разрешить многоадресный трафик:

# iptables -A INPUT -p igmp -j ACCEPT
# iptables -A INPUT -m addrtype --dst-type MULTICAST -j ACCEPT

# iptables -A INPUT -p udp -m state --state NEW -m multiport --dports 5404,5405 -j ACCEPT

или переключитесь на одноадресная передача.