我试图了解 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
服务器 IP:172.31.24.59 Mac:02:0d:2c:74:be
从上面的#4 行开始，服务器直接向客户端响应了一个确认数据包——这让我认为它正在执行直接路由，而不是通过 NLB 发送响应数据包。
但是，当我查看第 2 行时，我希望看到来自服务器 IP/Mac 地址的确认数据包，而不是第 4 行中看到的 NLB IP/Mac 地址。我知道在第 3 行中，mac 地址是 NLB 的，但由于 NLB 保留了客户端 IP，我们可以看到客户端 IP 完好无损。
如果有人能解释这种路由是如何发生的，我们将不胜感激。
最佳答案
简短版本:网络负载均衡器不是真正的设备，VPC 也不是真正的以太网，您所看到的只是这种令人信服的错觉的产物。
NLB 由称为 AWS Hyperplane 的内部服务提供，该服务与 VPC 网络基础设施集成。它在流量级别操纵网络中的流量，在流量从机器传输到机器时重写源或目标 IP 地址。
在同一个子网中使用两台机器，混合中没有 NLB，并且它们的 ARP 表中没有彼此……然后从一台机器 ping 到另一台机器。在您运行 ping 的实例上，您会看到 ARP 流量出去发现另一个实例，并且您会看到 ARP 响应从另一个实例返回。但在另一种情况下，你会嗅探……什么都没有，因为 ARP 协商从未真正发生过端到端。它只是看起来像。 ARP响应是由网络伪造的，包括第二台机器的源MAC地址。
这里正在发生类似的事情。网络本质上是在重写源 IP 的同时伪造源 MAC……因此服务器“直接”响应客户端 IP，但随后网络将源地址和源 MAC 都转换为“来自“NLB ENI。它给人一种不对称的印象，但那是一种错觉，因为流量并没有真正“通过”NLB 的任一方向。
关于amazon-web-services - 在路由数据包时，AWS NLB 如何工作？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/54730264/