Tráfego espúrio atingindo Keepalived

1

Usamos o Keepalived (em execução no RHEL 7) para gerenciar endereços IP compartilhados em nossos 3 servidores HAProxy. Cada servidor possui 2 interfaces, uma com um IP público e outra com um IP privado. Estamos migrando de um par de appliances Kemp LoadMaster LM-3000.

Percebemos que dois dos três sistemas HAProxy estão registrando muitas linhas a cada segundo para bogus VRRP packet received on em2 !!! .

Este é um segundo de registros. Eu cortei os tempos e processei números para economizar espaço.

haproxy01 Keepalived_vrrp: VRRP_Instance(haproxy::fqdn) IPSEC-AH : invalid IPSEC HMAC-MD5 value. Due to fields mutation or bad password !
haproxy01 Keepalived_vrrp: bogus VRRP packet received on em2 !!!
haproxy01 Keepalived_vrrp: VRRP_Instance(haproxy::fqdn) ignoring received advertisment...
haproxy00 Keepalived_vrrp: VRRP_Instance(haproxy::device) IPSEC-AH : invalid IPSEC HMAC-MD5 value. Due to fields mutation or bad password !
haproxy00 Keepalived_vrrp: bogus VRRP packet received on em2 !!!
haproxy00 Keepalived_vrrp: VRRP_Instance(haproxy::device) ignoring received advertisment...
haproxy00 Keepalived_vrrp: VRRP_Instance(haproxy::support) IPSEC-AH : invalid IPSEC HMAC-MD5 value. Due to fields mutation or bad password !
haproxy00 Keepalived_vrrp: bogus VRRP packet received on em2 !!!
haproxy00 Keepalived_vrrp: VRRP_Instance(haproxy::support) ignoring received advertisment...
haproxy00 Keepalived_vrrp: VRRP_Instance(haproxy::whiffle) IPSEC-AH : invalid IPSEC HMAC-MD5 value. Due to fields mutation or bad password !
haproxy00 Keepalived_vrrp: bogus VRRP packet received on em2 !!!
haproxy00 Keepalived_vrrp: VRRP_Instance(haproxy::whiffle) ignoring received advertisment...
haproxy00 Keepalived_vrrp: VRRP_Instance(haproxy::www) IPSEC-AH : invalid IPSEC HMAC-MD5 value. Due to fields mutation or bad password !
haproxy00 Keepalived_vrrp: bogus VRRP packet received on em2 !!!
haproxy00 Keepalived_vrrp: VRRP_Instance(haproxy::www) ignoring received advertisment...
haproxy00 Keepalived_vrrp: VRRP_Instance(haproxy::wwwdev) IPSEC-AH : invalid IPSEC HMAC-MD5 value. Due to fields mutation or bad password !
haproxy00 Keepalived_vrrp: bogus VRRP packet received on em2 !!!
haproxy00 Keepalived_vrrp: VRRP_Instance(haproxy::wwwdev) ignoring received advertisment...

haproxy02 não registra nenhum tráfego estranho.

  • haproxy00.example.com : em1 -> 172.24.0.200 , em2 -> 192.0.2.32
  • haproxy01.example.com : em2 -> 172.24.0.201 , em1 -> 192.0.2.29
  • haproxy02.example.com : em1 -> 172.24.0.202 , em2 -> 192.0.2.24
  • kemp00.example.com : em1 -> 172.24.0.48 , em2 -> 192.0.2.59
  • kemp01.example.com : em1 -> 172.24.0.49 , em2 -> 192.0.2.60
  • "Flutuante" kemp.example.com : 172.24.0.50
  • "Flutuante" kemp-public.example.com : 192.0.2.63

Observe que haproxy01 tem em1 e em2 invertidos em comparação com os outros dois.

Os sistemas haproxy* estão configurados para usar o VRRP unicast em vez do multicast (a amostra da configuração de haproxy00 os outros são exatamente os mesmos, exceto pelo nome alterado da interface para haproxy01 e uma prioridade diferente. haproxy02 é o MASTER ):

vrrp_instance haproxy::fqdn {
  interface                 em1
  state                     BACKUP
  virtual_router_id         199
  priority                  100
  advert_int                1
  garp_master_delay         5
  authentication {
    auth_type AH
    auth_pass csvrp199
  }
  virtual_ipaddress {
    172.24.0.199/24 dev em1
  }
  virtual_routes {
      metric 5 to default via 172.24.0.1
  }
  unicast_src_ip 172.24.0.200
  unicast_peer {
    172.24.0.201
    172.24.0.202
  }
}
vrrp_instance haproxy::device {
  interface                 em2
  state                     BACKUP
  virtual_router_id         15
  priority                  100
  advert_int                1
  garp_master_delay         5
  authentication {
    auth_type AH
    auth_pass csvrrp15
  }
  virtual_ipaddress {
    192.0.2.7/26 dev em2
  }
  virtual_routes {
      metric 5 to default via 192.0.2.1
  }
  unicast_src_ip 192.0.2.32
  unicast_peer {
    192.0.2.24
    192.0.2.29
  }
}
vrrp_instance haproxy-csweb:haproxy::support { ... }
vrrp_instance haproxy-csweb:haproxy::whiffle { ... }
vrrp_instance haproxy-csweb:haproxy::www { ... }
vrrp_instance haproxy-csweb:haproxy::wwwdev { ... }

Sabemos que o VRRP está funcionando entre os sistemas haproxy , porque podemos desligar haproxy02 e o tráfego se move para o próximo sistema de maior prioridade.

tcpdump mostra o tráfego que pensamos estar causando esse problema. O addrs anunciado de um LM para o outro parece ser ofuscado de alguma forma, uma vez que nenhum deles são nossos endereços reais.

[root@haproxy00 ~]# tcpdump -vvvvvni em2 vrrp
tcpdump: listening on em2, link-type EN10MB (Ethernet), capture size 262144 bytes
13:54:09.672726 IP (tos 0x10, ttl 255, id 51772, offset 0, flags [DF], proto VRRP (112), length 56)
    192.0.2.59 > 224.0.0.18: vrrp 192.0.2.59 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 1, authtype none, intvl 1s, length 36, addrs(7): 127.73.197.82,124.192.126.111,231.25.226.215,113.220.143.181,197.101.63.203,152.246.226.65,46.55.62.80

[root@haproxy01 ~]# tcpdump -vvvvvni em2 vrrp
tcpdump: listening on em2, link-type EN10MB (Ethernet), capture size 262144 bytes
13:54:36.739262 IP (tos 0x10, ttl 255, id 50547, offset 0, flags [DF], proto VRRP (112), length 56)
    172.24.0.48 > 224.0.0.18: vrrp 172.24.0.48 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 1, authtype none, intvl 1s, length 36, addrs(7): 120.18.52.8,8.96.198.173,44.237.204.205,99.139.163.15,10.76.116.67,163.0.175.114,121.54.183.104

Portanto, os erros são registrados em em2 de cada servidor para cada vrrp_instance , mas não para as instâncias em em1 e também não em haproxy02 .

Estamos tentando impedir esses erros que estão sendo registrados porque eles ocultam erros mais importantes e impossibilitam a entrada dos arquivos de log.

Separadamente, também temos iptables , o que eu acho que deveria estar bloqueando o tráfego multicast, mas não parece ser:

[root@haproxy00 ~]# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            /* 000 accept all icmp */
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            /* 001 accept all to lo interface */
REJECT     all  --  0.0.0.0/0            127.0.0.0/8          /* 002 reject local traffic not on loopback interface */ reject-with icmp-port-unreachable
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            /* 003 accept related established rules */ state RELATED,ESTABLISHED
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
ACCEPT     tcp  --  172.16.0.0/12        0.0.0.0/0            multiport dports 22 /* 203 allow internal sshd:22 */ state NEW
ACCEPT     112  --  192.0.2.24           0.0.0.0/0            /* 226 Allow vrrp from 192.0.2.24 */
ACCEPT     112  --  192.0.2.29           0.0.0.0/0            /* 226 Allow vrrp from 192.0.2.29 */
ACCEPT     112  --  172.24.0.201         0.0.0.0/0            /* 226 Allow vrrp from 172.24.0.201 */
ACCEPT     112  --  172.24.0.202         0.0.0.0/0            /* 226 Allow vrrp from 172.24.0.202 */
DROP       all  --  0.0.0.0/0            0.0.0.0/0            /* 999 drop all */

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
    
por yakatz 06.03.2018 / 02:24

0 respostas