Nextcloud 仅限 VPN：先盘点每一个入口

仅限 VPN 的 Nextcloud 方案若只保护浏览器而忘记同步客户端，就会失败。网页、桌面同步引擎、移动端上传、WebDAV 工具和共享链接接收者都需要通往同一服务的路径，而且每一个都可能暴露不同的入口。在关闭任何东西之前先盘点它们。那份清单才是真正的边界。

按顺序执行清单。第一项定义私有对本部署意味着什么；后续各项检验部署是否真正符合该定义。

在改变边界之前先定义私有

用一句话写下要求：每个用户必须先加入 VPN 才能访问应用，或者应用可以保持公开而其源站保持私有。这是两种不同的设计，而把流量转发进私有隧道的公网反向代理只满足第二种。

私有后端地址并不会让应用变私有。如果公网映射、第二个主机名或 IPv6 监听仍然能到达同一个 Nextcloud 实例，那么无论后端在哪里，入口都存在。在宣布服务私有之前，从外部逐一测试每个名称。缺少 DNS 记录并不等于端口已关闭。

还要就目标受众达成一致：员工、一个家庭、合作组织或部分账号。答案决定了公开共享链接是功能还是矛盾。把该受众写入访问方案。它是随后每个例外的检验标准。

列出公网地址映射、反向代理、备用主机名、IPv6 监听以及任何能到达该服务的隧道或网格地址。把解析到这些地址的名称也一并列出，因为被遗忘的 DNS 记录就是一个带着友好标签的入口。

检查代理配置中的转发头和备用服务器块。为另一个应用添加的代理可能通过某条路径或残留的虚拟主机暴露同一个上游。读实际配置，而不是设想的架构图。两者在应用迁移之后最容易出现分歧。

然后封堵你没有选择的入口。带公网前端的私有后端不是仅限 VPN 的设计，而只覆盖 IPv4 的防火墙规则会让 IPv6 监听保持开放。在同一次变更中关闭两个协议族和两个名称。

把私有 DNS 指向该服务，让该名称经 VPN 路由，并为它签发证书。名称必须通过私有路径解析并在没有警告的情况下通过验证。直接访问 IP 的客户端仍然需要名称可用。

通过无关 IP 地址连接的客户端不应为了跑通设计而不得不忽略证书错误。稳定的名称还能防止同步客户端在地址变化时创建重复的服务器条目。这就是私有服务与私有 IP 的区别。

保持证书验证开启。私有网络减少暴露面，但不会让未经校验的 TLS 连接变得可接受，而一个习惯于忽略警告的客户端在其他网络上也会忽略警告。

允许已登记用户访问 Nextcloud 服务及其必要依赖，并把服务器管理留在单独的路径上。一个把客户端放进整个家庭或办公网络的 VPN，给该客户端的东西远远超过应用所需。

VPN 准入不能替代 Nextcloud 账号、权限或额外认证。哪个用户能读哪个文件仍由应用决定，网络层不应是唯一的控制。

记录批准的来源范围和服务器端口。目标方需要观察到的来源，而 NAT 或代理可能在请求到达应用之前改写它。

桌面同步和移动端上传会各自在各自的时间建立连接。它们在连接时需要批准的私有路径，而在缺少 VPN 时行为可能不同：重试、暂停或报错。逐一测试，而不只是浏览器。

WebDAV 工具以及日历或联系人客户端是各自独立的集成，有自己的配置。缓存了公网 URL 的客户端在边界变更后仍会继续尝试该 URL，而失败看起来像应用问题。

共享链接值得一个明确的决定。链接不会给接收者 VPN 访问权限，因此在真正仅限 VPN 的设计中，外部接收者即便链接有效也无法使用。如果确实需要对外共享，那是一个带独立访问路径的刻意例外，而不是事后才发现的疏漏。

联邦和服务器到服务器的集成也需要同样对待。它们是安装之间的可达性关系，而仅私有的部署必须说明是否支持它们。

从已批准的客户端，检查网页界面以及一次普通的文件上传或下载。然后检查一个同步客户端和一个非浏览器工作流程。仅在浏览器中成功不算验收。

从未批准的路径，确认通过清单上的每个入口都无法访问该应用。测试备用主机名和 IPv6 地址，而不只是主 URL。

最后审查那些容易与网络策略混淆的应用设置。trusted_domains列出实例接受哪些名称；它不是客户端 IP 白名单。如果反向代理提供地址信息，trusted_proxies必须写明真正的代理，并且只应接受它传来的转发头。

在网络变更的同时继续日常加固：让数据和备份远离非预期的 Web 路径，为应用打补丁，保护管理员访问，并保持恢复可用。VPN 去掉一层入口表面；它不会让已登记的客户端变得可信。