软路由
初创团队，各方面有限，我们是saas+硬件，但是我们只有单个公网IP、一个一级域名，所以为了短时间适配生产、研发、测试三个环境，同时支持SaaS+硬件通信，我们需要做前端入口的流量管理，团队的小伙伴选择了OPNsense。
这一篇是我为了了解该技术方案而简单整理的。
OPNsense的防火墙模块基于FreeBSD的pf（Packet Filter），提供了强大的NAT功能，包括Port Forward（转发规则）、Outbound NAT（出站NAT）和NPTv6（IPv6前缀转换）。从我的截图可以看到，Port Forward页面列出了WAN到LAN的TCP流量规则（如Web服务和RDP），而Outbound NAT页面显示了自动生成的出站规则。这些功能让我在单一公网IP下实现了多环境隔离和外部访问。
NAT策略：Port Forward与Outbound NAT的协同
最初我以为Port Forward能解决所有需求，但实践证明，仅靠它处理入站流量是不够的。Outbound NAT才是出站流量的关键，尤其在多VLAN和硬件通信场景中，两者需协同工作。
Port Forward：
用途：处理入站流量，将公网端口映射到内部IP。例如，我配置了WAN:443到192.168.10.10:443，让外部通过prod.example.com访问生产环境。
局限：不管理出站流量，硬件向SaaS发送数据时需依赖Outbound NAT。
配置：Firewall → NAT → 转发，添加规则（Protocol: TCP；Destination: WAN address:443；Redirect to: 192.168.10.10:443）。
Outbound NAT：
位置：Firewall → NAT → Outbound，当前为自动模式，自动为WAN出站流量分配公网IP。
优化：切换到手动模式，为每个VLAN设置规则，确保出站流量隔离。
我的经验：自动模式曾因端口冲突导致硬件API请求失败，切换到手动后问题解决。
找到并配置Outbound NAT
Outbound NAT是管理出站流量的关键，位于Firewall → NAT → Outbound页面。从我的截图可以看到，默认使用“自动生成规则”，为LAN和Loopback网段分配WAN地址。但对于复杂场景，我切换到手动模式以满足需求。
手动配置：
点击“切换到手动规则”（Switch to Manual Outbound NAT rule generation），保存。
添加规则：Interface: WAN；Source: 192.168.10.0/24（生产），Translation: WAN地址，描述:“Production Outbound”。
依次为研发（192.168.20.0/24）和测试（192.168.30.0/24）设置规则。
硬件场景：为生产VLAN的硬件（如192.168.10.10）添加规则，确保其API请求（如curl https://prod.example.com/api/v1/data）顺利出站。
优化：启用NAT Reflection（Firewall → Advanced），让内部设备用公网IP访问暴露服务。
经验：备份配置（System → Config History）后切换模式，避免误操作。日志监控（Firewall → Log Files）帮助我定位流量问题。
下一步行动项
实战配置：综合NAT策略
入站：Port Forward规则处理prod.example.com的HTTPS请求，映射到生产环境的Web服务器。
出站：手动Outbound NAT为每个VLAN配置规则，保障出站流量隔离。我的硬件通过生产VLAN的规则上传数据，测试显示吞吐量稳定。
硬件场景：结合Port Forward和Outbound NAT，硬件既能接收SaaS命令（入站），又能上传数据（出站），单IP利用率显著提升。
NPTv6（未来扩展）：当前用IPv4，但NPTv6为IPv6网络的前缀转换提供了可能，适合ISP支持IPv6时升级。
硬件通信：NAT与子域名的结合
我的SaaS硬件通过prod.example.com与服务通信，NAT策略确保其双向通信。
入站：Port Forward映射WAN:443到192.168.10.10:443，配合HAProxy根据子域名分发流量。
出站：Outbound NAT规则让硬件出站请求使用公网IP，日志显示连接正常。
安全：用别名（Firewall → Aliases）定义硬件IP范围，限制未授权访问。
实践：我用curl测试硬件请求，确认数据成功上传到SaaS。
VPN: 团队vpn后续我会研究是否能用OPNsense