我的 EC2 CentOS vm 上为什么会丢弃 ELB HTTP 数据包而不是直接连接?

我的 EC2 CentOS vm 上为什么会丢弃 ELB HTTP 数据包而不是直接连接?

我在 VPC 内的 AWS 上的 CentOS AMI 上运行了一个简单的 Web 服务器(仅限 Apache)。我已为端口 80 打开了 AWS 安全组和 iptables,无需任何源要求。然后,我设置了一个 Elastic Load Balancer 来将流量定向到单个实例(当一切正常时,我会将其克隆为多个负载平衡实例)。该实例已在负载平衡器上注册,目前被列为“健康”

如果我在浏览器中调出实例的本地 IP,我就可以正常连接/查看页面。

如果我在浏览器中调出 ELB 的主机名,它会超时。我检查实例上的 /var/log/messages,发现 iptables 已丢弃该数据包。我不知道为什么 iptables 找不到这些数据包的匹配项,但找到了直接连接的匹配项。

我删除了 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 

出于好奇,我注释掉了--dport 80iptables 配置中的这一行,这样任何端口 80 流量都会被阻止;然后我通过直接 IP 在浏览器中访问了该实例,并查找了丢包日志。我想比较一下丢包日志中记录的“成功”连接与 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

答案1

iptables 很可能不会将 ACK/FIN 数据包视为新连接。
由于端口 80 规则指定仅当连接是新连接时才允许连接,因此它将丢弃任何不是新连接的连接。

-m state --state NEW如果从端口 80 中删除规则并进行测试,会发生什么情况?

答案2

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

相关内容