围绕标准WireGuard客户端建立小型VPN服务而不是专有应用程序的经验教训 当看一看商业VPN产品时,该应用似乎就是产品:一个被打磨的界面,一个国家列表,以及一个大型的"连接"按钮.
我选择了相反的方法。
与其建立另一个VPN客户端,我决定给用户一个标准WireGuard配置,让他们可以导入到现有的客户端.
这一决定取消了很多客户端的工作——但它也暴露了VPN服务的实际复杂性所在.
如果WireGuard已经拥有了,为什么还要建立另一个应用程序?
通常的商业VPN流量是直截了当的:安装供应商的应用程序,签入,选择位置,并连接.
一个专有客户端可以在一地管理服务器的选择,订阅,杀死开关,自动重接,诊断,更新和支持.
但对于一个或几个位置的小型服务,我不得不问一个更基本的问题:我是否真的需要建造和维护一个单独的Windows,macOS,Android,以及iOS客户端,只是为了建立一个WireGuard隧道?
WireGuard已经拥有跨主要桌面和移动平台的成熟客户端.
用户可以导入配置文件或扫描QR代码并获得普通的VPN切换.
在纸上,这看起来是一个非常有吸引力的取舍:客户端代码较少,更新机制较少,安装器较少,需要维护的攻击表面较小.
我低估的是 应用程序永远不会是最难的 .conf 文件不仅仅是一个设置文件 最初的建筑课程很简单,但很重要:线导配置实际上是一种证书。
它包含客户端的私钥.
一个代表同一种配置的QR代码以另一种形式包含相同的敏感材料.
这立即造成了与隧道本身无关的产品问题.
如何安全显示配置?
如果用户丢失了怎么办?
你能在不离开旧对等器的情况下发布替换吗?
你怎么可靠地取消访问?
当用户创建多个配置时会发生什么?
一旦涉及付款,这种配置也成为生命周期的一部分。
它可能处于待决,活性,过期,被替换,被撤销,或与未支付有关.
一个支付提供者可以同步发送回调,当一个对等点被添加到VPN主机时,那就是真正的网络访问——不仅仅是数据库中的一行. “生成一个配置并显示一个QR代码”的所谓简单流动迅速变成一个小型的国家机器。
线盾很简单 周围的服务不是。
我对WireGuard有一点喜欢 就是它保持专注 它在加密身份之间创建了加密地道,并配合了路由.
它不尝试解决订阅,账户恢复,客户支持,支付状态,密钥发行,或用户体验.
这种分离是很好的建筑,但是在早期的原型化过程中可能会引起误解.
你可以很快提出一个工作隧道, 并感觉好像大部分工程都完成了。
就我而言,隧道是容易的部分。
使周围的系统能预测到行为是真正的工作。
用户无需知道有VPN主机,网络服务,数据库,配置生成器,以及幕后同步支付回调.
他们的心理模式应该保持简单:支付成功,访问工程;支付失败,访问不活动;更新成功,不需要其他东西. “连接”与“正确配置”不同 另一组问题出现于路由和泄出.
一个客户端可以显示“ 连接” , 而整个网络行为仍然是错误的 。
公共IPv4地址可能会改变,同时DNS请求仍然去出乎意料的地方.
或者IPv4可以在IPv6通过直通道离开时使用地道.
这改变了我测试服务的方式。
成功的线卫一握手是必要的,但这还不够。
我也检查了阴道