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

Question

我首先要说我没有从一开始就设计这个网络，所以拓扑结构甚至对我来说都是一个惊喜。

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

我可以很好地 ping 两个网络，但是如果我尝试访问我们客户端子网中的 Web 服务器，连接就会失败。特别有趣的是，当我手动将网关设置为指向 192.168.5.34 (VyOS) 而不是我们的网关 192.168.5.1 时，连接可以正常工作，因此当防火墙必须将流量重定向回来时，防火墙肯定会出现故障从它来自的同一个界面出来。另外，如果我配置 source 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（似乎连接失败，在我们的瞻博网络防火墙）

Answer 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 地址（handwave - 是的，我正在努力保持简单。）

（旁注）如果 VyOS 盒子有一个默认网关设置，它可能是通过你的办公室瞻博网络。这对更新和东西很好，但它与您的环境无关。VyOS 根本没有配置任何默认网关也是完全合理的。

三、具体路线

问题中的 traceroute 表明两个办公室防火墙对另一个 LAN 有特定的了解。

所以每个防火墙都会配置一个额外的路由。

您的公司瞻博网络知道“通过 192.168.5.34 访问 192.168.1.0/24”

他们的防火墙知道“192.168.5.0 255.255.255.0 via 192.168.1.34”或类似的。从图片上看，这意味着：

4. 与包合一

因此，让我们从数据包的角度对此进行可视化。

一种。TestPC ping google（我使用 ping 是因为它是无状态的，而且比解释像 HTTP 这样的 TCP 连接更容易）

1. 数据包是 8.8.8.8 这不在 192.168.5.x 中，所以 testPC 将它以 192.168.5.1 的 DST 扔到以太网上
2. Juniper 收到一个 SRC 为 192.168.5.172 和 DST 8.8.8.8 的数据包，它被配置为 NAT 并转发这个数据包。SRC 地址被重写到 Juniper 上的外部 Inet IP 并扔给 ISP。瞻博网络在内存中的表中跟踪此连接。
3. 数据包转到谷歌，然后通过 ISP 返回回复，其中 SRC 为 8.8.8.8 和 Inet IP 的 DST
4. Juniper 查找其连接跟踪表，发现这是对 TestPC 启动的连接的回复。因此它将 DST 更改为 192.168.5.172 并将此数据包推送到 LAN 接口（因为这是直接连接到 192.168.5.x 的接口）
5. TestPC 听到 IP 的数据包并将其从网络上抓取（此处更多挥手）

这是一张图片：

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

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

这是最后一张图片：

我们如何解决这个问题？有多种不同的修复。

1.互联网络

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

正能量

1. 每个防火墙都知道所有流量，并且可以正确地跟踪连接。
2. 每家公司一台设备进行防火墙更改，而不是检查两个地方
3. 每个 LAN 设备都有最简单的设置。

缺点

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

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

它似乎不见了。如果您将蓝色箭头从 Customer Firewall 添加到 VyOS，则效果会更好。

3. 在 VyOS 设备上添加 SOURCE NAT

有人曾说过“如果您的计划涉及添加更多 NAT 层，那么您就不会理解根本问题”，我真的认为这不是一个好主意。

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

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

4.静态路由所有的东西！

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

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

# ip ro ls
default via 192.168.5.1 dev eth0
192.168.1.0/24 via 192.168.5.34 dev eth0
192.168.5.0/24 dev eth0 proto kernel scope link src 192.168.5.173

不利的一面是，这是一个管理噩梦。如果您只有几个从不移动的设备，这可能是可行的，但动态添加它们很麻烦。

可能的保存

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

总之

LAN Maps 是了解网络问题的绝佳解决方案。爱他们！我已使用http://www.gliffy.com/为这些插图创建背景图像。

KISS 如果一个解决方案既乏味又复杂，那么它可能是错误的解决方案。