平的作品，但TCP没有一点不寻常的拓扑结构
我首先会说我没有从头开始devise这个networking，所以拓扑对我来说也是一个惊喜。
有两个子网（一个是我们的公司，一个是我们的客户端），它们位于同一个物理位置，因此networking被VLAN隔开。 但是，除此之外，我们和我们的客户都有不同的防火墙，所以我们有一个额外的虚拟路由器（VyOS），它充当我们networking之间的桥梁。 VyOS路由器有两个接口（eth0和eth1）。
我能ping通两个networking，但如果我尝试去我们的客户端networking服务器在他们的子网连接失败。 特别有趣的是，当我手动设置我的网关指向192.168.5.34（VyOS），而不是我们的网关在192.168.5.1连接工作，所以一定有东西在防火墙失败，当它必须redirect的stream量从它来自的相同的接口出来。 另外，如果我configuration源NAT，它也可以。
这是关于networking的信息：
- 思科，如何使用VLSM和RIP-2做子网划分？
- 在一个交换机后面的两个IP范围之间启用通信需要什么？
- 2个服务器在内部子网（192.168.1.10）中看不到对方
- OpenVPNnetworking共享
- 多个子网上的ARP发现
我们的子网：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服务器时，stream量采取的路线
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防火墙上）
您的networking按预期工作。 让我们画出来：
这是一个简单的，我敢肯定，但有足够的信息来显示问题和各种修复（及其缺点）
假设
- 每台设备都使用LAN的防火墙IP作为其默认网关。
- DNS并不重要
- 在这个例子中所有的networking掩码是/ 24
- 这两种LAN拓扑结构是作为VLAN提供的。 现在我已经把它留下了，我们将每个VLAN表示为一个单独的物理LAN。
- 修复假定您可以pipe理所有三个路由器/防火墙上的规则
对于那些遵循OSI协议栈的，这是所有的IP，并在第3层。
1.直接连接的networking
你的电脑有一个包发送到IP。 它所做的第一件事是检查目标IP是否在同一个本地IPnetworking中。 如果SRC和DST地址共享同一个networking（即应用子网掩码后剩下的IP位），则操作系统将数据包从以太网接口中分出。 操作系统使用出口数据包所在接口的源IP标记出站数据包。
您的testingPC发送SRC IP为192.168.5.172的数据包。目的地是192.168.5.250您的networking掩码是/ 24，它是255.255.255.0，留下了192.168.5.x的networking。因此，您的PC可以通过将数据包放出以太网和目的地将收到它。
2.默认网关
默认网关，默认路由，网关，最后一个路由器，是当你没有更好的路由发送数据包的时候发送的。
以下是networking中的默认路由：
所以如果目标IP不是本地的（直接连接），那么TestPC知道通过默认网关寻址数据包。
一个设备只有一个默认网关IP地址（手摇 – 是的，我试图保持简单。）
（侧面评论）如果VyOS框有一个默认的网关集，它可能是通过您的办公室瞻博networking。 这对于更新和内容来说不错，但与您的环境无关。 对于VyOS完全没有configuration任何默认网关也是完全合理的。
3.具体路线
从问题的跟踪路由表明，这两个办公室防火墙具有其他局域网的具体知识。
所以每个防火墙都会有一个额外的路由configuration。
您的公司Juniper知道“通过192.168.5.34访问192.168.1.0/24”
他们的防火墙知道“192.168.5.0 255.255.255.0”是通过192.168.1.34“或类似的。 这意味着：
与包一起
所以让我们从包的angular度来看这个。
一个。 TestPC ping谷歌（我使用ping，因为它的无状态和容易比解释一个TCP连接像HTTP）
- 数据包是8.8.8.8这不是在192.168.5.x，所以testPC把它扔在以太网上，DST是192.168.5.1
- Juniper接收到SRC为192.168.5.172，DST为8.8.8.8的数据包，并将其configuration为NAT并转发此数据包。 SRC地址被重写到瞻博networking上的外部Inet IP上，并被传送到ISP。 瞻博networking在内存中的表中跟踪此连接。
- 数据包转到谷歌，并通过ISP的回复通过8.8.8.8的SRC和Inet IP的DST返回
- Juniper查找其连接跟踪表，发现这是对TestPC启动的连接的回复。 因此，它将DST更改为192.168.5.172，并在LAN接口上推送此数据包（因为这是直接连接到192.168.5.x的接口
- TestPC听到一个数据包的IP，并将其从线路上截获（在这里更多的是handwaving）
这作为图片：
湾 TestPC现在将ping 192.168.1.28客户的服务器
- 如上所述，testPC没有直接连接到192.168.1.x，所以它将数据包定位到默认网关Juniper。
- Juniperconfiguration为转发数据包，但是它具有通过 192.168.5.34 上的 VyOS到192.168.1.x的静态路由。因此，瞻博networking不通过NAT将目的地更改为ISP网关，而是通过VyOS转发数据包。
- VyOS只知道两个networking。 它在另一侧看到一个数据包，并在另一个接口上转发
- CustyServer看到数据包并接收它。 半！
- CustyServer向192.168.5.172发送一个回复，但是没有直接附加，所以我们去默认网关。
- custy防火墙没有想法如何处理这个数据包，所以它可能会被丢弃，或者可能被转发给他们的ISP，然后丢弃它。
- 此时其全部结束。 回复数据包丢失，并且TestPC将等待，直到答案超时。
这是最后一张照片：
我们如何解决这个问题？ 有多个不同的修复程序。
1.互连networking
这是“适当的”devise，在两个防火墙之间使用一个小的互连networking，并取消VyOS设备。 我已经使用172.22.22.x / 24作为互联局域网。 A / 24是相当大的，但保持这个简单。
阳性
- 每个防火墙都知道所有stream量，并可以正确连接跟踪。
- 每个公司的一台设备用于防火墙更改，而不是两个地方检查
- 每个LAN设备都有最简单的设置。
缺点
- 两个防火墙设备都需要额外的以太网接口，并在它们之间运行以太网电缆。
2.在客户的防火墙上添加一条静态路由
这似乎是失踪。 如果您将客户防火墙的蓝色箭头添加到VyOS，那么效果会更好。
3.在VyOS设备上添加一个SOURCE NAT
曾经有人说过“如果你的计划涉及到增加更多层的NAT，那么你就不了解根本问题”我并不认为这是一个好主意。
如果VyOS设备将两个networking之间的所有stream量转换为该LAN中的OWN IP，则回复stream量将不会尝试去默认网关。
主要的缺点是你会看到来自VyOS IP的所有stream量，你不知道真正的发送者是谁。 这使得取证更难一些。
4.静态路由所有的东西！
这是一个可怕的答案，但在某些情况下，这可能是适当的。
如果每个局域网设备都有这样的路由表，那么他们都知道如何与局域网交谈。
＃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
下行，这是一个pipe理噩梦。 如果只有一些设备永远不会移动，但是dynamic添加它们可能是可行的。
可能的保存
- Active Directory可以通过组策略推出静态路由。 不会帮助任何不是域join的窗口框的设备。 打印机，电话，接入点，其他的一切都没有了。 这就是我所知道的。
- 它可能推动一个静态路由与DHCP，但大多数实现忽略提供。 pfSense可以做到，但windows10忽略了这个选项。
综上所述
LAN地图是理解您的networking问题的绝佳解决scheme。 爱他们！ 我用http://www.gliffy.com/为这些插图创build背景图像。
KISS如果一个解决scheme是单调而复杂的，那么可能是错误的解决scheme。