wyxls

哇，注册给了 3000 金币

装个 Listary 或者 everything ，推荐 Listary ，不想付费就去找学习版，不放心就去 52pojie 那找学习过程自己解题，付费验证意外的好解

不太想动群晖自身预设好的 DSM 服务端口（ 5000 和 5001 ），因为我不知道这魔改系统会不会 hardcode 某些网络端口，改了可能会有奇奇怪怪的问题，之前就碰到过改了 drive 的服务端口导致在 DSM 界面跳转过去端口不对的情况

目前方案是防火墙只允许几个 web 服务端口出口以及局域网内一个堡垒机 IP 入口，其他 web 服务都通过堡垒机反代接入并透传真实客户 IP ，最后 fail2ban 条件拉满，7 天内连续 3 次失败直接永久封锁

个人推荐 PVE ，底层 debian ，想折腾原生软件服务就开一个 LXC 容器，想折腾其他的也能通过虚拟机跑起来

@mrlfishman
六七年前的路由硬件 NAT 应该不太够用，p2p 下载除了大量的硬盘 IO 和网络带宽压力，还有点对点大量连接处理压力，力大砖飞换网口和吞吐能力强的路由肯定能缓解

不过我的做法是在 NAS 里跑一个 win 虚拟机，然后乱七八糟的 win 版网盘、软件都往里边扔，这样可以把路由带宽压力转移到 NAS 的硬盘 IO 上，直接用 windows 的 RDP 或者套个 noVNC ，也方便随时进去远程管理

@shakukansp tailscale 的 admin console 里，192.168.0.0/23 这个路由表 approve 了没？

我刚好也在研究这问题，现在通过 AI 和搜索引擎找了两个方案，假设子网 A 为 10.36.13.0/24 ，子网 B 为 192.168.31.0/24：
1. 在 tailscale 通过配置 ACL ，针对客户端分组 tag 之后，注释掉默认 accept all ，改为设备到子网的逐一维护允许，比如{"action": "accept", "src": ["tag:A-devices"], "dst": ["B-subnet:*"],}
2. 在 subnet router 那维护静态路由表，比如 B 网关配置 192.168.31.0/23 to 10.36.13.0/24 ，这样局域网内 IP 通过网关访问 B 网，B 网优先级会胜出

码农有动手能力建议考虑虚拟化系统或者自由度比较高的 NAS 系统，比如 esxi 、PVE 、truenas ，主动权都在自己手里

想省事就黑群晖、飞牛 OS 之类的成品，缺点是官方怎么改，你只能选择不更新或者更新，像群晖之前就砍掉了 photos 的 HEVC 编解码功能，扔给客户端处理了，哪怕 NAS 本身有核显硬件加速

上面的说得差不多了，群晖后端的 docker 本身也遵循规则，不支持编辑更改端口、路径映射之类的，群晖只是做了个 manager 让你以为能改，实际上更改保存还是删掉容器再重建

其次 DSM v7.2 后 contrainer manager 提供了 compose 界面，建议还是逐渐改成用 compose 部署吧，或者干脆 ssh 进去 sudo docker-compose

以前只能单个容器点点点下一步太麻烦了