HTTPポートは、LVS（Linux Virtual Server）ロードバランサーの新しい仮想IPでフィルタリングされます
CentOS5.10でLinuxVirutal Server（LVS）ロードバランサーを継承しました。かなり長い間問題なく動作しており、心配もありません。
これで、新しい仮想IP（VIP）を追加すると、すべてのHTTPトラフィックがそのポートに「フィルタリング」されます。
例：既存のVIPのnmap出力は次のとおりです。
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
そして、これがVIP追加したばかりのnmap出力です：
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を変更しただけであることに注意してください。
もう1つ注意すべき点は、新しいVIPの実サーバーは、以前は元のVIPであり、そこで正常に機能していました。今は、それらを分割する必要があります。 a 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を介してカーネルパラメータを変更する必要があります。
＃ソースルーティングを受け入れない 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＃CentOS5で動作 または net.ipv4.conf.eth0.rp_filter = 2＃CentOS6 +で動作
デフォルトのrp_filter設定はカーネルのバージョンによって異なる可能性があるため、正しい設定を選択してください。 詳細情報 。