☰

Ping 可以工作，但 TCP 在有些不寻常的拓扑结构中不工作

tag-icon • tag-icon tcp subnet juniper vyos
Ping 可以工作，但 TCP 在有些不寻常的拓扑结构中不工作

首先要说的是，我一开始并没有设计这个网络，所以这个拓扑结构甚至对我来说都是一个意外。

有两个子网（一个是我们公司的子网，一个是我们的客户的子网）位于同一物理位置，因此这两个网络由 VLAN 分隔。但是，除此之外，我们和我们的客户都有不同的防火墙，所以我们还有一个额外的虚拟路由器 (VyOS)，它充当我们网络之间的桥梁。VyOS 路由器有两个接口（eth0 和 eth1）。

我可以很好地 ping 两个网络，但如果我尝试访问其子网中的客户端 Web 服务器，连接就会失败。特别有趣的是，当我手动将网关设置为指向 192.168.5.34 (VyOS) 而不是网关 192.168.5.1 时，连接可以正常工作，因此当防火墙必须将流量从其来源的同一接口重定向回时，防火墙一定出现了问题。此外，如果我配置源 nat，它也可以正常工作。

以下是有关网络的信息：

我们的子网：192.168.5.0/24 防火墙：192.168.5.1 VyOS eth1：192.168.5.34

客户端子网：192.168.1.0/24 防火墙：192.168.1.1 VyOS eth0：192.168.1.34

编辑：这是我尝试通过 HTTP 连接到 Web 服务器时流量所采用的路由

192.168.5.172 -> 192.168.5.1 -> 192.168.5.34 -> 192.168.1.28 | 192.168.1.28 -> 192.168.1.1（似乎此处的连接失败，在我们的 Juniper 防火墙处）

答案1

您的网络运行正常。让我们画出来：

天哪，这么多网络问题可以通过简洁的图表更好、更快地解释。自己的作品。

我确信这是一个简化，但这里有足够的信息来显示问题和各种修复（及其缺点）

假设

  • 每个设备都使用 LAN 的防火墙 IP 作为其默认网关。
  • DNS 并不重要
  • 本例中所有网络掩码均为 /24
  • 两个 LAN 拓扑被指定为 VLAN。我暂时忽略了这一点，我们将每个 VLAN 表示为一个单独的物理 LAN。
  • 这些修复假设您可以在所有三个路由器/防火墙上管理规则

对于遵循 OSI 堆栈的人来说，这都是 IP 并且位于第 3 层。

1. 直连网络

您的 PC 有一个要发送到 IP 的数据包。它首先会检查目标 IP 是否位于同一个本地 IP 网络中。如果 SRC 和 DST 地址共享同一个网络（即应用子网掩码后剩余的 IP 位），则操作系统会将数据包发送到以太网接口。操作系统会用数据包出口接口的源 IP 标记出出站数据包。

您的测试 PC 发送的数据包的 SRC IP 为 192.168.5.172，目的地为 192.168.5.250，您的网络掩码为 /24，即 255.255.255.0，网络为 192.168.5.x，因此您的 PC 可以通过将数据包放入以太网直接发送，目的地将接收它。

2.默认网关

默认网关、默认路由、网关、最后的路由器是当您没有更好的路由发送数据包时，您将数据包发送到的设备。

以下是您网络中的默认路由：

在此处输入图片描述

因此，如果目标 IP 不是本地的（直接连接），那么 TestPC 就知道该数据包的地址通过默认网关。

每个设备只有一个默认网关 IP 地址（挥手 - 是的，我试图保持简单。）

（旁注）如果 VyOS 盒子设置了默认网关，则可能是通过办公室 Juniper。这对于更新和其他东西来说很好，但与您的环境无关。VyOS 完全没有配置任何默认网关也是完全合理的。

3. 具体路线

从问题中得到的跟踪路由表明，两个办公室的防火墙对另一个 LAN 有具体的了解。

因此每个防火墙都会配置一条额外的路由。

您的公司 Juniper 知道“通过 192.168.5.34 访问 192.168.1.0/24”

他们的防火墙知道“192.168.5.0 255.255.255.0 via 192.168.1.34”或类似内容。图示的意思是：

在此处输入图片描述

4. 与包裹融为一体

因此，让我们从数据包的角度来形象化一下。

a. TestPC ping google（我使用 ping 是因为它是无状态的，而且比解释 HTTP 之类的 TCP 连接更容易）

  1. 数据包到达 8.8.8.8，但不在 192.168.5.x 中，因此 testPC 将其发送到以太网，DST 为 192.168.5.1
  2. Juniper 收到一个数据包，其 SRC 为 192.168.5.172，DST 为 8.8.8.8。它配置为 NAT 并转发此数据包。SRC 地址被重写为 Juniper 上的外部 Inet IP，并抛给 ISP。Juniper 在内存中的表中跟踪此连接。
  3. 数据包发往 google，然后通过 ISP 返回一个回复，其 SRC 为 8.8.8.8，DST 为 Inet IP
  4. Juniper 查找其连接跟踪表，发现这是 TestPC 发起的连接的回复。因此，它将 DST 更改为 192.168.5.172，并将此数据包推送到 LAN 接口（因为这是直接连接到 192.168.5.x 的接口）
  5. TestPC 监听到其 IP 的数据包并从线路上抓取它（此处有更多手势）

这是一张图片：

在此处输入图片描述

b. TestPC 现在将 ping 客户的服务器 192.168.1.28

  1. 如上所述，testPC 没有与 192.168.1.x 的直接连接，因此它将数据包发送到其默认网关 Juniper。
  2. Juniper 配置为转发数据包，但它具有到 192.168.1.x 的静态路由通过VyOS 位于 192.168.5.34，因此 Juniper 不会使用 NAT 将目的地更改为 ISP 网关，而是通过 VyOS 转发数据包。
  3. VyOS 只知道两个网络。它看到一端有数据包，并在另一个接口上转发它
  4. CustyServer 看到数据包并接收。完成一半！
  5. CustyServer 向 192.168.5.172 发送回复，但它并非直接连接，因此我们转到默认网关。
  6. 客户端防火墙不知道如何处理该数据包，因此它很可能会被丢弃，或者可能会被转发给他们的 ISP，然后由 ISP 将其丢弃。
  7. 至此，一切都结束了。回复数据包丢失，TestPC 将等待超时才能得到答案。

最后一张图如下：

在此处输入图片描述

我们该如何解决这个问题？有多种不同的解决方法。

1. 互连网络

这是“正确”的设计，在两个防火墙之间使用一个小型互连网络，并取消 VyOS 设备。我使用 172.22.22.x/24 作为互连 LAN。/24 相当大，但要保持简单。

在此处输入图片描述

积极因素

  1. 每个防火墙都知道所有的流量，并且可以正确地跟踪连接。
  2. 每家公司使用一台设备来监测防火墙的变化，无需在两个地方检查
  3. 每个 LAN 设备均具有尽可能简单的设置。

缺点

  1. 两个防火墙设备都需要一个额外的以太网接口，以及一条在它们之间运行的以太网电缆。

2. 在客户防火墙上添加静态路由

好像缺失了。如果您将蓝色箭头从客户防火墙添加到 VyOS，那么它会工作得更好。

在此处输入图片描述

3.在 VyOS 设备上添加 SOURCE NAT

某位名人曾经说过“如果你的计划涉及添加更多层 NAT，那么你就没有了解问题的根本所在”我真的不认为这是一个好主意。

如果 VyOS 设备将两个网络之间的所有流量 NAT 到该 LAN 中的自己的 IP，则回复流量将不会尝试转到默认网关。

主要缺点是您将看到来自 VyOS IP 的所有流量，并且您不知道真正的发送者是谁。这使得取证变得更加困难。

在此处输入图片描述

4. 静态路由一切事物！

这是一个糟糕的答案，但在某些情况下它可能是合适的。

如果每个 LAN 设备都有这样的路由表，那么它们都知道如何与客户 LAN 通信。

# ip ro ls
默认通过 192.168.5.1 dev eth0
192.168.1.0/24 通过 192.168.5.34 dev eth0
192.168.5.0/24 dev eth0 proto 内核范围链接 src 192.168.5.173

缺点是，这是一场管理噩梦。如果你只有几台永不移动的设备，这可能是可行的，但动态添加它们会很麻烦。

可能的挽救

  1. Active Directory 可以使用组策略推出静态路由。对未加入域的 Windows 设备没有帮助。打印机、电话、AP，其他一切都被忽略了。这就是我所知道的全部。
  2. 可以使用 DHCP 推送静态路由，但大多数实现都会忽略该提议。pfSense 可以做到这一点，但 windows10 忽略了该选项。

在此处输入图片描述

总之

局域网地图 是解决网络问题的好方法。我很喜欢！我使用过http://www.gliffy.com/为这些插图创建背景图像。

吻 如果一个解决方案繁琐而复杂，那么它很可能就是错误的解决方案。

相关内容