我们为什么要创建它？
长期以来，在Rambler Group，我们使用了三层数据中心网络体系结构，其中每个项目或基础架构组件都位于一个专用VLAN中。VLAN之间和数据中心之间的所有流量都通过边缘级设备进行。
边缘设备是能够执行许多不同功能的昂贵路由器，因此，其上的端口也很昂贵。随着时间的流逝，水平流量不断增加（机器到机器-例如数据库复制，对各种服务的请求等），并且在某个时候出现了边界路由器上的端口利用率问题。
这种设备的主要功能之一是流量过滤。结果，管理ACL也变得更加困难：您必须手动执行所有操作，而且相邻部门执行任务也需要时间。在访问级别上配置端口花费了额外的时间。由于主机分别更改了位置，因此它们可能会非法访问他人的vlan，因此不仅必须执行相同NOC的手动操作，而且还要识别潜在的安全问题。
改变某些东西的时机已经到来，Clos网络或IP工厂也应运而生。
尽管在外观上有相似之处，但此体系结构与上一个体系结构之间的根本区别在于，每个设备（包括叶子层）都充当路由器，服务器的默认网关是机架式。因此，不同项目的任何主机之间的水平流量现在都可以穿过主干层，而不是穿过边缘。
此外，在同一主干级别上，我们可以将数据中心彼此连接，并且任意两台服务器之间的路径上现在不超过四个网络设备。此体系结构中的边缘设备仅需要连接电信运营商，并且仅允许垂直流量（往返Internet）。
Klose网络的主要特点是它没有一个可以过滤主机之间流量的地方。因此，必须直接在服务器上执行此功能。集中式防火墙是一种程序，用于在接收流量的主机本身上过滤流量。
要求
一次要实现集中式防火墙的需求由以下几个因素决定：
- 最终消费者和
- 现有基础架构。
因此，该应用程序的要求如下：
- 防火墙必须能够在主机和虚拟机上工作并创建规则。此外，规则列表不应与防火墙运行的环境不同。也就是说，规则是相同的。
- . , – ssh, ( Prometheus), .
- , -.
- , – .
- .
- : « , ».
Rambler Group云非常动态：创建和删除虚拟机，安装和拆卸服务器。因此，我们不使用点对点访问；我们的基础结构具有“主机组”的概念。
主机组是一组唯一描述其角色的服务器的标记。例如news-prod-coolstream-blue。
这导致了另一个要求：用户必须使用高级实体进行操作-主机组，项目等。
理念与实施
Tulling
集中式防火墙是一件大而复杂的事情，需要配置代理。查找问题可能需要五分钟以上的时间，因此随代理和服务器一起出现了一个工具，该工具会告诉用户代理是否配置正确以及需要解决的问题。例如，对主机的重要要求是主机组或PTR中是否存在DNS记录。该工具将告诉您所有这一切以及更多信息（其功能如下所述）。
统一防火墙
我们尝试遵循以下原则：在主机上配置防火墙的应用程序应该是唯一的应用程序，以免获得“闪烁规则”。也就是说，如果服务器已经拥有自己的定制工具（例如，如果规则是由另一个代理配置的），那么我们的应用程序将不属于该工具。嗯，相反的条件也适用：如果有我们的防火墙代理，则只有他来设置规则-这是完全控制的原则。
防火墙不是iptables
众所周知，iptables只是用于netfilter的命令行实用程序。为了将防火墙移植到不同的平台（Windows，BSD系统），代理和服务器使用各自的模型。有关更多信息，请参见“架构”部分。
代理不会尝试解决逻辑错误
如上所述，代理不做任何决定。如果要关闭已经在运行HTTP服务器的端口443，请关闭它！
建筑
在这种应用程序的体系结构中很难提出一些新的东西。
- 我们有一个代理，它在主机上配置规则。
- 我们有一台服务器，它提供用户定义的规则。
- 我们有一个图书馆和工具。
- 我们有一个高级解析器-它可以将IP地址更改为主机组/项目，反之亦然。所有这些都在下面。
Rambler Group有许多主机，甚至还有更多虚拟机，并且所有主机都以某种方式属于某个实体：
- 虚拟局域网
- 网络
- 项目
- 主机组。
后者描述了宿主对项目的归属及其作用。例如，news-prod-backend-api，其中：news-project;产品-它的环境，在这种情况下是生产；后端-角色； api是任意的自定义标签。
防火墙
解析器在网络和/或传输级别运行，主机组和项目是高级实体。因此，为了“结交朋友”并了解谁拥有主机（或虚拟机），您需要获取地址列表-我们将此组件命名为“高级解析器”。它将高级名称更改为一组地址（就解析程序而言，它是“包含”），相反，将其更改为实体名称的地址（“包含”）。
库-核心
为了统一和统一某些组件，出现了一个库，它也称为Core。这是一个具有自己的控制器和视图的数据模型，允许您填充和读取它。这种方法大大简化了服务器端和代理代码，还有助于将主机上的当前规则与从服务器接收的规则进行比较。
我们有几种填充模型的资料：
- 规则文件（两种不同类型：简化和完整描述规则）
- 从服务器收到的规则
- 从主机本身收到的规则。
代理
代理不是对iptables的绑定，而是一个独立的应用程序，该应用程序使用C库libiptc，libxtables上的包装程序工作。代理本身不做任何决定，而仅在主机上配置规则。
代理的作用很小：读取规则文件（包括默认文件），从服务器获取数据（如果已配置用于远程操作），将规则合并为一组，检查它们是否与以前的状态不同，并应用（如果它们不同）。
该代理的另一个重要作用是在初始安装过程中或从服务器接收到无效响应时，不要将主机变成南瓜。为避免这种情况，默认情况下，我们在软件包中提供了一组规则，例如ssh，监视访问等。如果防火墙代理收到第200个响应代码以外的其他响应代码，则该代理将不会尝试执行任何操作，并会保留以前的状态。但是，它不能防止逻辑错误，如果您拒绝对端口80、443的访问，那么即使Web服务正在主机上运行，代理仍将继续执行其工作。
Tulza
Tulza供维护项目的系统管理员和开发人员使用。目标非常简单：一键获取有关代理工作的所有数据。该实用程序可以告诉您以下信息：
- 代理守护程序正在运行吗
- 主机是否有PTR记录
- .
该信息足以在早期诊断问题。
服务器
服务器是应用程序+数据库。工作的所有逻辑都由他执行。服务器的一个重要功能是它不存储IP地址。服务器仅与顶级对象一起使用-命名主机组，项目等。
基础中的规则如下：操作：接受Src：project-B，project-C Dst：Project-B Proto：tcp端口：80、443。
服务器如何理解要分配给谁的规则？从要求出发，无论代理在何处运行（无论是主机还是虚拟机），规则都必须相同。
来自代理的请求总是以一个值（一个IP地址）到达服务器。重要的是要记住，每个代理都要求自己制定规则，也就是说，他是目的地。
为了便于理解服务器操作，请考虑获取属于项目的主机规则的过程。
解析器首先起作用。它的任务是将IP地址更改为主机名，然后找出该主机包含在哪个实体中。 HL-Resolver响应服务器主机包含在项目A中。HL-Resolver引用数据源（我们之前没有提到过）。数据源是一种有关服务器，项目，主机组等的公司知识库。
接下来，服务器使用destination = project name查找项目的所有规则。由于我们在数据库中不包含地址，因此我们需要将项目名称重命名为hostenyms，然后重命名为地址，因此请求再次通过解析器发送到数据源。 HL-Resoler返回一个地址列表，此后代理将收到一个准备好的规则列表。
如果目标是装有虚拟机的主机，则不仅会对主机执行相同的脚本，还会对主机上的每个虚拟机执行相同的脚本。
下图显示了一个简单的情况：主机（硬件或虚拟机）在Project-A中接收该主机的规则。
发布
不难猜测，有了集中式防火墙管理，您还可以集中破坏所有内容。因此，代理和服务器的发布是分阶段进行的。
对于服务器-蓝绿色+ A / B测试
蓝绿色是一种涉及两个主机组的部署策略。并且切换进入1,3,5,10 ... 100％部分。因此，如果新版本出现问题，那么只有一小部分服务会受到影响。
对于一个代理，Canary
Canary（或canary部署）有点类似于A / B测试。我们仅更新一些代理并查看指标。如果一切顺利，我们再做一个更大的块，依此类推，直到100％。
结论
结果，我们为系统工程师提供了一项自助服务，使您可以从一个点管理网络访问。因此，我们：
- HTTP-API
- .