Regras de IPTables seguras para o Corosync

5

Eu tenho dois balanceadores de carga de HA ( hollywood e wolfman ) executando o Corosync e o Pacemaker. As interfaces eth1 estão conectadas à WAN e as interfaces eth0 à LAN, usando um IP virtual como o gateway para os servidores de backend. O eth1 IP de hollywood é xxx.xxx.195.45 e o eth1 IP de wolfman é xxx.xxx.195.46 . O bindnetaddr no Corosync é xxx.xxx.195.32 , o mesmo que o endereço de rede da WAN, e a porta Corosync é a padrão 5405 .

As regras relevantes das tabelas IP nos dois servidores são:

*filter

--flush

:INPUT DROP

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

Esta configuração parece funcionar bem, mas inicialmente adicionei --in-interface eth1 e --source xxx.xxx.195.46 a wolfman e --source xxx.xxx.195.45 a hollywood . Na maioria das vezes, isso pareceu funcionar, mas a reinicialização do balanceador passivo às vezes matava a comunicação entre os balanceadores de carga, gravando esses erros no syslog:

[TOTEM ] Totem is unable to form a cluster because of an operating system or network fault. The most common cause of this message is that the local firewall is configured improperly.

Portanto, parece que minha crença simplista de que todo o tráfego do Corosync está diretamente entre os dois balanceadores de carga sobre eth1 está errado ou que algo está causando um problema.

Gostaria de bloquear a porta 5404/5405 no IPTables para apenas o cluster. O que preciso fazer para que isso aconteça?

Editar: corosync.conf conforme solicitado. Este é todo o Ubuntu padrão diferente do 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
        }
}
    
por jetboy 17.08.2012 / 16:30

2 respostas

1

Por padrão, o Corosync usa multicast IP para se comunicar entre nós:

mcastaddr: 226.94.1.1
mcastport: 5405

Configure seu firewall para permitir o tráfego multicast:

# 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

ou mude para unicast .

    
por 21.08.2012 / 06:10
1

Ao usar a comunicação multicast (o padrão para o Corosync), o tráfego IGMP deve ser permitido e os pacotes Corosync podem ser permitidos com regras muito mais específicas do que na outra resposta. As regras a seguir são suficientes (supondo que a cadeia OUTPUT não bloqueie nenhum tráfego):

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

Neste exemplo, as seguintes variáveis são assumidas como definidas:

  • $corosync_interface : a interface de rede usada pelo Corosync
  • $ip_addr_self : o endereço IP ao qual o Corosync se vincula localmente (especificado como bindnetaddr in corosync.conf )
  • $ip_addr_partner1 , $ip_addr_partner2 : os endereços IP dos outros nós do Corosync - mais podem ser adicionados se o cluster tiver mais de três nós.
  • $ip_addr_mcast : o endereço multicast usado para o Corosync (especificado como mcastaddr in corosync.conf )
  • $corosync_port : a porta (destino) usada pelo Corosync (especificada como mcastport in corosync.conf )

Em um nó, onde a interface usada pelo Corosync é uma porta que é membro de uma ponte Open vSwitch, alguns dos pacotes de multidifusão foram recebidos na interface da ponte em vez daquela que tinha o endereço IP. Portanto, eu tive que adicionar uma regra adicional que permitisse pacotes multicast nessa interface:

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

Se a cadeia OUTPUT não aceitar os pacotes por padrão, é necessário adicionar regras que permitam o tráfego IGMP e que permitam o envio de pacotes 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
    
por 30.12.2014 / 20:53