☰

为不同客户端设置多个 OpenVPN 实例的最佳实践

tag-icon • tag-icon linux vpn openvpn pki
为不同客户端设置多个 OpenVPN 实例的最佳实践

我正在做一个项目，需要设置 OpenVPN 实例，以便将来自不同客户的 IoT 设备连接到中央服务器。每个客户端都应该有自己的独立 VPN 连接。我目前正在规划基础设施和证书处理，希望得到一些关于最佳方法的建议。

对于证书处理，我正在考虑以下结构：

CA.crt
|_Customer1.crt
|  |_ServerCert.crt
|     |_ClientCert1.crt
|     |_ClientCert2.crt
|     |_ClientCertX.crt
|
|_Customer2.crt
   |_ServerCert.crt
      |_ClientCert1.crt
      |_ClientCert2.crt
      |_ClientCertX.crt

因此，我将为每个客户端设置一个单独的 OpenVPN 实例，例如/etc/openvpn/server/Client1/和/etc/openvpn/server/Client2/，并使用以下命令启动它们：

sudo systemctl start [email protected] 这是可以接受的方法吗？对于如何为多个 VPN 客户端和服务器组织基础架构，我将不胜感激。

其他问题是：

  • 如何管理大量分散的设备，也许是 Ansible？
  • 对于每个 OpenVPN 实例，我需要一个额外的端口。
    • 使用 443 TCP、UDP 和 1194 TCP、UDP 后下一步是什么？

谢谢你！

答案1

OpenVPN 手册指出，它将信任任何属于您在其中配置的 CA 证书的后代证书。因此，要真正分离 VPN，您需要从所有配置中省略根证书。它不会在任何地方使用，不会增加任何价值或好处，那么为什么要维护它呢？只需使用 EasyRSA 并为每个 VPN 创建一个单独的、独立的“根、单级”CA。

我不知道您为什么在这里列出端口 443；它很少用于 OpenVPN，因为它是众所周知的 HTTPS 端口，并且经常被占用，因此使用它时，通常需要进行涉及的棘手配置port-share。在这种情况下，sslh更胜一筹，至少因为您可以使用它的“透明模式”让守护进程查看远程的真实 IP，而不必担心 OpenVPN 提供该信息的方式。不过我怀疑您的项目是否需要这种特性。除此之外，您真的可以使用任意端口号。1194 被列为“官方”，但没有什么禁止您设置 11941 或 1195 或 5000（这是 15 年前提出的）或其他任何端口号。选择一组端口，假设从 1194 开始，然后为每个连续的 VPN 实例添加一个。

其余部分是正确的：您为独立守护程序使用单独的（公共）端口，并将它们作为单独的 SystemD 单元运行。考虑为不同的 VPN 使用单独的容器：虽然可以在单个命名空间中运行单独的 VPN 实例，但直接拆分它们更容易且不容易出错（并且不会消耗太多资源）。据我了解，您的客户是不相关的实体，因此这将是更直接的分离它们的方法。在这种情况下，容器内的 VPN 配置可能会使用默认端口，但您将为它们转发（发布）不同的端口。

指定某个系统专门用于管理 VPN；它将存储您的 CA，因此只有它才能颁发证书。该系统还需要颁发 CRL；默认情况下，CRL 的有效期为 30 天，如果您进行配置crl-verify（您会！），当 CRL 过期时，VPN 将停止接受新连接，直到它再次有效。因此，您真正需要自动化的是 CRL 的重新颁发和分发。更新 CRL 文件时，您不需要重新加载守护程序，因此只需简单地将scp旧文件复制到目标系统即可。

创建 OpenVPN 客户端配置文件模板并从该模板生成带有嵌入式证书的客户端配置很有用；即使没有 Ansible，这也为我节省了很多时间。我经常自定义捆绑openssl.cnf和vars文件以添加几个字段并删除未使用的字段，并重新组织内容并使其运行时出现更少的问题（或没有问题，用于批处理）。对于您的情况，拥有此类模板和生成脚本对于创建新 VPN 和服务器配置也很有用。此类模板、脚本和自定义将对实例化新客户或现有客户的新 IoT 设备的 Ansible 剧本很有用。对于后者，将证书的 CN 与 IoT 设备的序列号绑定在一起可能会很好，这应该可以简化会计工作。

相关内容