主要介绍了一些各品牌防火墙配置自动化生成的思路，功能包括核查现有配置，判断是否需要新增配置，以及自动生成新增配置命令。并且在新增配置中，如何有效结合调用现有配置，避免在自动化生成的过程中引起防火墙配置量的野蛮增长，产生大量冗余配置。
1，ACL配置命名规范
ACL新增配置时的命名主要存在如下问题：
需求A： permit 10.10.10.1， 10.10.10.2 (OBJ_GROUP_A) ---> 20.20.20.1:80，443
需求B： permit 10.10.10.3， 10.10.10.4 ---> 20.20.20.1:80，443
需求C： permit 10.10.10.5， 10.10.10.6 ---> 20.20.20.1:80，443
需求D： ......
需求A和后续需求访问的目的地址和目的端口是一样的。因此目的地址组，以及目的端口组(思科)，可以直接调用已有配置，但是源地址组是新建，还是直接将后续新增地址加入到地址组OBJ_GROUP_A中呢?
1)如果来一个需求就新建源地址组，经过N个需求后就会产生N条源地址组以及N条ACL策略，自动化过程中配置量可能会野蛮增长。
2)如果直接往A需求的源地址组中添加新增地址，存在如下问题：
如果该源地址组被其他ACL调用，则可能扩大了其他ACL的访问范围， 例如还开通了permit OBJ_GROUP_A ---> 30.30.30.1:22
更糟糕的是如果被反方向deny调用，则可能影响现有系统的访问，例如还开通了deny 20.20.20.1 ---> OBJ_GROUP_A:80
综上所述:
地址组名称可以被反复调用和地址组名称可以添加成员是一对矛盾
可以被反复调用就不允许添加成员，可以添加成员就应该禁止被反复调用
因此，假设有开通工单(唯一编号)，定制如下命名规范:
目的地址组名称: 所在防火墙接口_开通工单， 可以被其他同方向ACL调用但禁止添加成员
源地址组名称: to_目的地址组名称_开通工单， 禁止被其他ACL调用但可以添加成员
端口组名称(思科): 单个端口无需创建组名称， 多个端口可以根据工单名称创建端口组， 并且可以全局可以反复调用
端口组名称(天融信/华为/juniper)：无需创建端口组， ACL中可以直接罗列端口
按此命名规范后:
1）需求单GD00001: permit 10.10.10.1， 10.10.10.2 ---> 20.20.20.1:80，443
新建ACL:to_IntA_GD00001_GD00001(10.10.10.1， 10.10.10.2) -------> IntA_GD00001(20.20.20.1): 80， 443
2）需求单GD00002：permit 10.10.10.3， 10.10.10.4 ---> 20.20.20.1:80，443
将10.10.10.3， 10.10.10.4添加至to_IntA_GD00001_GD00001
3）需求单GD00003: permit 10.10.10.1， 10.10.10.2 ---> 20.20.20.1:22
新建ACL:to_IntA_GD00001_GD00003(10.10.10.1， 10.10.10.2) -------> IntA_GD00001(20.20.20.1): 22
2，ACL配置自动化的思路
主要涉及模块：
1)防火墙配置实例化模块
2)策略核查模块
3)配置生成模块
4)路径生成模块（需要结合公司实际场景定制）
2.1，防火墙配置实例化模块
对各品牌防火墙（思科、天融信、juniper、华为）不同版本的防火墙配置文件进行解析，转换为三张表格：
表格一：地址表，记录地址组名称和地址组成员的对应关系
表格二：端口表，记录端口组名称和端口组成员的对应关系
表格三：ACL策略表，记录ACL主要信息
备注:
不同品牌防火墙记录信息会有差异，例如地址表中juniper需要记录区域信息
主要采用正则表达式 + pandas每天定时对防火墙配置进行读取和解析，供后续模块调用
返回的类型是表格， 可以通过excel， json， 数据库保存。数据库有点大材小用，excel表格单元格内数据量太大无法保存(例如地址组中有conf列会记录该地址组相关配置，如果成员数量过多就无法显示)，推荐用json，后续模块调用时可以直接将json转pandas。
2.2，策略核查模块
策略核查模块针对输入的ACL访问需求，做如下核查:
1)检查源地址、目的地址、目的端口， 三元素完全一致的ACL，返回所有命中的ACL(包括)
2)检查目的地址、目的端口，两个元素完全一致的ACL，并且目的地址组命名符合第一章的命名规范的(添加源地址时避免影响存量不规范配置)，返回该ACL所有信息
备注：这里只是做最简单的描述，实际实现时，还涉及到协议tcp/udp，而且不同防火墙需要的acl字段也有差异，思科只需要传策略名，其他品牌防火墙还有源区域和目的区域等等。
3， 配置生成模块
这块比较简单，主要是结合策略核查模块的结果，以及各品牌防火墙的配置命令，做如下三步：
1)三元素完全一致的ACL，并且第一条是permit的，直接反馈现有配置，无需新增配置
2)三元素中有目的地址、目的端口，两个元素完全一致的ACL，直接将需求中的源地址往现有源地址组名称中添加
3)根据本次工单号，依据命名规范，新增配置。新增配置时需要考虑是否有现有的目的地址组，端口组(思科)可以调用
4，路径生成模块（需要结合公司实际场景定制）
直接调用配置生成模块，不仅需要提供防火墙名称，防火墙端口等信息，如果涉及多个防火墙，还需要逐一罗列，对运维人员交互不友好
因此还需要结合公司实际网络环境，定制各网段间访问的关系，例如A网段访问B网段经过哪几个防火墙，以及分别是涉及防火墙的哪几个接口，思科防火墙的入向策略名等等
如果网络环境比较复杂可能全部罗列比较困难
对于HUB-SPOKEN有环形网的场景，可以通过记录每个网段到环形网经过的防火墙(以及相应接口)，这样所有通过环形网互相访问的网段就无需逐一罗列，同时再补充一张不经过环形网的特殊访问表即可
后续会逐一对各模块实现细节和相应代码进行展开分析