用户查询脚本是一种功能强大的工具，可以在Linux系统中快速查询用户信息。它不仅可以提供关键的用户属性，如UID、属组、GID、家目录，还可以验证用户是否拥有登录系统的权限。

**优势**

1、提升效率： 

用户查询脚本的设计旨在提供高效、便捷的用户信息查询方式。它消除了繁琐的手动查询过程，通过简单的命令行输入，即可迅速获取目标用户的关键属性。这种快速查询能极大地节省管理员的时间和精力，使其能够更专注于其他重要的管理任务。

2、自动化管理： 

用户查询脚本具备良好的可集成性，可以方便地与自动化脚本或管理工具进行整合。通过编写脚本，管理员能够实现批量查询用户信息，并在查询结果的基础上进行自动化处理。这种自动化管理的能力使得用户批量操作、权限分配等任务变得轻而易举，大大提高了工作效率。

3、加强安全性： 

用户查询脚本对于加强系统安全具有重要意义。通过查询用户的登录系统权限，管理员能够迅速检查和监控用户的访问权限，确保系统只授予合适的用户登录权。这种权限管理的精细化有助于防止未经授权的访问，提升了系统的整体安全性。

4、可定制的灵活性： 

用户查询脚本具有灵活的定制性，可以根据具体需求进行扩展和定制。管理员可以根据特定的管理需求，添加额外的功能或信息字段，满足不同场景下的管理需求。这种可定制性使得用户查询脚本成为一个高度灵活和可扩展的工具，能够适应各种复杂的管理要求。

**示例**

```
#!/bin/bash

# 检查输入参数
if [[ $# -ne 1 ]]; then
    echo "Usage: $0 <username>"
    exit 1
fi

# 获取用户信息
username=$1
user_info=$(getent passwd "$username")

# 检查用户是否存在
if [[ -z $user_info ]]; then
    echo "User '$username' does not exist."
    exit 1
fi

# 提取用户信息字段
IFS=':' read -r uid _ gid _ _ home _ <<< "$user_info"

# 检查用户是否有登录系统的权限
if sudo -n -u "$username" true 2>/dev/null; then
    login_access="Yes"
else
    login_access="No"
fi

# 输出用户信息
cat <<EOF
Username: $username
UID: $uid
GID: $gid
Home Directory: $home
Login Access: $login_access
EOF
```

用户查询脚本：提升效率与加强安全的必备利器

光模块学习总结

## 设备面临的安全威胁

随着网络通信技术的高速发展，人们享受到了前所未有的便利，与此同时也面临着网络中各种各样的安全威胁。为了抵御网络中的各种攻击，FW系列产品被广泛应用于IDC（Internet Data Center）出口、大小型企业和校园网出口等各种场景，为客户提供多种强大而完备的安全解决方案。与此同时，设备自身也面临着各种被攻击的风险，为了更好的为客户服务，设备需要应对各种可能的安全威胁，并对其提供有效的防护措施。

设备面临的安全威胁主要来自以下几个方面：

•仿冒（Spoofing）：指有能力冒充某人某物。由于业务场景需要，设备需要与多种外部交互方进行数据交互，如果这些外部交互方被仿冒，向设备发送请求，会造成正常业务受到影响，系统资源被占用。例如：由于IP网络的开放性，目前对MAC和IP地址缺乏有力的认证鉴权机制，极易产生基于ARP/IP的地址欺骗攻击，导致设备需要不断刷新转发流程必须的地址表项，处理来自欺骗地址的请求，由于地址表项错误导致转发中断，由于表项学习能力不足引发拒绝服务。

•篡改（Tampering）：指未经授权的更改。当设备与外部交互方进行数据传输时，如果缺乏安全的传输通道或加密手段，可能会被中间人攻击，数据被篡改。例如：WEB管理员通过HTTP协议访问设备，攻击者可通过获取交互报文，对某些重要信息做修改，如：向设备下发错误的指令，达到控制设备的目的；或者构造下发一些超长、畸形的报文字段，如果服务器端未进行完整性校验，可能会引起设备崩溃。

•抵赖（Repudiation）：指否认做过的事情。由于业务场景需要，设备需要响应各种外部交互方的指令，如果缺乏完善的日志机制，则下达指令的行为无法被记录，一旦出现问题，很难被追溯。例如：某管理员出于攻击目的，重启了设备，造成业务中断，配置丢失。如果系统的日志功能不完善，则很难对这种行为进行追溯。

•信息泄露（Information disclosure）：指信息被未授权访问。在实际场景中存在多种信息被泄露的风险。比如：当敏感数据在不同的业务子系统之间传输时，可能被网络黑客嗅探，如果信息采用明文传输或存储，则很容易造成信息被泄露，从而被攻击者获取和利用。

•拒绝服务（DOS）：攻击者向设备发起海量的消息请求，导致设备CPU无法实时处理消息，引发正常的业务交互流程、内部处理流程阻塞，达到拒绝服务的目的。

•权限提升（Elevation of privilege）：指拥有的权限高于实际需要的权限。在实际使用中，不同的用户角色应有不同的权限要求。如果对某类用户的权限定义不当，会导致权限扩大，使用户配置、查看到不应有的业务内容，导致安全风险。

除此之外，还有一些人为管理的原因，如：管理人员没有严格执行安全管理规章制度，管理人员安全意识不足等原因，也会给实际使用带来难以预估的安全风险。

## 设备脆弱性分析

**控制平面与管理平面处理能力局限性**

随着芯片等技术的发展，以及网络带宽需求的迅速增长，设备转发处理能力得到了极大的提升。近10年来，网络带宽经历了10M到100G的万倍跨越，转发平面的处理能力急剧提升。

设备的控制和管理平面运行在CPU上，软件处理能力的增长有限。超宽带时代终端与网元之间的通道得到极大增强，极易出现基于流量泛洪等方式的拒绝服务攻击。

**存在大量安全性不足的访问通道**

由于业界标准、管理便利性、历史继承性等原因，设备存在大量安全性不足的访问通道，例如：SNMP v1/v2，Telnet等，这些协议早期对安全性考虑不足，而新的协议（SNMP v3，SSH）并没有强制性替换老的协议。因此，如果用户不恰当的使用了这些安全不足的访问通道，容易造成信息泄密，被恶意用户利用时，容易产生非授权的访问行为。

同时，由于这些安全性不足的协议，没有进行任何完整性校验，容易引起中间人攻击，恶意攻击者可以通过篡改协议消息，达成攻击的目的。

**IP网络开放性带来的安全隐患**

IP网络的开放性带来网络架构便利性的同时，也带来了巨大的安全隐患。

1.首先，IP网络对接入终端无认证授权机制，导致任何终端均可以随意接入网络。恶意攻击者可以轻易的进入IP网络，只要探测到设备的IP地址，即可发起攻击行为。而且容易采用地址欺骗的方法，模拟海量源IP地址对设备进行攻击。

2.其次，IP网络在TCP/IP的第四层及以下，没有安全防御能力，所有消息的完整性、认证鉴权、协议一致性，都由应用层自行保障。因此，当攻击发生在第四层及以下时，设备往往成为攻击的对象。

3.再次，以太网架构本身的身份认证能力缺乏，容易引发基于MAC地址欺骗的攻击。

4.最后，IP协议栈本身的安全能力薄弱，协议设计时没有完整的安全策略架构，导致基于协议本身的攻击也频繁发生。

以上这些安全隐患，容易引发诸如地址欺骗、重放攻击、畸形报文、网络病毒、消息篡改、流量泛洪等一系列的安全攻击，引发各种各样的安全问题。

**电信网络复杂性带来的管理挑战**

由于电信网络规模庞大，系统构造复杂，导致网络节点数量众多、访问通道灵活复杂、通信协议层出不穷。

电信网络的管理也变得极其复杂，安全性和业务能力，安全性和业务灵活性，安全性和管理维护便利性，矛盾无处不在。不同技术能力、管理水平的运营商和管理人员，对这些矛盾的处理能力也参差不齐。

因此，电信网络的安全策略难以保持高水平的一致性，往往会暴露出部分安全漏洞，引发诸如感染病毒、非授权访问、以某个网元为跳板进行渗透攻击等问题。

**设备本身的复杂性带来的挑战**

设备配置模型复杂，管理员往往追求业务可用性，而忽略了安全防御能力，导致必要的安全措施没有得到妥善的配置，设备本身的安全能力无法发挥。

设备安全配置模型复杂，需要极高的技能才能完全掌握，对资深技术人员的依赖较大，容易造成在用户技能不足的情况下，以牺牲安全来达到业务可用。

## 设备安全风险评估

综合网络安全威胁、设备的脆弱性，可以评估出设备面临的安全风险，并给出安全风险抑制建议，如下表所示：

![image-20230523140144501](http://pic.nexopera.tech/image-20230523140144501.png)



## FW的安全隔离与防御机制

FW遵循X.805的三层三面安全隔离机制，其体系架构如下图所示。

由于不同的数据流的重要程度不同、受到的安全威胁不同、对用户的影响不同，为避免数据流相互影响，FW划分为三个不同的安全平面。

- 管理平面：关注管理用户的应用和业务数据的安全，即管理信息的安全，包括操作、维护和管理信息。
- 控制平面：FW需要运行各种各样的协议来达成业务，这些协议自身需要考虑安全性，避免被攻击或者仿冒。
- 转发平面：信息流的转发主要通过IP报文的目的MAC地址、目的IP地址来查找路径转发；相关安全性主要针对转发路径上如何避免对交换机自身的恶意攻击行为，以及预防某些攻击流量在IP网络中的扩散。

通过将控制平面、管理平面和转发平面进行隔离，FW能够保证任何一个平面在遭受攻击时，不会影响其他平面的正常运行

![image-20230523140205169](http://pic.nexopera.tech/image-20230523140205169.png)

图1 X.805的三层三面安全隔离架构

## 通用的安全加固建议

**日志维护建议**

利用审核日志记录来帮助发现可疑的活动。系统对于重要业务的操作需要记录日志。通过系统加固对日志文件进行保护。

·     定期检查日志

定期查看设备产生的日志，若发现有异常日志出现，应及时向上级部门汇报，若不能定位原因或无法自行解决时，及时联系客户服务中心，或者直接联系华为技术有限公司驻当地办事处的技术支持人员或联系代理商。

·     定期备份日志

日志应当定期进行备份，同时将备份文件在外介质（硬盘、磁带、光盘等）上存档。应当及时在设备上删除已备份的日志，以释放空间。

·     审计功能的配置更改

在系统初装时完成系统审计功能的配置，一般情况下不建议修改。若需要修改系统审计功能的配置，请报上级部门批准，同时将修改的内容作书面记录。

**安全评估建议**

建议运营商定期对系统进行安全评估，特别是在进行系统重大升级、网络搬迁、系统扩容等网络变更较大的情况下。

建议运营商找具有安全评估资质的专业机构对系统进行安全评估，评估时请与技术服务工程师联系。

**漏洞扫描建议**

漏洞扫描是指通过扫描等手段，对指定的远程或者本地计算机系统的安全脆弱性进行检测，发现可利用的漏洞的一种安全检测（渗透攻击）行为。

端口扫描是漏洞扫描的一部分。建议运营商使用NMAP工具扫描系统，参照产品的《通信矩阵》文档，检查系统是否开放了不必要的或可疑的端口。

运营商需要建立应对安全事故的应急响应处理机制，以保证出现安全事故后，可以尽快恢复生产和解决问题，将损失降至最低。

建议如下场景进行漏洞扫描：

- 周期性扫描，例如，按季度进行漏洞扫描。
- 在系统安装或者升级完成后进行漏洞扫描。
- 在发布重大漏洞公告时，需要对系统进行扫描确认是否存在重大漏洞。
- 在补丁安装完成后进行漏洞扫描。

**备份建议**

出于安全防护的需要，数据备份可以避免异常情况设备配置丢失，可以及时恢复数据。

- 在进行日常安全配置维护、故障处理之前和之后进行备份。
- 安装补丁、升级之前和之后进行备份。
- 请在备份前制定备份计划，确定备份时间和备份内容。
- 建议有专门的服务器备份所有软件版本、配置文件，并每周定期备份。
- 可以通过PC建立FTP/TFTP/SFTP服务器，将版本信息和配置信息下载存储在备份服务器上，作为备份。SFTP协议比FTP和TFTP有更高的安全保证，建议采用SFTP进行数据备份。

**补丁管理建议**

营商需要建立应用程序补丁的管理制度，设置相关人员，检视华为技术有限公司发布的补丁，并检查操作系统、数据库、中间件厂商发布的补丁。

安全加固与维护

# VLAN聚合简介：

VLAN聚合（VLAN Aggregation，也称Super VLAN）指在一个物理网络内，用多个VLAN（称为Sub-VLAN）隔离广播域，并将这些Sub-VLAN聚合成一个逻辑的VLAN（称为Super-VLAN），这些Sub-VLAN使用同一个IP子网和缺省网关。

通过引入Super-VLAN和Sub-VLAN的概念，使每个Sub-VLAN对应一个广播域，并让多个Sub-VLAN和一个Super-VLAN关联，只给Super-VLAN分配一个IP子网，所有Sub-VLAN都使用Super-VLAN的IP子网和缺省网关进行三层通信。

这样，多个Sub-VLAN共享一个网关地址，节约了子网号、子网定向广播地址、子网缺省网关地址，且各Sub-VLAN间的界线也不再是从前的子网界线了，它们可以根据各自主机的需求数目在Super-VLAN对应子网内灵活的划分地址范围，从而即保证了各个Sub-VLAN作为一个独立广播域实现广播隔离，又节省了IP地址资源，提高了编址的灵活性。

# 原理描述：

VLAN聚合通过定义Super-VLAN和Sub-VLAN，使Sub-VLAN只包含物理接口，负责保留各自独立的广播域；Super-VLAN不包含物理接口，只用来建立三层VLANIF接口。然后再通过建立Super-VLAN和Sub-VLAN间的映射关系，把三层VLANIF接口和物理接口两部分有机的结合起来，实现所有Sub-VLAN共用一个网关与外部网络通信，并用ARP Proxy实现Sub-VLAN间的三层通信，从而在实现普通VLAN的隔离广播域的同时，达到节省IP地址的目的。

- Sub-VLAN：只包含物理接口，不能建立三层VLANIF接口，用于隔离广播域。每个Sub-VLAN内的主机与外部的三层通信是靠Super-VLAN的三层VLANIF接口来实现的。
- Super-VLAN：只建立三层VLANIF接口，不包含物理接口，与子网网关对应。与普通VLAN不同的是，它的VLANIF接口的Up不依赖于自身物理接口的Up，而是只要它所含Sub-VLAN中存在Up的物理接口就Up。

一个Super-VLAN可以包含一个或多个Sub-VLAN。Sub-VLAN不再占用一个独立的子网网段。在同一个Super-VLAN中，无论主机属于哪一个Sub-VLAN，它的IP地址都在Super-VLAN对应的子网网段内。

这样，Sub-VLAN间共用同一个网关，既减少了一部分子网号、子网缺省网关地址和子网定向广播地址的消耗，又实现了不同广播域使用同一子网网段地址的目的，消除了子网差异，增加了编址的灵活性，减少了闲置地址浪费。

## Sub-VLAN之间的通信：

VLAN聚合在实现不同VLAN共用同一子网网段地址的同时，也给Sub-VLAN间的三层转发带来了问题。普通VLAN中，不同VLAN内的主机可以通过各自不同的网关进行三层互通。但是Super-VLAN中，所有Sub-VLAN内的主机使用的是同一个网段的地址，共用同一个网关地址，主机只会做二层转发，而不会送网关进行三层转发。即实际上，不同Sub-VLAN的主机在二层是相互隔离的，这就造成了Sub-VLAN间无法通信的问题。

**解决这一问题的方法就是使用Proxy ARP。**

### 示列：

如下图所示，假设Sub-VLAN2内的主机Host_1与Sub-VLAN3内的主机Host_2要通信，在Super-VLAN10的VLANIF接口上启用Proxy
ARP。

![这里写图片描述](http://pic.nexopera.tech/20180521131256326)

图：Proxy ARP实现不同Sub-VLAN间的三层通信组网图

Host_1与Host_2的通信过程如下（假设Host_1的ARP表中无Host_2的对应表项）：

1. Host_1将Host_2的IP地址（10.1.1.12）和自己所在网段10.1.1.0/24进行比较，发现Host_2和自己在同一个子网，但是Host_1的ARP表中无Host_2的对应表项。
2. Host_1发送ARP广播报文，请求Host_2的MAC地址，目的IP为10.1.1.12。
3. 网关Router收到Host_1的ARP请求，由于网关上使能Sub-VLAN间的Proxy ARP，开始使用报文中的目的IP地址在路由表中查找，发现匹配了一条路由，下一跳为直连网段（VLANIF10的10.1.1.0/24），VLANIF10对应Super-VLAN10，则向Super-VLAN10的所有Sub-VLAN接口发送一个ARP广播，请求Host_2的MAC地址。
4. Host_2收到网关发送的ARP广播后，对此请求进行ARP应答。
5. 网关收到Host_2的应答后，就把自己的MAC地址回应给Host_1。
6. Host_1之后要发给Host_2的报文都先发送给网关，由网关做三层转发。

Host_2发送报文给Host_1的过程和上述的Host_1发送报文给Host_2的过程类似，不再赘述。

## Sub_VLAN与其他网络的三层通信：

以所示组网为例，介绍Sub-VLAN内主机与其他网络内的主机间通信过程。

如下图，用户主机与服务器处于不同的网段中，Router_1上配置了Sub-VLAN2、Sub-VLAN3、Super-VLAN4和VLAN10，Router_2上配置了VLAN10和VLAN20。

![在这里插入图片描述](http://pic.nexopera.tech/20200418133534202.gif)

图：Sub-VLAN与其他网络的三层通信组网图

假设Sub-VLAN2下的主机Host_1想访问与Router_2相连的Server，报文转发流程如下（假设Router_1上已配置了去往10.1.2.0/24网段的路由，Router_2上已配置了去往10.1.1.0/24网段的路由，但两设备没有任何三层转发表项）：

1. Host_1将Server的IP地址（10.1.2.2）和自己所在网段10.1.1.0/24进行比较，发现和自己不在同一个子网，发送ARP请求给自己的网关，请求网关的MAC地址，目的MAC为全F，目的IP为10.1.1.1。
2. Router_1收到该请求报文后，查找Sub-VLAN和Super-VLAN的对应关系，知道应该回应Super-VLAN4对应的VLANIF4的MAC地址，并知道从Sub-VLAN2的接口回应给Host_1。
3. Host_1学习到网关的MAC地址后，开始发送目的MAC为Super-VLAN4对应的VLANIF4的MAC地址、目的IP为10.1.2.2的报文。
4. Router_1收到该报文后，根据Sub-VLAN和Super-VLAN的对应关系以及目的MAC判断进行三层转发，查三层转发表项没有找到匹配项，上送CPU查找路由表，得到下一跳地址为10.1.10.2，出接口为VLANIF10，并通过ARP表项和MAC表项确定出接口，把报文发送给Router_2。
5. Router_2根据正常的三层转发流程把报文发送给Server。

Server收到Host_1的报文后给Host_1回应，回应报文的目的IP为10.1.1.2，目的MAC为Router_2上VLANIF20接口的MAC地址，回应报文的转发流程如下：

1. Server给Host_1的回应报文按照正常的三层转发流程到达Router_1。到达Router_1时，报文的目的MAC地址为Router_1上VLANIF10接口的MAC地址。
2. Router_1收到该报文后根据目的MAC地址判断进行三层转发，查三层转发表项没有找到匹配项，上送CPU，CPU查路由表，发现目的IP为10.1.1.2对应的出接口为VLANIF4，查找Sub-VLAN和Super-VLAN的对应关系，并通过ARP表项和MAC表项，知道报文应该从Sub-VLAN2的接口发送给Host_1。
3. 回应报文到达Host_1。

## Sub-VLAN与其他设备的二层通信：

如下图所示组网为例，介绍Sub-VLAN内主机与其他设备的二层通信情况。Router_1上配置了Sub-VLAN2、Sub-VLAN3和Super-VLAN4，_*Router*_1的_IF_1和IF_2配置为Access接口，IF_3接口配置为Trunk接口，并允许VLAN2和VLAN3通过；Router_2连接Router_1的接口配置为Trunk接口，并允许VLAN2和VLAN3通过。
![这里写图片描述](http://pic.nexopera.tech/20180521131313570)

图：Sub-VLAN与其他设备的二层通信组网图

从Host_1进入Router_1的报文会被打上VLAN2的Tag。在Router_1中这个Tag不会因为VLAN2是VLAN4的Sub-VLAN而变为VLAN4的Tag。该报文从Router_1的Trunk接口IF_3出去时，依然是携带VLAN2的Tag。

也就是说，Router_1本身不会发出VLAN4的报文。就算其他设备有VLAN4的报文发送到该设备上，这些报文也会因为Router_1上没有VLAN4对应的物理接口而被丢弃。因为Router_1的IF_3接口上根本就不允许Super-VLAN4通过。对于其他设备而言，有效的VLAN只有Sub-VLAN2和Sub-VLAN3，所有的报文都是在这些VLAN中交互的。

这样，Router_1上虽然配置了VLAN聚合，但与其他设备的二层通信，不会涉及到Super-VLAN，与正常的二层通信流程一样。

# 配置Super-VALN:

## 配置注意事项：

- VLAN1不能配置为Super-VLAN。
- 配置某VLAN为Super-VLAN后，该VLAN类型改变为**super**，不允许任何物理接口加入该VLAN。
- 流策略只有在Super-vlan的所有Sub-vlan下配置才能生效，在Super-vlan下配置不生效。
- 配置某个VLAN为子接口的终结VLAN后，该VLAN不能再配置为Super-VLAN或Sub-VLAN。
- Super-VLAN对应的VLANIF接口配置IP地址后Proxy ARP才能生效。

## 配置聚合VLAN：

### 拓扑：

PC1,2 属于VLAN10 ，PC3,4属于VLAN20，通过聚合VLAN100，实现共用网关IP地址，开启VLAN间ARP代理，实现VLAN间通信。

![这里写图片描述](http://pic.nexopera.tech/20180521131320943)

图：VLAN聚合配置拓扑

### 配置参数：

```c
[SW]dis current-configuration 
#
sysname SW
#
vlan batch 10 20 100
  //批量创建VLAN
#
vlan 100
 aggregate-vlan//创建聚合VLAN
 access-vlan 10 20//将valn10 20 添加进聚合和VLAN
#
interface Vlanif100
 ip address 10.0.100.254 255.255.255.0
 arp-proxy inter-sub-vlan-proxy enable
 //开启VLAN间ARP代理，实现VLAN间通信
#
interface GigabitEthernet0/0/1
 port link-type access
 port default vlan 10
#
interface GigabitEthernet0/0/2
 port link-type access
 port default vlan 10
#
interface GigabitEthernet0/0/3
 port link-type access
 port default vlan 20
#
interface GigabitEthernet0/0/4
 port link-type access
 port default vlan 20
#
```



VLAN聚合

DNS (Domain Name Server) 提供了域名/主机名到 IP 地址的正反向解析功能，是保障网络服务能够正常使用的重要基础设施。几乎每次网络连接都是从 DNS 解析开始的，比如访问 Web 页面、发送电子邮件等等，都需要将域名解析为 IP 地址。

实现 DNS 的服务有很多，BIND 是 Unix/Linux 操作系统首选的 DNS 服务器，对于建设私有 DNS，BIND 无疑是一个好选择。本文将通过以下主题介绍 BIND，并演示在 Rocky Linux 9 上自动化完成 BIND 主从架构的部署：

- 部署环境要求
- 部署 BIND Master
- 部署 BIND Slave
- 配置客户端
- 总结

## 1.1 部署环境要求

BIND 主从部署过程的自动化是通过 Ansible 实现的，因此需要 Ansible 控制节点，BIND 使用主从架构，因此需要 BIND Master 节点和 BIND Slave 节点，共需要三个节点。

### 1.1.1 节点信息

三个节点分别为 2 核 CPU、2 G 内存的虚拟机。

Ansible 托管节点的信息已经在 “[自动化部署 NTP 服务](https://blog.nexopera.tech/post/228)” 一文做过介绍，这里略过。Ansible Inventory hosts 文件内容如下：

```
[automate]
automate-host.aiops.red

[ntp]
ntp1.server.aiops.red

[dnsmaster]
dns1-host.aiops.red

[dnsslave]
dns2-host.aiops.red
```

BIND Master 节点信息：

```
# IP：10.211.55.16
# NETMASK：255.255.255.0
# 主机名：dns1-host.aiops.red
# 系统版本：Rocky Linux release 9.0
```

BIND Slave 节点信息：

```
# IP：10.211.55.17
# NETMASK：255.255.255.0
# 主机名：dns2-host.aiops.red
# 系统版本：Rocky Linux release 9.0
```

### 1.1.2 节点要求

Ansible 控制节点通过主机名访问 DNS 主从节点，在 DNS 部署完成前，需要在 Ansible 控制节点的 `/etc/hosts` 文件中做主机名与 IP 地址的绑定：

```
sudo vim /etc/hosts
```

![image-20230522165709475](http://pic.nexopera.tech/image-20230522165709475.png)

为了实现部署过程的自动化，Ansible 控制节点需要通过 `aiops` 用户 (或其他有免密 **sudo** 权限的普通用户) 免密登录 DNS 主从节点，并可以免密执行 **sudo** 命令。在之后的小结中，会使用名为 `set_authorized_key` 的 Ansible Role 配置免密登录。

## 1.2 部署 BIND Master

BIND (Berkeley Internet Name Domain) 是由 ISC (Internet Systems Consortium) 开发和维护的开源软件，为不同操作系统实现 DNS 协议。

在本节中，介绍通过一组 Ansible Roles 完成 BIND Master 的安装与配置。

### 1.2.1 创建 BIND Master Role

创建 `bind_master` Role，并进入 `bind_master/` Role 目录：

```
ansible-galaxy role init --init-path ~/roles/ bind_master
cd ~/roles/bind_master/
```

![image-20230522165714143](http://pic.nexopera.tech/image-20230522165714143.png)

在 `tasks/main.yml` 文件中，定义安装 BIND Master 需要的 task，文件内容如下：

```
---
# tasks file for bind_master
- name: install bind packages task
  ansible.builtin.dnf:
    name:
      - bind
      - bind-utils
    state: present

- name: started dns service task
  ansible.builtin.systemd:
    name: named.service
    state: started
    enabled: true

- name: turn on dns service in the firewall task
  ansible.builtin.firewalld:
    service: dns
    permanent: true
    immediate: true
    state: enabled

- name: generate named.conf file from template task
  ansible.builtin.template:
    src: "{{ item.src }}"
    dest: "{{ item.dest }}"
    owner: root
    group: named
  loop:
    - { src: named_master.conf.j2, dest: /etc/named.conf }
    - { src: named.conf.master.j2, dest: /etc/named.conf.master }
    - { src: domain_name.j2, dest: "/var/named/{{ domain_name }}" }
    - { src: arpa.j2, dest: "/var/named/{{ arpa }}.in-addr.arpa" }
  notify: restart dns service handlers
```

第一个 task 安装 BIND 软件包，`bind` 包提供了 BIND 的主程序 **named**；`bind-utils` 包提供了查询 DNS 信息的命令 (**host、dig、nslookup**)。

第二个 task 启动 **named.service** 服务，并将其设置为开机启动。

第三个 task 在 **firewalld** 防火墙中开启 dns service，以供客户端访问。

第四个 task 通过模板文件生成四个配置文件，并在文件有变化时，通过 **notify** 通知 “restart dns service handlers”  执行。

`handlers/main.yml` 文件的内容如下：

```
---
# handlers file for bind_master
- name: restart dns service handlers
  ansible.builtin.systemd:
    name: named.service
    state: restarted
```

在接到通知后，重启 **named.service** 服务。

在模板配置文件中用到了几个变量，定义在了 `defaults/main.yml` 文件中：

```
---
# defaults file for bind_master
allow_network: 10.211.55.0/24
arpa: 55.211.10
domain_name: aiops.red
master_ip: 10.211.55.16
slave_ip: 10.211.55.17
```

这几个变量的值需要被使用者重新定义，因此把它们定义在了 `defaults/main.yml` 文件中。

### 1.2.2 创建 BIND Master Playbook

在 `~/playbooks/` 目录下创建用于存放部署 BIND Master 的 Playbook 及模板文件的目录，并切换到 `deploy_bind_master/`：

```
mkdir -p ~/playbooks/deploy_bind_master/templates/
cd ~/playbooks/deploy_bind_master/
```

![image-20230522165722721](http://pic.nexopera.tech/image-20230522165722721.png)

在 `templates/` 目录中创建模板文件。模板文件可以存放在 Role 的 `templates/` 目录下，也可以存放在 Playbook 的 `templates/` 目录下，如果两个位置分别存储了模板文件，Playbook 会覆盖 Role。

`templates/named_master.conf.j2` 文件生成 **named** 的主配置文件，内容如下：

```
options {
	listen-on port 53 { 127.0.0.1; {{ master_ip }}; };
	listen-on-v6 port 53 { ::1; };
	directory 	"/var/named";
	dump-file 	"/var/named/data/cache_dump.db";
	statistics-file "/var/named/data/named_stats.txt";
	memstatistics-file "/var/named/data/named_mem_stats.txt";
	secroots-file	"/var/named/data/named.secroots";
	recursing-file	"/var/named/data/named.recursing";
	allow-query     { localhost; {{ allow_network }}; };

	recursion yes;

	dnssec-validation yes;

	managed-keys-directory "/var/named/dynamic";
	geoip-directory "/usr/share/GeoIP";

	pid-file "/run/named/named.pid";
	session-keyfile "/run/named/session.key";

	include "/etc/crypto-policies/back-ends/bind.config";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
	type hint;
	file "named.ca";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
include "/etc/named.conf.master";
```

文件用到了 `master_ip` 和 `allow_network` 变量。`master_ip` 定义了 **named** 进程监听的 IP 地址；`allow_network` 定义了允许使用该 DNS  进行查询的网段。

文件末尾包含了 `/etc/named.conf.master` 文件，该文件由 `templates/named.conf.master.j2` 模板文件生成，内如如下：

```
zone "{{ domain_name }}" {
  type master;
  allow-transfer { {{ slave_ip }}; };
  also-notify { {{ slave_ip }}; };
  file "/var/named/{{ domain_name }}";
};

zone "{{ arpa }}.in-addr.arpa" {
  type master;
  allow-transfer { {{ slave_ip }}; };
  also-notify { {{ slave_ip }}; };
  file "/var/named/{{ arpa }}.in-addr.arpa";
};
```

**zone** 定义资源记录区，`domain_name` 是要托管的域名。**allow-transfer** 定义了将 Master DNS 上的区域文件内容复制到哪些 Slave DNS 上，以提供容错性。

`templates/domain_name.j2` 模板文件用于生成 zone 配置文件，内容如下：

```
$TTL 1h
@       IN      SOA     {{ domain_name}}.    root.{{ domain_name }}. (
        2022112101      ; Serial YYYYMMDDnn
        24h             ; Refresh
        2h              ; Retry
        28d             ; Expire
        2d )            ; Minimum TTL

;Name Servers
@       IN      NS              dns1-host
@       IN      NS              dns2-host

;Mail Servers
@       IN      MX      0       mail1-host

;Other Servers
dns1-host      IN      A               10.211.55.16
dns2-host      IN      A               10.211.55.17
mail1-host     IN      A               10.211.55.5
ntp1-host      IN      A               10.211.55.19

;Canonical Names
ntp1.server     IN      CNAME          ntp1-host
```

`templates/arpa.j2` 生成 zone 反向区域文件，定义 PTR 记录，内容如下：

```
$TTL 1h
@       IN      SOA     {{ arpa }}.in-addr.arpa    root.{{ domain_name }}. (
        2022111801      ; Serial YYYYMMDDnn
        24h             ; Refresh
        2h              ; Retry
        28d             ; Expire
        2d )            ; Minimum TTL

;Name Servers
@       IN      NS              dns1-host
@       IN      NS              dns2-host

;Other Servers
dns1-host  IN      A       10.211.55.16
dns2-host  IN      A       10.211.55.17

;PTR Records
16               IN      PTR             dns1-host
17               IN      PTR             dns2-host
5                IN      PTR             mail1
19               IN      PTR             ntp1-host
```

正反向区域文件中，分别添加了几个解析。

创建 `deploy_bind_master.yaml` Playbook 文件，内容如下：

```
#!/usr/bin/env ansible-playbook
---
- name: deploy bind master server play
  hosts: dnsmaster
  become: true
  gather_facts: false

  roles:
    - set_authorized_key
    - change_hostname
    - upgrade_packages
    - bind_master
...
```

Playbook 文件中使用了四个 Role。

`set_authorized_key` Role 将 Ansible 控制节点的 `aiops` 用户的公钥拷贝到托管节点的指定用户，以配置免密登录。执行该 Role 时，需要 **-k** 选项，提供远程用户密码。

在该 Role 中定义了两个文件。

`set_authorized_key/tasks/main.yml` 内容如下：

```
---
# tasks file for set_authorized_key
- name: initialization ssh key task
  ansible.builtin.authorized_key:
    comment: aiops user public key
    user: "{{ item }}"
    key: "{{ lookup('file', '/home/{{ local_user }}/.ssh/id_rsa.pub') }}"
  loop: "{{ remote_users }}"
```

`set_authorized_key/defaults/main.yml` 内容如下：

```
---
# defaults file for set_authorized_key
local_user: aiops
remote_users:
  - aiops
```

`local_user` 变量为 Ansible 控制节点的用户；`remote_users` 变量为托管节点的用户。

`change_hostname` Role 根据 Inventory hosts 中的名称设置托管节点的主机名，`change_hostname/tasks/main.yml` 文件内容如下：

```
---
# tasks file for change_hostname
- name: change host name task
  ansible.builtin.shell:
    cmd: hostnamectl set-hostname "{{ inventory_hostname }}"
```

`upgrade_packages` Role 更新 **dnf** 包，类似在操作系统上执行 **dnf upgrade -y** 命令。如果有软件包更新，则重启操作系统。`upgrade_packages/tasks/main.yml` 文件的内容如下：

```
---
# tasks file for upgrade_packages
- name: upgrade packages task
  ansible.builtin.dnf:
    update_cache: true
    name: "*"
    state: latest
  register: upgradeResult

- name: reboot system task
  reboot:
  when: upgradeResult.changed
```

> 在 “[Linux 9 自动化部署 NTP 服务](https://blog.nexopera.tech/post/228)” 一文中，对 Role 的创建做过介绍。

### 1.2.3 安装 BIND Master

执行 `deploy_bind_master.yaml` Playbook，安装并配置 BIND Master 节点：

```
ansible-playbook deploy_bind_master.yaml -k
```

![image-20230522165732456](http://pic.nexopera.tech/image-20230522165732456.png)

## 1.3 部署 BIND Slave

Slave 节点提高了服务的可用性。

### 1.3.1 创建 BIND Slave Role

创建 `bind_slave` Role，并进入 `bind_slave/` Role 目录：

```
ansible-galaxy role init --init-path ~/roles/ bind_slave
cd ~/roles/bind_slave
```

![image-20230522165737219](http://pic.nexopera.tech/image-20230522165737219.png)

在 `tasks/main.yml` 文件中，定义安装 BIND Slave 的 task，内容如下：

```
---
# tasks file for bind_slave
- name: install bind packages task
  ansible.builtin.dnf:
    name:
      - bind
      - bind-utils
    state: present

- name: started dns service task
  ansible.builtin.systemd:
    name: named.service
    state: started
    enabled: true
    
- name: set selinux to allow data synchronization from master task
  ansible.builtin.shell:
    cmd: setsebool -P named_write_master_zones on

- name: generate configuration files task
  ansible.builtin.template:
    src: "{{ item.src }}"
    dest: "{{ item.dest }}"
    owner: root
    group: named
  loop:
    - { src: named_slave.conf.j2, dest: /etc/named.conf }
    - { src: named.conf.slave.j2, dest: /etc/named.conf.slave }
  notify: restart dns service handlers
```

编辑 `handlers/main.yml` 文件，内容如下：

```
---
# handlers file for bind_slave
- name: restart dns service handlers
  ansible.builtin.systemd:
    name: named.service
    state: restarted
```

在 `defaults/main.yml` 中设置变量：

```
---
# defaults file for bind_slave
allow_network: 10.211.55.0/24
arpa: 55.211.10
domain_name: aiops.red
master_ip: 10.211.55.16
slave_ip: 10.211.55.17
```

Slave 中用到的变量与 Master 相同。

### 1.3.2 创建 BIND Slave Playbook

在 `~/playbooks/` 目录下创建用于存放部署 BIND Slave 的 Playbook 及模板文件的目录，并切换到 `deploy_bind_slave/`：

```
mkdir -p ~/playbooks/deploy_bind_slave/templates
cd ~/playbooks/deploy_bind_slave/
```

![image-20230522165743252](http://pic.nexopera.tech/image-20230522165743252.png)

BIND Slave Role 用到了`named_slave.conf.j2`、`named.conf.slave.j2` 两个模板文件，这两个文件存放在 `~/playbooks/deploy_bind_slave/templates/` 目录下。

`named_slave.conf.j2` 内容如下：

```
options {
	listen-on port 53 { 127.0.0.1; {{ slave_ip }}; };
	listen-on-v6 port 53 { ::1; };
	directory 	"/var/named";
	dump-file 	"/var/named/data/cache_dump.db";
	statistics-file "/var/named/data/named_stats.txt";
	memstatistics-file "/var/named/data/named_mem_stats.txt";
	secroots-file	"/var/named/data/named.secroots";
	recursing-file	"/var/named/data/named.recursing";
	allow-query     { localhost; {{ allow_network }}; };

	recursion yes;

	dnssec-validation yes;

	managed-keys-directory "/var/named/dynamic";
	geoip-directory "/usr/share/GeoIP";

	pid-file "/run/named/named.pid";
	session-keyfile "/run/named/session.key";

	/* https://fedoraproject.org/wiki/Changes/CryptoPolicy */
	include "/etc/crypto-policies/back-ends/bind.config";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
	type hint;
	file "named.ca";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
include "/etc/named.conf.slave";
```

`named.conf.slave.j2` 文件内容如下：

```
zone "{{ domain_name }}" {
   type slave;
   masters { {{ master_ip }}; };
   file "/var/named/{{ domain_name }}";
};

zone "{{ arpa }}.in-addr.arpa" {
   type slave;
   masters { {{ master_ip }}; };
   file "/var/named/{{ arpa }}.in-addr.arpa";
};
```

创建 `deploy_bind_slave.yaml` Playbook 文件，内容如下：

```
#!/usr/bin/env ansible-playbook
---
- name: deploy bind slave server play
  hosts: dnsslave
  become: true
  gather_facts: false

  roles:
    - set_authorized_key
    - change_hostname
    - upgrade_packages
    - bind_slave
...
```

### 1.3.3 安装 BIND Slave

执行 `deploy_bind_slave.yaml` Playbook，安装并配置 BIND Slave 节点：

```
ansible-playbook deploy_bind_slave.yaml -k
```

![image-20230522165749598](http://pic.nexopera.tech/image-20230522165749598.png)

## 1.4 设置节点使用 DNS 服务

DNS 主从节点已部署完成，接下来设置主机使用新建的 DNS 服务。

在 Ansible 控制节点上执行以下命令，为 `/etc/resolv.conf` 文件生成新内容：

```
sudo nmcli c m eth0 ipv4.dns-search aiops.red ipv4.dns 10.211.55.17,10.211.55.16
```

![image-20230522165754416](http://pic.nexopera.tech/image-20230522165754416.png)

执行 `restart_eth.sh` 脚本，重启网卡连接，使配置生效。`restart_eth.sh` 脚本内容如下：

```
#!/bin/bash
sudo nmcli c down eth0
sudo nmcli c up eth0
```

执行脚本：

```
sh restart_eth.sh
```

![image-20230522165758726](http://pic.nexopera.tech/image-20230522165758726.png)

> eth0 需要修改成正确的网卡接口。

查看 `/etc/resolv.conf` 文件的内容，可以看到，nameserver 地址已经配置为主从 DNS 的地址：

![image-20230522165802990](http://pic.nexopera.tech/image-20230522165802990.png)

`aiops.red` zone 添加了几个 A 记录以及解析 `ntp1.server` 的 CNAME 记录。删除 `/etc/hosts` 文件中包含 `ntp1.server.aiops.red` 的条目，然后访问该地址，以验证 DNS 的域名解析功能：

```
ping -c 1 ntp1.server.aiops.red
dig ntp1.server.aiops.red
```

![image-20230522165806565](http://pic.nexopera.tech/image-20230522165806565.png)

从输出可以看出，`ntp1.server.aiops.red` 域名是通过 DNS Slave 解析的。

可以编写一个 Ansible task，将 `/etc/resolv.conf` 文件拷贝到其他主机，使其他主机也能使用已部署的 DNS 服务解析域名。

## 1.5 总结

本文介绍了在 Rocky Linux 9 及其他基于 RPM 的 Linux 发行版上，使用 Ansible 自动化部署主从架构的 DNS 服务。

Linux 9 自动化部署 DNS 服务

Nexopera是一个专注于Linux、网络和运维等领域的博客网站。将为读者提供广泛的相关文章，涵盖操作系统、服务器管理、网络配置、安全性等多个主题。如果你是初学者，希望这里有适合你的内容。

光模块简介

什么是光模块：

设备面临的安全威胁

VLAN聚合简介：