amazon-web-services - AWS ECS Iptables允许源和目标是相同的IP地址

Question

当前，结合使用AWS ECS和内部NLB，就不可能进行系统间通信。含义容器1（在实例1上）->内部NLB->容器2（在实例1上）。由于源IP地址不变，并且与目标IP相同，因此ECS实例将丢弃此流量。

我在https://forums.aws.amazon.com/message.jspa?messageID=806936#806936的AWS论坛上找到一个线程来解释我的问题。

我已经联系了AWS支持，他们表示要对路线图进行修复，但是他们无法告诉我何时修复该问题，因此在AWS永久修复之前，我正在寻找自行解决问题的方法。

它必须通过更改ECS iptables可修复，但是我没有足够的知识来完全阅读其iptables设置并了解需要进行哪些更改以解决此问题。

iptabels-保存输出：

:DOCKER - [0:0]
:DOCKER-ISOLATION - [0:0]
:DOCKER-USER - [0:0]
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A DOCKER -d 172.17.0.3/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 5000 -j ACCEPT
-A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 5000 -j ACCEPT
-A DOCKER -d 172.17.0.5/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 8086 -j ACCEPT
-A DOCKER-ISOLATION -j RETURN
-A DOCKER-USER -j RETURN
COMMIT
# Completed on Wed Jan 31 22:19:47 2018
# Generated by iptables-save v1.4.18 on Wed Jan 31 22:19:47 2018
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [38:2974]
:POSTROUTING ACCEPT [7147:429514]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A PREROUTING -d 169.254.170.2/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 127.0.0.1:51679
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT -d 169.254.170.2/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 51679
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 172.17.0.3/32 -d 172.17.0.3/32 -p tcp -m tcp --dport 5000 -j MASQUERADE
-A POSTROUTING -s 172.17.0.2/32 -d 172.17.0.2/32 -p tcp -m tcp --dport 5000 -j MASQUERADE
-A POSTROUTING -s 172.17.0.5/32 -d 172.17.0.5/32 -p tcp -m tcp --dport 8086 -j MASQUERADE
-A DOCKER -i docker0 -j RETURN
-A DOCKER ! -i docker0 -p tcp -m tcp --dport 32769 -j DNAT --to-destination 172.17.0.3:5000
-A DOCKER ! -i docker0 -p tcp -m tcp --dport 32777 -j DNAT --to-destination 172.17.0.2:5000
-A DOCKER ! -i docker0 -p tcp -m tcp --dport 32792 -j DNAT --to-destination 172.17.0.5:8086
COMMIT
# Completed on Wed Jan 31 22:19:47 2018

IP地址：

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 0a:b4:86:0b:c0:c4 brd ff:ff:ff:ff:ff:ff
    inet 10.12.80.181/26 brd 10.12.80.191 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::8b4:86ff:fe0b:c0c4/64 scope link
       valid_lft forever preferred_lft forever
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:ca:cf:36:ae brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:caff:fecf:36ae/64 scope link
       valid_lft forever preferred_lft forever
7: vethbd1da82@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
    link/ether 36:6d:d6:bd:d5:d8 brd ff:ff:ff:ff:ff:ff link-netnsid 1
    inet6 fe80::346d:d6ff:febd:d5d8/64 scope link
       valid_lft forever preferred_lft forever
27: vethc65a98f@if26: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
    link/ether e6:cf:79:d4:aa:7a brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::e4cf:79ff:fed4:aa7a/64 scope link
       valid_lft forever preferred_lft forever
57: veth714e7ab@if56: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
    link/ether 1e:c2:a5:02:f6:ee brd ff:ff:ff:ff:ff:ff link-netnsid 3
    inet6 fe80::1cc2:a5ff:fe02:f6ee/64 scope link
       valid_lft forever preferred_lft forever

Answer 1

我没有即将到来的解决方案的信息，但我怀疑任何解决方法都将涉及防止实例与其自身连接，而是始终连接至其他实例……或者也许将平衡器的源地址用于发夹式连接，而不是原始地址。

基本的问题是：平衡器通过与网络基础结构集成，进行网络地址转换，更改出局中的原始目标地址以及返回中的源地址来工作，以便目标组中的实例可以看到客户端的真实源地址，但不能反过来……但这与非对称路由不兼容。当实例最终与自己对话时，路由是相当不对称的。

假设平衡器为172.30.1.100，实例为172.30.2.200。

TCP连接从172.30.2.200（实例）启动到172.30.1.100（平衡器）。这些端口并不是很重要，但是假设源端口为49152（临时端口），而均衡器目标端口为80，实例目标端口为8080。

172.30.2.200:49152 > 172.30.1.100:80 SYN

NLB是NAT设备，因此将其翻译为：

172.30.2.200:49152 > 172.30.2.200:8080 SYN

这被发送回实例。

这已经没有任何意义，因为实例只是从自身，来自外部的某个对象收到了传入请求，即使它没有发出该请求。

假设它响应，而不是丢弃已经是无意义的数据包，现在您将获得以下信息：

172.30.2.200:8080 > 172.30.2.200:49152 SYN+ACK

如果172.30.2.200:49152实际上已将数据包发送到172.20.2.200:8080，它将以ACK响应并建立连接。

但事实并非如此。

接下来发生的事情应该是这样的：

172.30.2.200:49152 > 172.30.2.200:8080 RST

同时，172.30.2.200:49152从172.30.1.100:80还没有听到任何声音，因此它将重试，然后最终放弃： Connection timed out。

当源计算机和目标计算机不同时，NLB可以工作，因为它不是像ELB / ALB提供的那样的真实（虚拟）计算机，而是由网络本身完成的。这是唯一可能的解释，因为否则这些具有转换地址的数据包的确会将其返回到原始计算机，而NAT发生在相反的方向，并且只有在VPC网络保留这些连接的状态表并进行转换的情况下，这种情况才会发生。

请注意，在VPC中，默认网关不是真实的。实际上，子网不是真实的。以太网不是真实的。 （这些都不是批评。这里有一些非常出色的工程证据。）所有这些都由VPC网络基础结构中的软件模拟。当位于同一子网上的两台计算机直接相互通信时……他们不会。¹他们正在通过软件定义的网络进行通信。这样，即使计算机在同一子网中，网络也可以看到这些数据包并执行NLB所需的转换。

但是，当机器自言自语时则不是这样，因为当这种情况发生时，流量永远不会出现在网络上，而是保持在单个VM内，超出了VPC网络基础架构的范围。

我不认为基于实例的解决方法是可行的。



¹他们没有。一个非常有趣的示例是使用Wireshark监视同一子网中两个实例上的流量。打开安全组，然后从另一个ping通一个实例。源计算机发送ARP请求，并似乎从目标设备获得ARP响应...但是没有证据表明目标计算机上存在ARP交互。那是因为它不会发生。网络处理目标实例的ARP响应。这是无法从另一个实例欺骗一个实例的部分原因-伪造的数据包不会被网络转发，因为它们显然是无效的，并且网络知道它。发生ARP之后，ping通正常。流量似乎是根据第2层标头直接在实例之间传递的，但这并不是实际发生的情况。