Portas HTTP são filtradas em novos IPs virtuais no balanceador de carga LVS (Linux Virtual Server)

Question

Eu herdei um balanceador de carga Linux Virutal Server (LVS) no CentOS 5.10. Tem sido executado sem problemas por algum tempo sem preocupações.

Agora, quando eu adiciono um novo IP virutal (VIP), todo o tráfego HTTP é "filtrado" para essa porta.

Por exemplo: Aqui está a saída do nmap para um VIP existente:

nmap 10.150.200.141
Starting Nmap 5.51.6 ( http://nmap.org ) at 2014-10-13 14:55 EDT
Nmap scan report for 10.150.200.141
Host is up (0.014s latency).
Not shown: 995 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
111/tcp  open  rpcbind
443/tcp  open  https
1556/tcp open  veritas_pbx
Nmap done: 1 IP address (1 host up) scanned in 0.28 seconds

E aqui está a saída do nmap para um VIP que acabei de adicionar:

nmap -Pn 10.150.200.47
Starting Nmap 5.51.6 ( http://nmap.org ) at 2014-10-13 14:58 EDT
Nmap scan report for 10.150.200.47
Host is up (0.011s latency).
Not shown: 995 closed ports
PORT     STATE    SERVICE
22/tcp   open     ssh
80/tcp   filtered http
111/tcp  open     rpcbind
443/tcp  filtered https
1556/tcp open     veritas_pbx
Nmap done: 1 IP address (1 host up) scanned in 1.31 seconds

Devo observar que a configuração do novo VIP é uma cópia do VIP original; Acabei de mudar o nome, eth0 e IP.

Outra coisa a notar é que os servidores reais do novo VIP estavam anteriormente no VIP original e funcionavam bem lá. Agora eu só preciso dividi-los em um VIP próprio para testes.

Eu tentei outro VIP novo com um servidor real diferente (não relacionado aos mencionados anteriormente) e obtive o mesmo resultado.

Atualizando com a saída do iptables:

/sbin/iptables -L --line -n -v
Chain INPUT (policy ACCEPT 106M packets, 16G bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 107M packets, 16G bytes)
num   pkts bytes target     prot opt in     out     source               destination

Atualizando com saída ipvsadm:

ipvsadm -L -n -t 10.150.200.47:80
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.150.200.47:80 wlc
  -> 10.150.200.247:80            Route   50     0          0

Atualizando com a saída do iptables dos servidores reais:

Chain RH-Firewall-1-INPUT (2 references)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
2    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 255
3    ACCEPT     esp  --  0.0.0.0/0            0.0.0.0/0
4    ACCEPT     ah   --  0.0.0.0/0            0.0.0.0/0
5    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpts:161:162
6    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
7    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80
8    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:443
9    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpts:161:162
10   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
11   REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Quaisquer pensamentos ou sugestões para depuração serão bem-vindos.

    

Answer 1

Verifique a configuração do firewall:

/sbin/iptables -L --line -n -v

É provável que você precise permitir o tráfego para esse VIP. Por exemplo:

/sbin/iptables -I INPUT <line#> -d 10.150.200.47 -p tcp -m tcp --dport 80 -j ACCEPT 
/sbin/iptables -I INPUT <line#> -d 10.150.200.47 -p tcp -m tcp --dport 443 -j ACCEPT 

Além disso, verifique se os servidores reais estão aceitando conexões, por exemplo:

$ sudo ipvsadm -L -n -t 10.150.200.47:80
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.150.200.47:80  wrr
  -> 192.168.100.11:80            Route   1      56         145       
  -> 192.168.100.12:80            Route   1      49         159       

Editar: Adicionando coisas para verificar no (s) servidor (es) real (is):

Supondo que você esteja usando o roteamento direto, o IP virtual precisará ser configurado na interface de loopback do (s) servidor (es) real (is). Quando a conexão é encaminhada do balanceador de carga para o servidor secundário, ela retornará na eth0 normalmente. Como seria essa configuração:

ifconfig lo:0 10.150.200.47 netmask 255.255.255.255

Ou como um script de rede:

$ cat /etc/sysconfig/network-scripts/ifcfg-lo:0
DEVICE=lo:0
IPADDR=10.150.200.47
NETMASK=255.255.255.255
ONBOOT=yes

Além disso, você precisará fazer alterações nos parâmetros do kernel via sysctl:

# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0

Além disso, você precisará alterar a forma como o ARP é anunciado e responde às solicitações ( mais informações ):

net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.eth0.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2

Além disso, configure a filtragem de rp:

net.ipv4.conf.eth0.rp_filter = 1 # Works for CentOS 5
or
net.ipv4.conf.eth0.rp_filter = 2 # Works for CentOS 6+

A configuração padrão do rp_filter pode variar entre as versões do kernel, por isso certifique-se de escolher a configuração correta. Mais informações .