Правила IP-таблиц Corosync и Pacemaker

Question 1

При использовании Corosync с двумя кольцами через многоадресные адреса 226.94.1.1 (порт 5405) и 226.94.1.2 (порт 5406) какие правила iptables требуются, чтобы два узла могли взаимодействовать оптимально, не предоставляя ненужный доступ и не устанавливая правила слишком снисходительный?

У меня сейчас есть:

iptables -A INPUT -p udp -m multiport --dports 5404,5405,5406 -j ACCEPT

Будет ли это разрешать все коммуникации, которые требуются для установки Corosync / Pacemaker для обоих колец?

Я слышал аргументы, что что-то как:

iptables -I INPUT 1 -m pkttype --pkt-type multicast -j ACCEPT

требуется. Однако я не могу воспроизвести ситуацию, когда это помогает, если первое правило, которое я перечислил выше, уже действует.

Документация Red Hat, кажется, поддерживает первый подход. Есть некоторая документация IBM, поддерживающая второе, но разве это просто случай правила, которое слишком мягкое, когда первое будет выполнять работу одинаково хорошо, не оставляя ненужных открытых портов?

Я больше склоняюсь к первое правило было достаточным, но хотелось получить больше мнений по этому вопросу.

Question 2

Документация от Red Hat и IBM указывает правила, которые на самом деле позволяют больше пакетов, чем действительно необходимо.

Многоадресные пакеты IP действительно не очень отличаются от одноадресных пакетов IP, единственная разница (в дополнение к пути, как они отправляются на Уровне 2 и направляются), адрес назначения, который должен быть в диапазоне 224.0.0.0/4.

Как описано на Отказе сервера, следующие правила могут использоваться для единственного кольца 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)

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

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

Community · Answer 1 · 3 March 2014 в 07:57