数据包流分析

之前，我们使用卷曲工具来触发测试的 HTTP 请求。它支持各种功能的广泛选项。我们’已看到-H 选项，它指定了 HTTP 请求中的主机字段。这次，出于调试目的，我们使用另一个有用选项-v （在卷曲命令中）：

此选项显示有关 HTTP 交互的更多详细信息：

> 线是卷曲发送的消息内容，
< 行是收到的消息内容

从远程。从交互，您可以看到

卷曲发送了带有路径/到 FIP 101.101.101.1 的 HTTP GET，并且主机充满了可处理的 URL。
它获取代码为 200 OK 的响应，指示请求已成功。
响应中有许多其他标头对于我们的测试并不重要，因此我们可以跳过它们。
响应的其余部分为返回网页的 HTML 源代码。
连接将在以后立即关闭。

现在，’您已看到卷曲在后台执行的详细交互，您可以了解在 telnet 测试中发送的 GET 命令和主机标头。在这种测试中，我们只是模拟卷曲的操作，但现在是手动完成的！

Internet 主机到网关路由器

首先，’让 s 从客户端–启动互联网主机。

与在任何主机中一样，路由表都非常简单。通常情况下，静态路由或更多的是指向网关路由的默认路由，它需要：

最后一项是我们’手动配置的静态路由，指向我们的网关路由器。

Note

在此设置中，我们在网关路由器中配置了一个 VRF 表，用于将主机连接到相同的 MPLS/vpn 中，使其可以与 Contrail 群集中的叠加网络通信。实际上，还有其他方法可实现相同的目标。例如，网关路由器还可以选择使用 Vpn 和 Internet 路由表之间的策略来泄漏路由，以便不属于 Vpn 的互联网主机也可在 Contrail 中访问叠加网络。

用于入口公共浮点 IP 的网关路由器：GRE 上的 MPLS

我们’以前见过网’关路由器的路由表。从协议的下一跃点，我们可以通过 MPLSoGRE 通道将数据包发送至 active haproxy node cent222。

现在，在两个计算上收集的流表，我们都可以找到相同的信息。让’我们来了解活动代理计算的流条目：

此流反映源自互联网主机客户端到 active haproxy 的 TCP 连接的状态。让’我们来看一下捕获的第一项：

第一个流条目显示 HTTP 请求的源和目标;它来自互联网主机（15.15.15.2），并在当前节点 cent222 中担任入站浮点 IP。
S （nh）：61是 Internet 主机请求–源的下一跳。这类似于反向路径转发（RPF）。VRouter 始终保持向流中数据包源的路径。
Nh--get 命令使用更多详细信息解析 nexthop 61。您可以看到 MPLSoGRE 标志已设置，Sip 和 Dip 是 GRE 隧道的两个端，并且它们当前分别是节点和网关路由器’的回传（IP）。
TCP： SSrEEr 是显示 TCP 连接状态的 TCP 标志。VRouter 检测到 SYN-ACK （Sr），因此建立了双向连接（EEr）。
Proto （V）字段指示 VRF 编号和协议类型。当前（独立） NS ns-user-1 中涉及两个 VRF。
- VRF 2：默认 pod 网络的 VRF
- VRF 5：FIP-VN 的 VRF
- 协议6表示 TCP （HTTP 数据包）。

Tip

’我们稍后在为 VRF 路由表中的前缀查询 nexthop 时使用 VRF 2。

总之，第一个流条目可确认来自 Internet 主机的请求数据包遍历网关路由器，并通过 MPLSoGRE 通道访问入口外部 VIP 101.101.101.1。NAT 将会发生，’我们将探讨下一步。

将公共浮点 IP 入入口 Pod IP：FIP （NAT）

要验证 NAT 操作，您只需从以前的流输出中稍微了解一点：

第一项中的操作标记 N （D）表示目标 NAT 或 DNAT。目标入口外部浮点 IP 101.101.101.1 （作为外部）将转换为入口内部 VIP。
第二项中的操作标志 N （S）表示源 NAT 或 SNAT。这表示源 IP 10.47.255.238 （内部入口） NAT，VIP 将转换为入口外部 VIP。

总而言之，active haproxy node cent222 的流表告诉我们，在接收发送到入口浮动 IP 的数据包时，节点 cent222 上的 vRouter 执行 NAT 操作，并将目标浮点 IP （101.101.101.1）转换为入口’端 VIP （10.47.255.238）。之后，数据包将成为入口负载平衡器’的 VRF 表，并转发至活动的 haproxy’的侦听接口。HTTP 代理操作现在将发生，接下来我们’将讨论它。

Note

在 vRouter 流中，第二流条目也称为第一项的反向流。它是向互联网主机发送返回数据包的流入口 vRouter。从入口负载平衡器’的角度来看，它只使用10.47.255.238，从默认的 pod 网络作为源 IP 进行分配，不知道有关浮动 IP 的任何信息。外部互联网主机也是如此，它只知道如何到达浮动 IP，并且没有关于私有入口内部 VIP 的线索。这是 vRouter 之间的双向 NAT 翻译。

入口 Pod IP 到服务 IP：UDP 上的 MPLS

现在，数据包位于入口负载平衡器’的 VRF 表中，位于 haproxy 的前端。结果是：

Haproxy 正在对前端 IP （入口内部 podIP/VIP）和端口80进行侦听，以查看数据包。
Haproxy 将检查在其配置文件中编程的入口规则，确定请求需要代理到 webservice 的服务 IP （1）。
VRouter 检查入口负载平衡器’的 VRF 表，并查看 webservice-1 和服务 IP 从目标节点 cent333 中获知的前缀，这将成为转发数据包的下一跳跃。
计算节点之间使用 MPLSoUDP 通道对转发路径进行了编程，因此 vRouter 通过带右 MPLS 标签的 UDP 隧道 MPLS 发送。

这一过程在Figure 4中有如下说明：

让’我们先从 UI 查看 VRF 路由表。在 UI 中，我们可以根据 VRF 名称从任何计算节点检查 VRF 路由表。

从入口 podIP’s VRF （当前命名空间的默认 pod 网络的 VRF 相同），我们可以看到下一跳跃服务 IP 前缀 10.99.225.17/32 是另一个计算节点 cent333，通过10.169.25.21 隧道提供 IP MPLSoUDP。也可通过 vRouter rt/nh 实用程序找到同样的结果：

请注意，从入口到服务的所有流量都发生在 Contrail 计算节点之间的叠加中，这意味着所有叠加数据包都应封装在 UDP 通道上的 MPLS 中。要验证 haproxy 进程数据包处理的详细信息，’请让我们在节点 cent222 的物理接口上捕获数据包，其中活动 haproxy 进程正在运行。下一个屏幕捕捉（Figure 6）显示了结果

Active Haproxy Node cent222 的结构接口上的数据包捕获

从Figure 6的 Wireshark 屏幕截图，您可以清楚地了解：

框架43-45，入口专用 podIP 建立了通向服务 IP 和端口的新 TCP 连接，这发生在叠加中。
帧46，在新 TCP 连接上，haproxy 启动对服务 IP 的 HTTP 请求。
帧50，HTTP 响应返回回去。

第46帧也是用于显示数据包封装的示例。您’将看到包含 HTTP 请求的此 IP 数据包 MPLS 标记，并且嵌入在 UDP 数据报内部。数据包的外部来源和目标 IP 分别是10.169.25.20 （计算节点 cent222）和10.169.25.21 （计算节点 cent333）。

正向与代理

如果您 observant 得足够，您会注意到这种捕获中有些奇怪。例如：

’不应来源 ip 地址是互联网主机’ip 15.15.15.2，而非负载平衡器’的前端 IP？
是否已转发原始 HTTP 请求？
是来自 Internet 主机的相同 TCP 会话内的事务，还是跨越网关路由器和负载平衡器节点 cent222，一直到后端箱位于节点 cent333 中？

所有这些问题的答案都是 "否"。此测试中的 haproxy 正在执行第7层（应用层）负载平衡。其功能是：

与互联网主机建立 TCP 连接，并持续监控 HTTP 请求;
只要看到传入的 HTTP 请求，它就会检查其规则并启动与相应后端的全新 TCP 连接;
它将从 Internet 主机接收的原始 HTTP 请求复制到新的 TCP 连接中，并与其后端进行粘贴。确切地说，HTTP 请求是代理的，不是转发的。
扩展 wireshark 显示过滤器以包括15.15.15.2 和101.101.101.1。
Figure 7: 主动 Haproxy 节点 Cent222 结构接口上的数据包捕获：“整篇文章”
帧39-41：互联网主机建立了向入口外部公共 FIP 的 TCP 连接。
帧42：互联网主机发送 HTTP 请求。
帧43-52：主动 haproxy 与服务建立新的 TCP 连接、发送 HTTP 请求、检索 HTTP 响应并关闭连接。
帧53-54：active haproxy 将 HTTP 响应发送回互联网主机。
帧55-57：Internet 主机关闭了 HTTP 连接。

在这里，我们使用帧42显示 active haproxy node cent222 和网关路由器之间的 GRE 封装上的 MPLS。在前一屏幕截图中将其与帧46进行比较时，您会注意到这是一个不同的标签。在 vRouter 将数据包交付给活动 haproxy 之前，GRE 通道中携带的 MPLS 标签将被剥离。当 active haproxy 启动与远程节点的新 TCP 会话时，将分配新标签。

此时，我们知道 HTTP 请求已代理至 haproxy’s 后端。根据入口配置，这后端是 Kubernetes 服务。现在，为了到达服务，将请求发送至目标节点 cent333，其中所有后端盒都处于住位置。接下来’，我们将了解目标节点中将发生的情况。

服务 IP 到后端 Pod IP：浮动 IP （NAT）

在目标节点 cent333 上，当数据包从入口内部 IP 10.47.255.238 到 webservice 的服务 IP 10.99.225.17 时，vRouter 将再次执行 NAT 转换操作。它将服务 IP 转换为后 podIP 10.47.255.236，与您’在节点 cent222 中看到的一样，vRouter 在入口公共浮动 IP 与入口内部 podIP 之间进行转换。

以下是使用 shell 脚本捕获的流表。此流显示了 active haproxy 与后端盒之间的第二个 TCP 连接的状态：

您’在服务部分看到了类似的内容，因此您不’应在了解它时遇到问题。显然，第二项由从活动 haproxy IP （入口 podIP）向服务 IP 发出的传入请求触发。VRouter 知道服务 IP 是一种可映射到后端 podIP 10.47.255.236 的浮动 IP，而服务端口则映射到后端盒中的容器 targetPort。它在传出方向上和 SNAT + SPAT （SPs）中执行 DNAT + DPAT （DPd）。

跟踪此转发路径的另一种简单方法是查看 MPLS 标签。在上一步中，我们已看到标签38，在活动 haproxy 计算 cent222 向 MPLSoUDP 通道发送数据包以计算 cent333 时使用。您可使用 vrouter mpls 实用程序检查此 In 标签中的 nexthop：

确定下一跳跃后，您可以找到输出接口（Oif）编号，然后使用 vif 实用程序找到 pod 接口。相应的 podIP 10.47.255.236 是 HTTP 请求的后端箱，其外观与流表中显示的一致。

最后，pod 将看到 HTTP 请求，并通过网页回复。这种返回的信息流将由捕获中的第一个流条目反映出来，显示：

原始来源 IP 是10.47.255.236 的后 podIP
原始源端口为 web 还是可移植端口80
目标 IP 入口 podIP 10.47.255.238

后端盒：分析 HTTP 请求

后端箱接口上的另一个 tcpdump 数据包捕获有助于揭示入口内部 IP 和后端 podIP 之间的数据包交互：

返回信息流

相反的方向上，podIP 运行 web 还是响应其网页。响应遵循请求的反向路径：

Pod 通过 MPLSoUDP 隧道响应负载平衡器前端 IP。
节点 cent333 上的 vRouter 执行 SNAT + SPAT，将 podIP： podPort 转换为 serviceIP： servicePort。
响应到达在节点 cent222 上运行的活动 haproxy。
Haproxy 从后端盒复制 HTTP 响应，并粘贴到与远程互联网主机的连接中。
节点 cent222 上的 vRouter 执行 SNAT，将负载平衡器前端 IP 转换为浮动 IP
响应将发送至网关路由器，以将其转发至互联网主机。
互联网主机获取响应。