获取单个文件不需要完整的网络 VPN

VPN 访问申请背后往往只藏着一个文件夹和一个文件。授予通往整个办公室网络的路由虽然回应了申请，却交出了远超任务所需的东西。用上传页面取代映射共享，在另一个方向上可能同样错误，因为它改变了人们的工作方式。决策应从文件需要经历什么开始。

这里有三类需求看起来相似，行为却截然不同：复制一份已完成的 PDF、就地编辑文档，以及让应用直接访问共享目录。

从编辑入手，而不是文件夹

如果文件已完成且只需阅读，传输账户就足够。如果要编辑，问题就变成还有谁在编辑、冲突如何解决，这属于工作流问题而非网络问题。如果应用直接从目录打开文档，存储层的延迟和锁定行为就很重要。先回答这一点，可以避免一种连接完美却仍然无法使用的方案。

共享编辑带来任何传输都无法解决的问题。用户下载电子表格、离线编辑，在别人改动原文件后再上传，而加密连接对覆盖操作没有任何意见。关于覆盖、冲突或版本管理的约定必须先于访问方式存在。

SFTP 是传输协议，不是共享

SFTP 通过加密的 SSH 传输移动文件，这正是复制所需要的，而不是映射驱动器所需要的。它不是 FTP，提供 FTPS 的产品提供的是另一种协议，而不是 SFTP。通过文件系统层挂载 SFTP 目录，并不保证原共享的锁定、权限或应用行为。在称之为直接替代之前，请检查客户端应用的要求。

sftp [email protected]
put report.pdf /upload/report.pdf
get /shared/template.docx

这就是完成文件所需的全部工作流：连接、放置、取回。仅用于传输的账户也需要受限的 SSH 服务，而不只是文件系统。chroot 或 ForceCommand internal-sftp 限制会话可以运行什么，禁用 TCP 转发和隧道则堵住了那些本会把文件账户变成网络入口的路径。只限制可见目录，并不能证明该账户能到达什么。

如果需要共享，就不要公开它

有时原始共享确实是需求，而答案并不是把 SMB 暴露给任意互联网客户端。Microsoft 的建议是在边界阻断直接的 SMB 流量，理由充分：该协议并非为面对不可信网络而构建。存在 SMB over QUIC 和类似设计，两端都有特定的平台要求，它们并不是适用于任意 Samba 服务器的通用开关。如果两者都不适用，工作就是提供受支持的访问路径，而不是转发端口。

基于浏览器的方案在工作适合时是合理的第三答案。它带来自己的决策：账户、共享链接、到期、保留版本以及哪份副本具有权威性。任何人都能打开的链接和需要登录的工作区代表不同的访问策略，两者都不应被偶然选中。

移交访问权限前要核实什么

sftp [email protected] <<< "get /shared/template.docx /tmp/probe.docx"
ssh [email protected] "cat /etc/passwd"

无论选择哪种设计，都要把它限定在预期的数据和预期的操作上。第一条命令应当成功，第二条应当被拒绝；如果两条都成功，账户就比任务更宽。然后删除账户并重复第一条，此时应当失败。保持源文件所有者可识别，以便日后关于权威副本的问题有答案。值得记录的结果是可使用且可撤销的文件工作流，而不是缺失的连接图标。

写下用户应用实际需要哪种协议，以及你运行了哪三项测试。这两行能防止大部分返工。