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

HTTP-порты фильтруются на новых виртуальных IP-адресах в балансировщике нагрузки LVS (Linux Virtual Server)

Я унаследовал балансировщик нагрузки Linux Virutal Server (LVS) на CentOS 5.10. Он работает без проблем в течение некоторого времени без каких-либо проблем.

Теперь, когда я добавляю новый виртуальный IP (VIP), весь HTTP-трафик «фильтруется» на этот порт.

Например: вот вывод nmap для существующего VIP:

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

А вот вывод nmap для только что добавленного VIP:

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

Я должен отметить, что конфиг для нового VIP является копией исходного VIP; Я просто изменил имя, eth0 и IP.

Следует также отметить, что настоящие серверы в новом VIP ранее были в исходном VIP и там нормально работали. Теперь мне просто нужно выделить их на отдельном VIP для тестирования.

Я попробовал еще один новый VIP с другим реальным сервером (не связанным с ранее упомянутыми) и получил тот же результат.

Обновление с выводом 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

Обновление с выводом 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

Обновление с выводом iptables с реальных серверов:

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

Приветствуются любые мысли или предложения по отладке.

Проверьте конфигурацию межсетевого экрана:

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

Скорее всего, вам нужно будет разрешить трафик этому VIP. Например:

/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 

Также убедитесь, что реальные серверы принимают соединения, например:

$ 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       

Изменить: добавление вещей для проверки на реальном сервере (ах):

Предполагая, что вы используете прямую маршрутизацию, виртуальный IP должен быть настроен на интерфейсе обратной связи реального сервера (ов). Когда соединение перенаправляется от балансировщика нагрузки на вторичный сервер, он будет отвечать на eth0 как обычно. Как бы выглядела эта конфигурация:

ifconfig lo:0 10.150.200.47 netmask 255.255.255.255

Или как сетевой сценарий:

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

Кроме того, вам нужно будет изменить параметры ядра через sysctl:

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

Кроме того, вам необходимо изменить способ объявления ARP и ответа на запросы (больше информации):

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

Также настройте фильтрацию rp:

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

Параметр rp_filter по умолчанию может варьироваться в зависимости от версии ядра, поэтому убедитесь, что вы выбрали правильный параметр. Больше информации.