我的EC2 CentOS虚拟机上正在删除ELB HTTP数据包,但没有直接连接?

我在VPC上的AWS上的CentOS AMI上运行了一个简单的webserver(仅限apache)。 我已经为端口80打开了AWS安全组和iptables,没有源代码需求。 然后,我设置了一个Elastic Load Balancer来将stream量引导到单个实例(当一切正常时,我将克隆它以获得多个负载均衡的实例)。 在负载平衡器上注册的实例就好了,目前被列为“健康”

如果我在浏览器中提取实例的本地IP地址,我可以很好地连接/查看页面。

如果我在浏览器中提取ELB的主机名,则超时。 我检查实例上的/ var / log / messages,并且iptables已经丢弃了这个包。 我不知道为什么iptables没有find这些数据包的匹配,但直接连接。

我删除了iptables中的大部分规则,以确保没有什么交互的奇怪。 这是我目前的规则集:

*filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A RH-Firewall-1-INPUT -s 10.40.0.0/16 -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT -A RH-Firewall-1-INPUT -j LOG --log-prefix "IP DROP NO MATCH: " -A RH-Firewall-1-INPUT -j DROP COMMIT 

以下是丢弃的数据包的样子:

 Aug 28 21:59:54 ip-10-40-80-11 kernel: IP DROP NO MATCH: IN=eth0 OUT= MAC=0e:57:37:73:05:4e:0e:57:37:40:00:3F:68:21 SRC=10.40.80.179 DST=10.40.80.11 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=2363 DF PROTO=TCP SPT=61866 DPT=80 WINDOW=58 RES=0x00 ACK FIN URGP=0 

出于好奇,我在我的iptablesconfiguration中注释了--dport 80行,以便任何端口80的stream量都被阻塞了。 然后,我通过直接IP在浏览器中访问实例,查找丢弃的数据包的日志。 我想比较丢弃的数据包日志logging的“成功”连接与ELB的问题。 以下是我所看到的:

 Aug 28 22:05:12 ip-10-40-80-11 kernel: IP DROP NO MATCH: IN=eth0 OUT= MAC=0e:57:37:73:05:4e:0e:57:37:40:00:3F:68:21 SRC=10.40.180.110 DST=10.40.80.11 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=2816 DF PROTO=TCP SPT=50995 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0 

唯一的区别(除了源,这应该不重要?)是,ELB数据包以ACK FIN结尾,而我的直接连接以SYN结束…但是我承认我不太了解复杂的TCP知道这是否真的有所作为。

什么可能会阻止ELB HTTP数据包通过防火墙成功的区别?

编辑:tcpdump结果

 # tcpdump -i eth0 port 80 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 22:49:38.994125 IP 10.40.80.11.http > 10.40.80.179.62394: Flags [F.], seq 2393122986, ack 3223961569, win 227, options [nop,nop,TS val 116463035 ecr 1792527], length 0 22:49:43.231187 IP 10.40.80.179.62426 > 10.40.80.11.http: Flags [S], seq 1887835523, win 14600, options [mss 1460,sackOK,TS val 1836427 ecr 0,nop,wscale 8], length 0 22:49:43.231267 IP 10.40.80.11.http > 10.40.80.179.62426: Flags [S.], seq 3789128001, ack 1887835524, win 14480, options [mss 1460,sackOK,TS val 116467272 ecr 1836427,nop,wscale 6], length 0 22:49:43.231578 IP 10.40.80.179.62426 > 10.40.80.11.http: Flags [.], ack 1, win 58, options [nop,nop,TS val 1836427 ecr 116467272], length 0 22:49:43.231684 IP 10.40.80.179.62426 > 10.40.80.11.http: Flags [F.], seq 1, ack 1, win 58, options [nop,nop,TS val 1836427 ecr 116467272], length 0 22:49:43.231774 IP 10.40.80.11.http > 10.40.80.179.62426: Flags [F.], seq 1, ack 2, win 227, options [nop,nop,TS val 116467272 ecr 1836427], length 0 22:49:43.232012 IP 10.40.80.179.62426 > 10.40.80.11.http: Flags [.], ack 2, win 58, options [nop,nop,TS val 1836427 ecr 116467272], length 0 22:49:47.632855 IP 10.40.80.179.62427 > 10.40.80.11.http: Flags [S], seq 3419546406, win 14600, options [mss 1460,sackOK,TS val 1837527 ecr 0,nop,wscale 8], length 0 22:49:47.632929 IP 10.40.80.11.http > 10.40.80.179.62427: Flags [S.], seq 1724369749, ack 3419546407, win 14480, options [mss 1460,sackOK,TS val 116471673 ecr 1837527,nop,wscale 6], length 0 22:49:47.632942 IP 10.40.80.179.62416 > 10.40.80.11.http: Flags [F.], seq 3666215037, ack 243876755, win 58, options [nop,nop,TS val 1837527 ecr 116411675], length 0 22:49:47.633055 IP 10.40.80.11.http > 10.40.80.179.62416: Flags [F.], seq 1, ack 1, win 227, options [nop,nop,TS val 116471673 ecr 1837527], length 0 22:49:47.633209 IP 10.40.80.179.62427 > 10.40.80.11.http: Flags [.], ack 1, win 58, options [nop,nop,TS val 1837527 ecr 116471673], length 0 22:49:47.633282 IP 10.40.80.179.62416 > 10.40.80.11.http: Flags [.], ack 2, win 58, options [nop,nop,TS val 1837527 ecr 116471673], length 0 

很可能iptables不会将ACK / FIN数据包看作一个新的连接。
由于端口80规则指定只有在连接是新连接的情况下才允许连接,因此将删除不是新连接的任何连接。

如果你删除-m state --state NEW从80端口规则和testing-m state --state NEW会发生什么?

尝试sudo service iptables stop ,看看它是否与iptables相关。