NAT转发功能建议

Water

建议增加协议和端口项.

小老弟

楼主好，您具体应用场景是什么样的，一般NAT涉及到协议和端口的就是端口映射规则，可以具体说明一下吗？

Water

像ros防火墙的nat那样什么都可以自定义，虽然复杂，但是功能强大。

爱快的端口映射就真的是个映射，够用了。

但是nat转发功能，动作有了，线路有了，源和目的地址有了，目标地址也有了，但是不能指定协议和端口。如果加了协议和端口项应该可以实现的功能会多很多。

像原有的“强制客户端DNS代理”，就是把LAN的udp53端口的流量劫持转发到本机。

像原有的“第三方DNS代理模式”，就是把LAN的udp53端口的流量劫持转发到指定服务器并排除这个第三方DNS服务器。

为什么局限性要这么强呢？

Water

小老弟 发表于 2020-5-26 09:36
楼主好，您具体应用场景是什么样的，一般NAT涉及到协议和端口的就是端口映射规则，可以具体说明一下吗？ ...

像ros防火墙的nat那样什么都可以自定义，虽然复杂，但是功能强大。

爱快的端口映射就真的是个映射，够用了。

但是nat转发功能，动作有了，线路有了，源和目的地址有了，目标地址也有了，但是不能指定协议和端口。如果加了协议和端口项应该可以实现的功能会多很多。

像原有的“强制客户端DNS代理”，就是把LAN的udp53端口的流量劫持转发到本机。

像原有的“第三方DNS代理模式”，就是把LAN的udp53端口的流量劫持转发到指定服务器并排除这个第三方DNS服务器。

为什么局限性要这么强呢？

小老弟

Water 发表于 2020-6-2 22:12
像ros防火墙的nat那样什么都可以自定义，虽然复杂，但是功能强大。

爱快的端口映射就真的是个映射，够 ...

感谢建议！产品的易用性和功能的灵活性我们也是一直在做取舍，功能做的灵活且复杂肯定能满足部分资深且爱折腾用户，但是可能会牺牲了另一部分用户（可能是大部分用户）的操作体验和使用门槛；另外一个原因是我们开发资源是有限的，但是用户需求是各式各样且源源不断的，正常情况下（项目需求例外）我们会优先评估能满足大部分用户的功能需求，尽量做到对用户需求的及时响应；
所以我们在评估时尽量做到满足用户普遍的应用场景，然后将功能做到简单易用；在需求板块我们一直希望用户能够结合实际的使用场景来描述需求，这样我们评估功能的时候也会更加明确；