pfSense 上本地设备的 NAT - 我错过了什么?

pfSense 上本地设备的 NAT - 我错过了什么?

我有一个古老而奇怪的 20 世纪 80 年代的设备(它是我很久以前拥有的一个早期控制器的一部分)。

它的硬编码地址为 192.168.1.100,显然(可能是因为年代久远了)它预计子网为 192.168.1.100/24,实际上除非来自该子网,否则它不会响应任何内容。它连接到我的 pfSense 路由器上的 OPT1 NIC,该路由器的接口为 192.168.1.1/24。

我想做的是在路由器中设置某种 NAT 规则或 VIP,这样我的桌面就可以直接与它通信。我的桌面 IP 是 192.168.3.2,LAN NIC 有接口 192.168.3.1/24。例如以下任一设置:

  1. 选项1- LAN 接口上从源=192.168.3.2 目标=192.168.1.100 收到的数据包照常在 OPT1 上转发,但数据包经过 NAT 后,源=192.168.1.1(OPT1 的 IP)目标=192.168.1.100 - 因此设备“认为”它们来自所需子网。然后,路由器在 OPT1 上接收其回复,并通过 LAN 转发回 192.168.3.2
  2. 选项 2- LAN 接口上发送到虚拟 LAN IP 目标=192.168.3.100 的数据包被路由器接受,路由器在“后台”将它们转发到 OPT1,并将数据包修改为源=192.168.1.1(OPT1 的 IP)目标=192.168.1.100 - 因此设备“认为”它们来自所需的子网。然后,路由器在 OPT1 处接收其回复,并在 LAN 上转发,源 192.168.1.100 映射回 192.168.3.100,因此当桌面收到它们时,它们似乎来自 LAN 上的设备,而不是 LAN 之外的设备。

这两个选项的区别在于,第一个选项中,原始数据包被发送到非 LAN IP,路由器在 OPT1 上转发数据包时会修改其源。第二个选项中,原始数据包被发送到 LAN 上的虚拟 IP,路由器在转发数据包之前会同时修改其源和目标。

这两种方式与 pfSense 对虚拟 IP 和其他 NAT 选项的操作几乎完全相同,因此我确信这并不难。但我似乎无法让这两种方式都发挥作用 - NAT 是一个相当复杂的领域!

答案1

我找到了答案。解决方案称为出站 NAT,它将源 IP或数据包,而不是(更常见的是)目标 IP。

不幸的是,文档有点含糊不清,在出站 NAT 上很容易被误解,所以这是我找到的完整答案:

我曾假设 NAT 会应用于出站数据包(即通过某个接口进入路由器),但它实际上应用于出站数据包路由器的出站接口上。

  1. 我设置了一个“IP 别名”类型的虚拟 IP(但也许其他类型也可以正常工作),我希望数据包看起来像来自的 IP(本例中为 192.168.1.0/24 范围内的任何内容 - 例如 192.168.1.5)。IP 别名需要位于接口上 - 我使用了它将离开路由器(此例中为 OPT1),而不是它到达路由器时的那个。

  2. 我启用了混合 NAT(手动/AON NAT 也可以工作),然后在同一个接口(OPT1)上添加了出站 NAT 规则,源 = 任意(或数据包实际来自的任何 IP 范围),目标 = 目标 IP 或其子网或其他(我使用了 192.168.1.0/24)。然后,我从下拉框中选择我在步骤 1 中输入的虚拟 IP,设置“转换地址”。

这正是我想要的。发送到其目标 IP 的数据包从 LAN 传入,并在从 OPT1(NAT 规则中的接口)传出时被 NAT 接收。由于数据包的源与“any”匹配,并且其目标与 NAT 规则中输入的值(192.168.1.0/24)匹配,因此其源按要求转换为 192.168.1.5,然后通过 OPT1 发送出去。

数据包捕获证实了这一点 - 当我按照第一篇文章中的描述进行 ping 操作时,OPT1 接口上的数据包捕获显示从 192.168.3.2 -> 192.168.1.100 的 ping 和回复,但 OPT2 接口上的数据包捕获显示从 192.168.1.5 -> 192.168.1.100 的 ping 和回复如预期的那样。

这不仅对我的设备有用,而且对任何其他需要数据包看起来来自与另一台设备相同子网的情况也很有用。

相关内容