我认为 “免费软件就可以为所欲为，爱用用不用走人” 的讲法是不对的。按这个逻辑，超市里那些免费试吃的食物，一些免费的赠品就不用承担产品质量责任了？又或者反过来讲，“你厂家要免费什么心态我不管，我消费者抱怨你就得受着，不爱听就别免费” 这样也可以？

产品和用户都要有底线，总是通过相互给对方泼粪，或者通过能相互泼粪的威慑来达到一种微妙的平衡，然后凑活过日子，不累？

@moguiyu Arq 5 还真的不错

Mountain Duck 或者 cyberduck，这俩一家出的，用法不一样，前者也不是免费的。支持多种网盘或者对象存储，支持端对端加密，而且核心代码都是开源的。用这俩 + S3 + S3 版本控制 + S3 异地同步 + 本地有一份，不能更安全了。而且 S3 作为备份，可以考虑设定生命周期，一段时间后转为冷存储，节约成本。

这样唯一的缺点是这种端对端加密换密码很麻烦。也可以考虑一些现成的端对端加密网盘方案，比如 Tresorit 这种。优点是开箱即用，容易更换主密码，可以共享文件。缺点是透明度没上面那样高，小容量存储成本也高一些。

对了，在补充一点。请不要眼红大容量，用过各种云就知道，存储空间和带宽都非常昂贵，天下没有免费的午餐。首先国内这些网盘在信守承诺方面都没什么说服力，容量说变就变，产品说没就没。此外这么大的容量，这么低的价格必然是超卖。超卖没什么，大家都超卖，但得适可而止，而且技术上也要有这精钢钻不是？否则大规模超卖本身就是对数据的一种威胁。

存储重要资料的话，微云百度云还是不要了吧。个人认为这些云是面向娱乐而不是面向生产的，也不知道他们内部怎么定位自己的产品。主要还是有这些问题：

1. 账号安全。无论 QQ 号，微信号还是百度账号，其安全设计我一直都摸不透，什么密码，安全问题，安全助手，手机号，身份证号，安全邮箱，账号申诉相互嵌套。说到底是手机号为主？但是账号申诉又算怎么回事？对个人而言，反而是只用账号密码更可控。

2. 传输安全。比如微云网页端支持 https，但不强制。所以客户端呢？

3. 数据安全。据网友反应，微云有文件传上去下不来的情况，百度云就不提了。实际上，比如坚果云，除了时间积累的口碑外，在他的主页上还可以看到很多使用他产品的企业，国外知名的网盘也可以看到很多商业实体使用他们的服务。我认为这也是面向生产的一种表现。总不能说你的网盘很好，内部也很重视这个产品，结果没有一个严肃的客户？

4. 重要数据安全功能的缺失，比如说版本控制。营销味道太重，比如微云的保险箱，算什么呢？也不是端对端加密，感觉强行新功能。对待会员和非会员，除了空间比较明确，其他方面的限制都很模糊，比如带宽，非会员可以慢，但到底是多少总该有个数吧？不然怎么拿来用？到时候我要同步工作文件你就给我 5k/s ？

5. 隐私条款，服务条款不被强调。对待用户数据界限暧昧，动手删用户网盘里的文件？！

所以如果以年为单位保存重要数据，并且对隐私还有要求，我觉得使用一款行业认可的商用网盘才行。Onedrive 个人版可以，商用版更好，国内也没被 q。如果有条件稳定出 q，我推荐 Dropbox，用下来还是这款最可靠。

可是我的 S8 港版系统支付宝可以用指纹啊。

另外，googleapis.cn 和 googleapis.com 服务器不一样。美国那边解析出来的 googleapis.cn 可以用，你可以试一下 hosts 解析到美国那边的服务器。

ping 一下 baidu qq 之类的看下丢包和延时的稳定性。你这种情况我怀疑可能是 DNS 不行，换个 DNS 试试。

我个人的看法是，除非清楚自己在做什么，否则自己搭建的这种系统，其安全性远不如商用网盘。首先，可用性和容灾就没法比，这两点是最基本要保证的。其次，就保密来讲，商用系统的管理怕不是甩了个人和小团体 n 条街。而且，自己搭建系统，除非硬件在自己手上，而且数据传输到设备中间不经过任何解密，否则还是要信任第三方，而个人对第三方的控制能力和大公司也没得比。

所以我个人的建议是，选择信誉好的商用网盘。如果保密性要求高，应该选择支持端对端加密的网盘，或者通过第三方软件实现端对端加密。保存好一个强密码，比管理好一整套网盘系统简单多了不是？

我个人的经验是 Current Branch for Business + 功能更新延迟半年以上 + 质量更新尽快安装 就挺稳定的。容易出问题的一般是功能更新，质量更新对于安全至关重要（ >> 杀毒软件），仅供参考。

@acess 对了，WAN 口上默认是有 MASQUERADE 的吧？这可能是 WAN 口成功的原因。

@acess 不行的话，你先尝试一下把其他自己添加的规则删掉，在一个干净的表上单独尝试这个规则，排除干扰的可能。此外你要不试一下把 ! -o lo 删掉？我还是没明白这个规则怎么改的出 Localhost

@acess 还有我没看懂，按说 REDIRECT 应该重定向到 incoming interface，你的第一行命令里已经 ! -o lo，为什么请求包会被定向到 127.0.0.1:5301?

@acess 抱歉没审清楚题目，那么下面这个能工作么？

iptables -t nat -A OUTPUT \! -o lo -p udp --dport 53 -j DNAT --to-destination 127.0.0.1:5301

需要 tproxy 模块

hsts preload 可以在一定程度上缓解这个问题。

我最不能理解的是关了 UAC 然后装杀毒软件，这是假装自己重视安全？

没有允许 related,established 链接吧，重启不行的话，只能控制台了，再没有就重装吧。

使用 U 盾作为认证工具，基本可以消除用户方面凭证管理所引起的安全问题，一般可以认为用户签名必然源于用户对应的 U 盾，所以 U 盾签名是非常权威的，主要也是方便了用户。但这只是安全管理中的一环，验证逻辑、数据保护和设施安全还有很多其他与之独立的问题。