我试图了解AWS NLB如何在客户端和目标之间路由流量。我在客户端和服务器上都使用tcpdump对NLB进行了简单测试，以查看谁在哪里发送数据包。这是我从tcpdump中找到的-
NLB IP：172.31.29.2 Mac：02：4d：8f：d9：22：e2
客户端IP：172.31.20.174 Mac：02：7e：b1：06：aa：42
02：7e：b1：06：aa：42> 02：4d：8f：d9：22：e2，以太类型IPv4（0x0800），长度74：172.31.20.174.47682> 172.31.29.2.80 ：标志[S]
02：4d：8f：d9：22：e2> 02：7e：b1：06：aa：42，以太网类型IPv4（0x0800），长度74：172.31.29.2.80> 172.31.20.174.47682 ：标志[S。]
服务器IP：172.31.24.59 Mac：02：0d：2c：74：be
02：4d：8f：d9：22：e2> 02：0d：2c：74：be：88，以太类型IPv4（0x0800），长度74：172.31.20.174.47682> 172.31.24.59.http ：标志[S]
02：0d：2c：74：be：88> 02：7e：b1：06：aa：42，以太类型IPv4（0x0800），长度74：172.31.24.59.http> 172.31.20.174.47682 ：标志[S。]
在上面的＃4行中，服务器直接向客户端响应了确认数据包-这使我认为它正在执行直接路由，而不是通过NLB发送响应数据包。
但是，当我查看第2行时，我希望看到来自服务器IP / Mac地址的确认包，而不是第4行中的NLB IP / Mac地址。我确实知道在第3行中，mac地址是NLB，但是由于NLB保留了客户端IP，因此我们可以看到客户端IP完好无损。
如果能解释一下这种路由的发生方式，我们将不胜感激。
答案 0 :(得分：1)
简短的版本：Network Load Balancer并不是真正的设备，VPC也不是真正的以太网，您所看到的是这种令人信服的幻想的产物。
NLB由称为AWS Hyperplane的内部服务提供，该服务与VPC网络基础架构集成在一起。它在流量级别上操纵网络中的流量，并在流量从计算机传到计算机时重写源IP地址或目标IP地址。
将两台机器放在同一子网上，没有混合使用NLB，并且它们的ARP表中没有对方...并且从另一台ping到另一台。在运行ping的实例上，您会看到ARP流量出去发现另一个实例，并且会看到ARP响应从另一个实例返回。但是在另一种情况下，您什么也不会嗅到...，因为该ARP协商从未真正端到端进行。它看起来像。 ARP响应是由网络伪造的，包括第二台计算机的源MAC地址。
这里发生了类似的事情。网络本质上是在伪造源MAC的同时重写源IP，因此服务器“直接”响应客户端IP，但是随后网络将源地址和源MAC都转换为“来自“ NLB ENI”。它给人一种不对称的印象，但这是一种错觉，因为流量实际上并没有沿任何方向“通过” NLB。