如何将 LAN 中设备发往公网指定 domain:port 的 HTTPS 请求重定向到 LAN 中指定设备的 ip:port

[dLvsYgJ8fiP8TGYU]

背景： 家中运行一台 NAS，为实现从公网（使用移动数据）访问，已通过一台拥有公网 IP 地址的云服务器配置端口转发服务，并申请了域名及 SSL 证书，目前运行良好。

用 PPT 画了个网络拓扑： https://i.imgur.com/0yGEJ6C.png

在外面使用移动数据连接家里的 NAS，需要访问云服务器的指定端口（示例： https://nas.example.com:12345 ），在这一过程中需要消耗云服务器的流量（废话）。

如果我回到家里，在局域网中访问上述 domain:port，依然可以成功连接 NAS，但还是需要消耗云服务器的流量。这部分流量其实消耗的有点冤，毕竟已经在同一个 LAN 里面了，按理说可以直连的。这样子不但多交钱，延时也增加了。

问题： 是否可以通过某种方式在局域网中重定向发往 nas.example.com:12345 的请求，使其无需经由云服务器中转而直接发往局域网中的 NAS 的指定端口？

1. 尽可能避免用户在设备端进行操作，如记住不同的 ip:port，在网络环境变化时手动输入（可行，但用户操作不便，排除）

   • 我个人其实无所谓，主要是考虑到家里其他人不太懂计算机 /网络这块，

2. 已经尝试过以下方案，效果均不好

   • 修改 hosts
     • 在 iOS 设备基本不可行，且离开局域网即失效
   • 在 NAS 上搭建基于 AdGuard 的 DNS 服务器
     • 在网络环境变换时，比如出门 /刚回家，可能是由于 DNS 缓存，不能实现无缝无感切换
     • 改 DNS TTL 有用吗？

3. 可能可行的其他方案？

   • 路由器设置策略路由或其他某种设置
     • 对现有硬件改动最小。TP-LINK 企业级路由器，不清楚是否支持这样操作
   • 新增一个软路由？
   • 在 iOS 上运行某种支持通过判断当前 SSID 并修改请求的软件？

4. NAS 用的是群晖，5001 是 HTTPS 端口

5. 如果能实现 IP 地址重定向，但无法同时实现端口重定向，可妥协

   • 在 NAS 也开启 12345 端口，与云服务器端口号实现同步，并允许相应服务使用此端口
   • 云服务器端口需保持至少 10000+ 高位，以保证安全

[jim9606]

如果不满意 dns 劫持的效果，我建议用 iptables dnat+snat，不过企业路由能不能支持类似功能我是不清楚了。

不过你用群晖的话 QuickConnect 好像就可以自动判断是否处于内网并自动做 301 跳转。通过浏览器 js 进行检测。

[Maskeney]

iptables 之类的方式劫持你的公网小鸡 IP 重定向到局域网 IP 上

[Lemeng]

可以，画拓扑图的点个赞

[la0wei]

@tankren 我的方案优点在于用户对修改无感知，低门槛。建导航的方法也是极好的，对习惯用浏览器的用户比较友好，但是对客户端要求比较高。
我为何研究这个方案，因为之前我有加速下载的需求，奈何 http 不能很好的利用我宽带的多拨叠加带宽，而 http 下载工具支持镜像功能的很少，还需要大量的手工操作，忒麻烦，才催生出这套方案。
靠手工配置确实可以解决问题，但是都太麻烦了，还是中心化的解决方案比较方便，一劳永逸。
另外我的方案和导航式的并不矛盾，可以很多好的融合

[piku]

问题我懂了。但下面回复的我没理解。
在家里还是用的域名吧。域名还是指向的公网 ip 吧。这就是简单的内网域名访问回流问题啊。
在家里网关路由器上做两条。先 dst-nat 把访问公网 ip:端口的重定向到内网 ip:端口。
然后 src-nat 把这部分流量 masquerade，否则回流有问题。
有的路由器直接有内网服务器选项，自己能处理回流。

[hanguofu]

请问如何在 局域网内输入自定义的名字就可以访问同一个局域网内的其它设备啊？

[tankren]

@la0wei #24 我自己也是用的 pfsense+HAproxy 用了好几年了 问题是楼主没有公网

[la0wei]

@tankren #52 没有公网不影响吧。公网访问楼主已经自己实现了，你看原文。内外网原理是一样的，细微差别而已。
1.公网是公开的 dns 解析，内网是路由器自定义 hosts 实现，两者都实现了域名到 ip 的转换。
2.端口部分，我猜楼主用的是 frps：内网有个客户端，主动连接外网服务端保活，服务端转发到客户端实现对内网的访问。frps 和 haproxy 不深入探究原理的话，在这个例子里最根本的区别在于 frps 是反弹式的。

具体实现是否有问题还是看楼主操作后再看看。

有一个情况我觉得建导航的方式也是非常不错的，甚至部管端口，不一样就不一样。别在在手机上访问时没关流量，看电影把房子送给移动了。内外网有显著差异还是不错的，能提醒自己切换网络。

[la0wei]

@tankren @piku 这个解释也是靠谱的

[joesonw]

路由器 ip tables.

[la0wei]

@tankren @piku 确实非常接近典型的 nat 回流问题，也启发了我。区别在于楼主的情况还是有不一样的，他没有公网 ip，防火墙 /路由器默认的的 nat 回流设置需要替换外网 ip 地址，需要设备支持命令行及 iptables

在路由器有公网 ip 的情况下，可以充分利用设备特性，此时不需要添加任何设备，不需要任何命令，全图形化操作。

tp-link 企业级路由器示例：问题描述及解决方法 https://blog.csdn.net/x55x5/article/details/86146915

不过 nat 回流只解决了 ip 的问题，没解决端口。不过咱可以修改内网端口，内网改成 12345 就好 https://serverfault.com/questions/592254/how-to-configure-synology-to-use-only-standard-http-ports-80-and-443-instead-of

路由器没有公网 ip 的情况下，我建议路由器自定义 hosts，同时修改群晖端口为 12345 。
这个方案应该是最精简的了。不需要添加任何设备，不需要任何命令行操作，避免了设备限制（自定义 hosts--路由器大概率支持，修改端口--群晖大概率支持）。

最终结论：路由器自定义 hosts，同时修改群晖端口为 12345

[la0wei]

#31 群晖修改端口 serverfault.com/questions/592254/how-to-configure-synology-to-use-only-standard-http-ports-80-and-443-instead-of

[no1xsyzy]

话说，DHCP 下发路由表，使得公网 IP 导向群晖，然后在群晖上添加这个 IP （使得它收到 DST=IP 的包的时候自己消费掉），这也可行吧，就是挺邪门的。

甚至流量不用经过路由器？

[no1xsyzy]

@no1xsyzy 哦，发现一个问题，那样的话内网包括 frpc 都连不上公网的那个 IP 了

[no1xsyzy]

@la0wei #28 结合到说室内忘记关流量的问题，我觉得 VPN 回家是最好的。
在家里，移动设备直接关掉 VPN 。

[dorothyREN]

是什么原因让你认为高位端口就安全了

[julyclyde]

如果端口相同且本来要访问的那个 IP 地址不变的话
直接在网关加路由，目标为本来要访问的，下一跳为实际访问的，然后在实际访问那个服务器上增加那个本来要访问的 IP 地址就行了
你需要考虑的是怎么搞到人家的 SSL 证书

[la0wei]

@julyclyde 楼主的群晖默认访问端口是 5000( http)、5001( https)，这是群晖出厂的默认配置，应该是内置的证书。haproxy 的 tcp 模式可以直接使用目标服务器的 ssl 证书，本地不需要特别的配置，这也是我推荐 haproxy 最主要的原因。
@no1xsyzy 手工配置还是挺香的，我倒又产生个想法，如果经常电脑访问，透明的方式比较好，app 访问多的话，完全可以装两个功能类似的 app 做隔离。

[julyclyde]

@la0wei 用 haproxy 也同样存在证书和地址对不上的问题。这不是怎么转发的问题，而是转发之后怎么识别的问题

[la0wei]

@julyclyde 根据我个人非常浅薄的经验，没有遇到证书的问题。我在外网有个服务器，使用 cloudflare 反代，内网将域名指向一台 linux 设备，并在 linux 上使用 haproxy 转发。
PC-->局域网 haproxy-->cloudflare-->服务器

对于 let'encrpt 证书可能会出现问题，因为确实 ip 和地址不一致，但我认为可能出问题的是在签发阶段，ip 和域名不匹配，这个很容易理解。而签发完成后，证书是否能够用在别的服务器上，这点我就不清楚了。毕竟证书只关乎公私钥，ip 是否严格限制就不知道了。而 cloudflare 证书实测可行。

但我理解 haproxy 只是转发 tcp,证书还是从服务器获得的，对于局域网来说依然是原始 ip 和证书，出问题的可能性不大。

我内网没有类似群晖已经签发 https 证书的设备，暂时无法测试可行性。