在把 IPsec 换成 Shadowsocks 之前，先把丢掉的工作列出来

三个服务，一条隧道：一个 Web 应用、一个数据库、一个文件共享。有人提议把 IPsec 换成 Shadowsocks，理由是更好维护。随后的加密算法之争跑偏了重点，因为这条隧道同时在干好几件事，只有一件跟密码有关。先把这些工作写下来，再比较产品。清单很短，任何一项都可能让这次替换失效。

先从流量怎么被捕获说起

这个协议分两半。本地组件接受连接，把以目标地址开头的流加密后发给远端组件。远端再向该目标建立连接，转发字节。UDP 用数据报走同样的形状。这是对它捕获到的流做转发，而对没捕获到的流什么也没说。明确会讲代理的应用很好办；其余应用必须靠适配器或路由规则才能被捕获。

先把每个应用的捕获方式记录下来，再谈别的比较。没被捕获的流量会走普通路径，直到某个服务在办公室外表现异常才有人察觉。

把每个目标和协议都点名

远端必须能到达每一个内部服务。到那台主机有一条可用的加密会话，并不会因此多出一条通往数据库的路由，也不会让内部名字在客户端解析。与其写「包含局域网」，不如把地址、端口和协议列清楚。

把破坏整洁设计的情况补上：内部 DNS、无视代理设置的应用，以及任何必须从服务器向客户端发起的流。每一件都需要明确安排，而不是假设。

加密不等于授权

Shadowsocks 文档中列出的 AEAD 方法提供的是带认证的加密，所以把整个家族说成不安全是错的。用这个事实去回答访问控制问题，同样错。谁访问哪个服务、人离职时权限怎么收回、密钥放在哪、由哪个组件守住边界，这些都得有人来定。只有一个共享密钥时，每个持有者的范围都一样，一个人离开就变成所有人一起轮换。

用同一把尺子量现在的 IPsec 配置。它的名字不能证明规则是对的，拿一种设计打磨过的版本去比另一种设计含糊的版本，什么也定不下来。

把今天两边都有的控制项列出来，再判断哪些缺口你可以接受。

把运维工作数清楚

任何替换都需要有人负责客户端软件包、服务器更新、凭据轮换和故障处理。留意隧道不可用时每个应用会怎样：失败、改走本地路径重试，还是等待。这种行为来自部署方式，而不是协议名字。

只有一个 Web 应用时，一个窄代理可能就够。要按人授权访问整个网络，额外部件通常比被替换掉的隧道更贵。

要决定的不是哪个产品听起来更安全。而是哪种设计能用团队真会维护的控制项，把列出的工作做完。