管理防火墙后面的 Linux 计算机集群

Question

我公司的产品本质上是一个 Linux 机器 (Ubuntu)，它位于其他人的网络中，运行我们的软件。到目前为止，我们在野外只有不到 25 个盒子，并使用 TeamViewer 来管理它们。

我们现在将运送 1000 个这样的盒子，而 TeamViewer 不再是一种选择。我的工作是找出一种访问这些盒子并更新它们上的软件的方法。这个解决方案应该能够穿透防火墙和你有什么。

我考虑过：

1. 自行开发的解决方案（例如 Linux 服务），它建立到云中服务器的SSH 反向隧道，以及云中的另一个服务来跟踪这些并让您连接到它们。

这显然是劳动密集型的，坦率地说，感觉就像重新发明轮子，因为许多其他公司肯定已经遇到过这个问题。即便如此，我不确定我们会在这方面做得很好。

2. puppet、chef 或 OpenVPN 等工具

我试图尽可能多地阅读，但我似乎无法通过营销演讲足够深入地理解显而易见的选择。

除了我们之外，没有其他人需要连接到这些盒子。有没有相关经验的人可以给我一些指点？

Answer 1

拉取更新，不要推送

随着规模的扩大，对所有产品进行推送更新将变得不可行。

• 您必须跟踪每个客户，每个客户可能都有不同的防火墙配置。
• 您必须通过客户的防火墙创建传入连接，这将需要端口转发或其他一些类似机制。这对您的客户构成安全风险

相反，让您的产品定期“拉取”它们的更新，然后随着您的增长，您可以在服务器端添加额外的容量。

如何？

这个问题已经解决了，正如你所建议的。这是我能想到的几种方法。

• using apt：使用带有自定义 PPA 和源列表的内置 apt 系统。如何设置 PPA？
  • 缺点：除非你使用像 launchpad 这样的公共托管服务，否则设置你自己的 apt PPA + 打包系统不适合胆小的人。
• using ssh：为每个产品生成一个 SSH 公钥，然后将该设备的密钥添加到您的更新服务器。然后，只需拥有您的软件rsync/scp所需的文件。
  • 缺点：必须跟踪（并备份！）您发送的每个产品的所有公钥。
  • 优点：比原始下载更安全，因为只有安装了公钥的设备才能访问更新。

• 原始下载 + 签名检查：

  • 在某处发布签名的更新文件（Amazon S3、FTP 服务器等）
  • 您的产品会定期检查要更改的更新文件，然后下载/验证签名。
  • 缺点：根据您的部署方式，这些文件可能是可公开访问的（这可能会使您的产品更容易被逆向工程和破解）

• ansible：Ansible是用于管理系统配置一个伟大的工具。它属于 puppet/chef 领域，但无代理（使用 python）并且设计为幂等的。如果部署您的软件需要复杂的 bash 脚本，我会使用这样的工具来降低执行更新的复杂性。

当然，还有其他方法可以做到这一点……但这让我想到了一个重要的点。

签署/验证您的更新！

无论您做什么，都必须有一种机制来确保您的更新不被篡改。恶意用户可以在上述任何配置中冒充您的更新服务器。如果你不验证你的更新，你的盒子更容易被黑客入侵。

这样做的一个好方法是签署您的更新文件。您必须维护证书（或付钱给某人这样做），但您可以在发货之前在每台设备上安装指纹，以便他们可以拒绝已被篡改的更新。

物理安全

当然，如果有人可以物理访问客户的部署，他们可以轻松接管服务器。但至少他们无法攻击其他部署！物理安全可能是您的客户的责任。

如果您愿意，请想象一下如果您使用大型 OpenVPN 网络进行更新会发生什么……然后他们可以使用受感染的服务器来攻击VPN 上的每个实例

安全

无论您做什么，都需要从一开始就内置安全性。不要在这里偷工减料 - 如果你这样做，你最终会后悔的。

完全保护此更新系统超出了本文的范围，如果您或您团队中的某个人不了解该领域，我强烈建议您聘请顾问。每一分钱都是值得的。

Answer 2

你真的需要访问它们吗？

还是只是更新它们？因为您可以让它们自行更新，类似于 apt 自动更新的方式。

如果您需要登录

为什么不是 OpenSSH 守护进程通过端口转发进行监听？每个客户都可以拥有单独的安全密钥，并且仅在需要时才进行连接。

取决于您的客户

您还需要考虑客户愿意接受的内容。他们可能对远程访问他们的网络不满意，或者只对特定的技术/配置感到满意。

Answer 3

我建议使用Puppet或Salt 之类的编排工具。

Salt 是一个消息队列，可以建立从设备到主服务器的持久出站连接。您可以使用它在设备上运行任意命令……例如apt-get.

另一个选项是 Puppet，您仍然有一个主服务器，客户端从它们的位置建立出站连接。

我将这两种工具用于类似的目的，我可能没有对防火墙的管理控制。