分类 系统运维 下的文章

Jenkins 的默认日志难以阅读,但日志本不必如此。

 title=

Jenkins 是一个自由开源的自动化服务器,用于构建、测试和部署代码。它是 持续集成 Continuous Integration (CI)、 持续交付 Continuous Delivery (CD)的基础,可以为开发人员每天节约几小时,并保护他们免受失败的代码上线的影响。一旦代码失效或开发人员需要查看测试输出时,Jenkins 提供了日志文件以供检查。

默认的 Jenkins 管道 Pipeline 日志可能难以阅读。这篇关于 Jenkins 日志的基础知识的总结文章提供了一些技巧(和代码),说明了如何提升它们的可读性。

你获得什么

Jenkins 管道分为 几个阶段。Jenkins 自动记录每个阶段的开始,记录内容如下:

[Pipeline] // stage
[Pipeline] stage (hide)
[Pipeline] { (Apply all openshift resources)
[Pipeline] dir

上文显示的内容没有太大区分度,重要的内容(如阶段的开始)未突出显示。在多达数百行的管道日志中,要找到一个阶段的起始和另外一个阶段的终止位置可能会很艰巨。当随意浏览日志寻找一个特定的阶段的时候,这种艰巨尤其明显。

Jenkins 管道是由 Groovy 和 Shell 脚本混合编写的。在 Groovy 代码中,日志记录很少。很多时候,日志是由命令中的不起眼的文本组成,没有详细信息。在 Shell 脚本中,打开了调试模式(set -x),所以每条命令都会被完全 具现化 realized (变量被解除引用并打印出数值)并详细记录,输出也是如此。

鉴于日志可能有很多内容,通读日志获取相关信息可能很繁琐。由于在管道中被处理,并跟着一个 Shell 脚本的 Groovy 日志可读性差,它们很多时候缺少上下文:

[Pipeline] dir
Running in /home/jenkins/agent/workspace/devop-master/devops-server-pipeline/my-repo-dir/src
[Pipeline] { (hide)
[Pipeline] findFiles
[Pipeline] findFiles
[Pipeline] readYaml
[Pipeline] }

我可以知道我正在使用的目录,并且知道我正在使用 Jenkins 的步骤搜索文件、读取 YAML 文件。但是我在寻找什么?我找到并读取的内容是什么?

能做什么?

我很高兴你这么问,因为这里有一些简单的做法和一些小的代码片段可以提供帮助。首先,代码如下:

def echoBanner(def ... msgs) {
   echo createBanner(msgs)
}

def errorBanner(def ... msgs) {
   error(createBanner(msgs))
}

def createBanner(def ... msgs) {
   return """
       ===========================================

       ${msgFlatten(null, msgs).join("\n        ")}

       ===========================================
   """
}

// flatten function hack included in case Jenkins security
// is set to preclude calling Groovy flatten() static method
// NOTE: works well on all nested collections except a Map
def msgFlatten(def list, def msgs) {
   list = list ?: []
   if (!(msgs instanceof String) && !(msgs instanceof GString)) {
       msgs.each { msg ->
           list = msgFlatten(list, msg)
       }
   }
   else {
       list += msgs
   }

   return  list
}

将这段代码添加到每个管道的末尾,也可以 加载一个 Groovy 文件 或者使其成为 Jenkins 共享库 的一部分,这样更有效。

在每个阶段起始处(或者在阶段中的特定位置),只需调用 echoBanner

echoBanner("MY STAGE", ["DOING SOMETHING 1", "DOING SOMETHING 2"])

你的 Jenkins 日志会展示如下:

    ===========================================

    MY STAGE
    DOING SOMETHING 1
    DOING SOMETHING 2

    ===========================================

这个横幅很容易从日志中分辨出来。当正确使用它们时,它们还有助于界定管道流,并且可以很好的将日志分解开来进行阅读。

我已经在某些地方专业地使用这些代码一些时间了。在帮助管道日志更易读和流程更易理解方面,反馈是非常积极的。

上述的 errorBanner 方法以相同的方式工作,但是它会立即使脚本失效。这有助于突显失败的位置与原因。

最佳实践

  1. 在你的 Groovy 代码中大量使用 echo Jenkins 步骤来通知用户你在做什么。这些也可以帮助记录你的代码。
  2. 使用空的日志语句(Groovy 中空的 echo 步骤、echo '' 或 Shell 中的 echo)来分割输出,提高可读性。你可能在你的代码中为同样的目的使用空行。
  3. 避免在脚本中使用 set +x 的陷阱,因为它隐藏了日志记录已执行的 Shell 语句。它并没有清理你的日志,而是使你的管道成为一个黑盒子,隐藏了管道正在做的行为以及出现的任何错误。确保管道功能尽可能透明。
  4. 如果你的管道创建了 中间工件 Intermediate Artifacts ,开发人员和 DevOps 人员可以使用这些工件来帮助调试问题,那么也要记录它的内容。是的,它会加长日志,但这只是文本。在某些时候,这会是有用的信息,而(利用得当的)日志不就是关于发生了什么和为什么发生的大量信息吗?

Kubernetes 机密信息:无法完全透明的地方

有些事情你不希望出现在日志里暴露出来。如果你在使用 Kubernetes 并引用保存在 Kubernetes 机密信息 Secrets 中的数据,那么你绝对不希望在日志中公开该数据,因为这些数据只是被混淆了,而没有被加密。

假如你想获取一些保存在机密信息中的数据,然后将其注入模板化 JSON 文件中。(机密信息和 JSON 模板的完整内容与此例无关。)按照最佳实践,你希望保持透明并记录你的操作,但你不想公开机密信息数据。

将脚本模式从调试(set -x)更改为命令记录(set -v)。在脚本敏感部分的结尾,将 Shell 重置为调试模式:

sh """
   # change script mode from debugging to command logging
   set +x -v

   # capture data from secret in shell variable
   MY_SECRET=\$(kubectl get secret my-secret --no-headers -o 'custom-column=:.data.my-secret-data')

   # replace template placeholder inline
   sed s/%TEMPLATE_PARAM%/${MY_SECRET_DATA}/ my-template-file.json

   # do something with modified template-file.json...

   # reset the shell to debugging mode
   set -x +v
"""

这将输出此行到日志:

sed s/%TEMPLATE_PARAM%/${MY_SECRET_DATA}/ my-template-file.json

与 Shell 调试模式中不同,这不会具现化 Shell 变量 MY_SECRET_DATA。显然,如果管道中在这一点出现问题,而你试图找出问题出在哪里,那么这不如调试模式有用。但这是在保持管道执行对开发人员和 DevOps 透明的同时,也保持你的秘密的最佳平衡。


via: https://opensource.com/article/21/5/jenkins-logs

作者:Evan "Hippy" Slatis 选题:lujun9972 译者:DCOLIVERSUN 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

cron 是一个调度守护进程,它以指定的时间间隔执行任务,这些任务称为 corn 作业,主要用于自动执行系统维护或管理任务。例如,你可以设置一个 cron 作业来自动执行重复的任务,比如备份数据库或数据,使用最新的安全补丁更新系统,检查磁盘空间使用情况,发送电子邮件等等。 cron 作业可以按分钟、小时、日、月、星期或它们的任意组合运行。

cron 的一些优点

以下是使用 cron 作业的一些优点:

  • 你可以更好地控制作业的运行时间。例如,你可以精确到分钟、小时、天等。
  • 它消除了为循环任务逻辑而去写代码的需要,当你不再需要执行任务时,可以直接关闭它。
  • 作业在不执行时不会占用内存,因此你可以节省内存分配。
  • 如果一个作业执行失败并由于某种原因退出,它将在适当的时间再次运行。

安装 cron 守护进程

幸运的是,Fedora Linux 预先配置了运行重要的系统任务来保持系统更新,有几个实用程序可以运行任务例如 cron、anacronatbatch 。本文只关注 cron 实用程序的安装。cron 和 cronie 包一起安装,cronie 包也提供 cron 服务。

要确定软件包是否已经存在,使用 rpm 命令:

$ rpm -q cronie
 Cronie-1.5.2-4.el8.x86_64

如果安装了 cronie ,它将返回 cronie 包的全名。如果你的系统中没有安装,则会显示未安装。

使用以下命令安装:

$ dnf install cronie

运行 cron 守护进程

cron 作业由 crond 服务来执行,它会读取配置文件中的信息。在将作业添加到配置文件之前,必须启动 crond 服务,或者安装它。什么是 crond 呢?crond 是 cron 守护程序的简称。要确定 crond 服务是否正在运行,输入以下命令:

$ systemctl status crond.service
● crond.service - Command Scheduler
      Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor pre>
      Active: active (running) since Sat 2021-03-20 14:12:35 PDT; 1 day 21h ago
    Main PID: 1110 (crond)

如果你没有看到类似的内容 Active: active (running) since…,你需要启动 crond 守护进程。要在当前会话中运行 crond 服务,输入以下命令:

$ systemctl run crond.service

将其配置为开机自启动,输入以下命令:

$ systemctl enable crond.service

如果出于某种原因,你希望停止 crond 服务,按以下方式使用 stop 命令:

$ systemctl stop crond.service

要重新启动它,只需使用 restart 命令:

$ systemctl restart crond.service

定义一个 cron 作业

cron 配置

以下是一个 cron 作业的配置细节示例。它定义了一个简单的 cron 作业,将 git master 分支的最新更改拉取到克隆的仓库中:

*/59 * * * * username cd /home/username/project/design && git pull origin master

主要有两部分:

  • 第一部分是 */59 * * * *。这表明计时器设置为第 59 分钟执行一次。(LCTT 译注:原文此处有误。)
  • 该行的其余部分是命令,因为它将从命令行运行。 在此示例中,命令本身包含三个部分:

    • 作业将以用户 username 的身份运行
    • 它将切换到目录 /home/username/project/design
    • 运行 git 命令拉取 master 分支中的最新更改

时间语法

如上所述,时间信息是 cron 作业字符串的第一部分,如上所属。它决定了 cron 作业运行的频率和时间。它按以下顺序包括 5 个部分:

  • 分钟
  • 小时
  • 一个月中的某天
  • 月份
  • 一周中的某天

下面是一种更图形化的方式来解释语法:

  .--------------- 分钟 (0 - 59)
 |  .------------- 小时 (0 - 23)
 |  |  .---------- 一月中的某天 (1 - 31)
 |  |  |  .------- 月份 (1 - 12) 或 jan、feb、mar、apr …
 |  |  |  |  .---- 一周中的某天 (0-6) (周日=0 或 7)
 |  |  |  |  |            或 sun、mon、tue、wed、thr、fri、sat
 |  |  |  |  |               
 *  *  *  *  *  user-name  command-to-be-executed 

星号的使用

星号(*)可以用来替代数字,表示该位置的所有可能值。例如,分钟位置上的星号会使它每分钟运行一次。以下示例可能有助于更好地理解语法。

这个 cron 作业将每分钟运行一次:

* * * * [command]

斜杠表示分钟的间隔数。下面的示例将每小时运行 12 次,即每 5 分钟运行一次:

*/5 * * * * [command]

下一个示例将每月的第二天午夜(例如 1 月 2 日凌晨 12:00,2 月 2 日凌晨 12:00 等等):

0 0 2 * * [command]

(LCTT 译注:关于 cron 时间格式,还有更多格式符号,此处没有展开)

使用 crontab 创建一个 cron 作业

cron 作业会在后台运行,它会不断检查 /etc/crontab 文件和 /etc/cron.*/ 以及 /var/spool/cron/ 目录。每个用户在 /var/spool/cron/ 中都有一个唯一的 crontab 文件。

不应该直接编辑这些 cron 文件。crontab 命令是用于创建、编辑、安装、卸载和列出 cron 作业的方法。

更酷的是,在创建新文件或编辑现有文件后,你无需重新启动 cron。

$ crontab -e

这将打开你现有的 crontab 文件,或者创建一个。调用 crontab -e 时,默认情况下会使用 vi 编辑器。注意:要使用 Nano 编辑 crontab 文件,可以设置 EDITOR=nano 环境变量。

使用 -l 选项列出所有 cron 作业。如果需要,使用 -u 选项指定一个用户。

$ crontab -l
$ crontab -u username -l

使用以下命令删除所有 cron 作业:

$ crontab -r

要删除特定用户的作业,你必须以 root 用户身份运行以下命令:

$ crontab -r -u username

感谢你的阅读。cron 作业看起来可能只是系统管理员的工具,但它实际上与许多 Web 应用程序和用户任务有关。

参考

Fedora Linux 文档的 自动化任务


via: https://fedoramagazine.org/scheduling-tasks-with-cron/

作者:Darshna Das 选题:lujun9972 译者:MjSeven 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

虚拟私有网络 Virtual Private Networks 应用广泛。如今有各种方案可供使用,用户可通过这些方案访问任意类型的资源,同时保持其机密性与隐私性。

最近,WireGuard 因为其简单性、速度与安全性成为最广泛使用的虚拟私有网络协议之一。WireGuard 最早应用于 Linux 内核,但目前可以用在其他平台,例如 iOS、Android 等。

WireGuard 使用 UDP 作为其传输协议,并在 Critokey Routing(CKR)的基础上建立对等节点之间的通信。每个对等节点(无论是服务器或客户端)都有一对 密钥 key (公钥与私钥),公钥与许可 IP 间建立通信连接。有关 WireGuard 更多信息请访问其 主页

本文描述了如何在两个对等节点(PeerA 与 PeerB)间设置 WireGuard。两个节点均运行 Fedora Linux 系统,使用 NetworkManager 进行持久性配置。

WireGuard 设置与网络配置

在 PeerA 与 PeerB 之间建立持久性虚拟私有网络连接只需三步:

  1. 安装所需软件包。
  2. 生成 密钥对 key pair
  3. 配置 WireGuard 接口。

安装

在两个对等节点(PeerA 与 PeerB)上安装 wireguard-tools 软件包:

$ sudo -i
# dnf -y install wireguard-tools

这个包可以从 Fedora Linux 更新库中找到。它在 /etc/wireguard/ 中创建一个配置目录。在这里你将创建密钥和接口配置文件。

生成密钥对

现在,使用 wg 工具在每个节点上生成公钥与私钥:

# cd /etc/wireguard
# wg genkey | tee privatekey | wg pubkey > publickey

在 PeerA 上配置 WireGuard 接口

WireGuard 接口命名规则为 wg0wg1 等等。完成下述步骤为 WireGuard 接口创建配置:

  • PeerA 节点上配置想要的 IP 地址与掩码。
  • 该节点监听的 UDP 端口。
  • PeerA 的私钥。
# cat << EOF > /etc/wireguard/wg0.conf
[Interface]
Address = 172.16.1.254/24
SaveConfig = true
ListenPort = 60001
PrivateKey = mAoO2RxlqRvCZZoHhUDiW3+zAazcZoELrYbgl+TpPEc=

[Peer]
PublicKey = IOePXA9igeRqzCSzw4dhpl4+6l/NiQvkDSAnj5LtShw=
AllowedIPs = 172.16.1.2/32
EOF

允许 UDP 流量通过节点监听的端口:

# firewall-cmd --add-port=60001/udp --permanent --zone=public
# firewall-cmd --reload
success

最后,将接口配置文件导入 NetworkManager。这样,WireGuard 接口在重启后将持续存在。

# nmcli con import type wireguard file /etc/wireguard/wg0.conf
Connection 'wg0' (21d939af-9e55-4df2-bacf-a13a4a488377) successfully added.

验证 wg0的状态:

# wg
interface: wg0
  public key: FEPcisOjLaZsJbYSxb0CI5pvbXwIB3BCjMUPxuaLrH8=
  private key: (hidden)
  listening port: 60001

peer: IOePXA9igeRqzCSzw4dhpl4+6l/NiQvkDSAnj5LtShw=
  allowed ips: 172.16.1.2/32

# nmcli -p device show wg0

===============================================================================
                             Device details (wg0)
===============================================================================
GENERAL.DEVICE:                         wg0
-------------------------------------------------------------------------------
GENERAL.TYPE:                           wireguard
-------------------------------------------------------------------------------
GENERAL.HWADDR:                         (unknown)
-------------------------------------------------------------------------------
GENERAL.MTU:                            1420
-------------------------------------------------------------------------------
GENERAL.STATE:                          100 (connected)
-------------------------------------------------------------------------------
GENERAL.CONNECTION:                     wg0
-------------------------------------------------------------------------------
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveC>
-------------------------------------------------------------------------------
IP4.ADDRESS[1]:                         172.16.1.254/24
IP4.GATEWAY:                            --
IP4.ROUTE[1]:                           dst = 172.16.1.0/24, nh = 0.0.0.0, mt =>
-------------------------------------------------------------------------------
IP6.GATEWAY:                            --
-------------------------------------------------------------------------------

上述输出显示接口 wg0 已连接。现在,它可以和虚拟私有网络 IP 地址为 172.16.1.2 的对等节点通信。

在 PeerB 上配置 WireGuard 接口

现在可以在第二个对等节点上创建 wg0 接口的配置文件了。确保你已经完成以下步骤:

  • PeerB 节点上设置 IP 地址与掩码。
  • PeerB 的私钥。
  • PeerA 的公钥。
  • PeerA 的 IP 地址或主机名、监听 WireGuard 流量的 UDP 端口。
# cat << EOF > /etc/wireguard/wg0.conf
[Interface]
Address = 172.16.1.2
SaveConfig = true
PrivateKey = UBiF85o7937fBK84c2qLFQwEr6eDhLSJsb5SAq1lF3c=

[Peer]
PublicKey = FEPcisOjLaZsJbYSxb0CI5pvbXwIB3BCjMUPxuaLrH8=
AllowedIPs = 172.16.1.254/32
Endpoint = peera.example.com:60001
EOF

最后一步是将接口配置文件导入 NetworkManager。如上所述,这一步是重启后保持 WireGuard 接口持续存在的关键。

# nmcli con import type wireguard file /etc/wireguard/wg0.conf
Connection 'wg0' (39bdaba7-8d91-4334-bc8f-85fa978777d8) successfully added.

验证 wg0 的状态:

# wg
interface: wg0
  public key: IOePXA9igeRqzCSzw4dhpl4+6l/NiQvkDSAnj5LtShw=
  private key: (hidden)
  listening port: 47749

peer: FEPcisOjLaZsJbYSxb0CI5pvbXwIB3BCjMUPxuaLrH8=
  endpoint: 192.168.124.230:60001
  allowed ips: 172.16.1.254/32

# nmcli -p device show wg0

===============================================================================
                             Device details (wg0)
===============================================================================
GENERAL.DEVICE:                         wg0
-------------------------------------------------------------------------------
GENERAL.TYPE:                           wireguard
-------------------------------------------------------------------------------
GENERAL.HWADDR:                         (unknown)
-------------------------------------------------------------------------------
GENERAL.MTU:                            1420
-------------------------------------------------------------------------------
GENERAL.STATE:                          100 (connected)
-------------------------------------------------------------------------------
GENERAL.CONNECTION:                     wg0
-------------------------------------------------------------------------------
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveC>
-------------------------------------------------------------------------------
IP4.ADDRESS[1]:                         172.16.1.2/32
IP4.GATEWAY:                            --
-------------------------------------------------------------------------------
IP6.GATEWAY:                            --
-------------------------------------------------------------------------------

上述输出显示接口 wg0 已连接。现在,它可以和虚拟私有网络 IP 地址为 172.16.1.254 的对等节点通信。

验证节点间通信

完成上述步骤后,两个对等节点可以通过虚拟私有网络连接相互通信,以下是 ICMP 测试结果:

[root@peerb ~]# ping 172.16.1.254 -c 4
PING 172.16.1.254 (172.16.1.254) 56(84) bytes of data.
64 bytes from 172.16.1.254: icmp_seq=1 ttl=64 time=0.566 ms
64 bytes from 172.16.1.254: icmp_seq=2 ttl=64 time=1.33 ms
64 bytes from 172.16.1.254: icmp_seq=3 ttl=64 time=1.67 ms
64 bytes from 172.16.1.254: icmp_seq=4 ttl=64 time=1.47 ms

在这种情况下,如果你在 PeerA 端口 60001 上捕获 UDP 通信,则将看到依赖 WireGuard 协议的通信过程和加密的数据:

捕获依赖 WireGuard 协议的节点间 UDP 流量

总结

虚拟私有网络很常见。在用于部署虚拟私有网络的各种协议和工具中,WireGuard 是一种简单、轻巧和安全的选择。它可以在对等节点之间基于 CryptoKey 路由建立安全的点对点连接,过程非常简单。此外,NetworkManager 支持 WireGuard 接口,允许重启后进行持久配置。


via: https://fedoramagazine.org/configure-wireguard-vpns-with-networkmanager/

作者:Maurizio Garcia 选题:lujun9972 译者:DCOLIVERSUN 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

这是有关 网络地址转换 network address translation (NAT)的系列文章中的第二篇。之前的第一篇文章介绍了 如何使用 iptables/nftables 的报文跟踪功能 来定位 NAT 相关的连接问题。作为第二部分,本文介绍 conntrack 命令,它允许你查看和修改被跟踪的连接。

引言

通过 iptables 或 nftables 配置的 NAT 建立在 netfilters 连接跟踪子系统之上。conntrack 命令作为 “conntrack-tools” 软件包的一部分,用于查看和更改连接状态表。

连接跟踪状态表

连接跟踪子系统会跟踪它看到的所有报文流。运行 sudo conntrack -L 可查看其内容:

tcp 6 43184 ESTABLISHED src=192.168.2.5 dst=10.25.39.80 sport=5646 dport=443 src=10.25.39.80 dst=192.168.2.5 sport=443 dport=5646 [ASSURED] mark=0 use=1
tcp 6 26 SYN_SENT src=192.168.2.5 dst=192.168.2.10 sport=35684 dport=443 [UNREPLIED] src=192.168.2.10 dst=192.168.2.5 sport=443 dport=35684 mark=0 use=1
udp 17 29 src=192.168.8.1 dst=239.255.255.250 sport=48169 dport=1900 [UNREPLIED] src=239.255.255.250 dst=192.168.8.1 sport=1900 dport=48169 mark=0 use=1

上述显示结果中,每行表示一个连接跟踪项。你可能会注意到,每行相同的地址和端口号会出现两次,而且第二次出现的源地址/端口对和目标地址/端口对会与第一次正好相反!这是因为每个连接跟踪项会先后两次被插入连接状态表。第一个四元组(源地址、目标地址、源端口、目标端口)记录的是原始方向的连接信息,即发送者发送报文的方向。而第二个四元组则记录的是连接跟踪子系统期望收到的对端回复报文的连接信息。这解决了两个问题:

  1. 如果报文匹配到一个 NAT 规则,例如 IP 地址伪装,相应的映射信息会记录在链接跟踪项的回复方向部分,并自动应用于同一条流的所有后续报文。
  2. 即使一条流经过了地址或端口的转换,也可以成功在连接状态表中查找到回复报文的四元组信息。

原始方向的(第一个显示的)四元组信息永远不会改变:它就是发送者发送的连接信息。NAT 操作只会修改回复方向(第二个)四元组,因为这是接受者看到的连接信息。修改第一个四元组没有意义:netfilter 无法控制发起者的连接状态,它只能在收到/转发报文时对其施加影响。当一个报文未映射到现有连接表项时,连接跟踪可以为其新建一个表项。对于 UDP 报文,该操作会自动进行。对于 TCP 报文,连接跟踪可以配置为只有 TCP 报文设置了 SYN 标志位 才新建表项。默认情况下,连接跟踪会允许从流的中间报文开始创建,这是为了避免对启用连接跟踪之前就存在的流处理出现问题。

连接跟踪状态表和 NAT

如上一节所述,回复方向的四元组包含 NAT 信息。你可以通过命令过滤输出经过源地址 NAT 或目标地址 NAT 的连接跟踪项。通过这种方式可以看到一个指定的流经过了哪种类型的 NAT 转换。例如,运行 sudo conntrack -L -p tcp –src-nat 可显示经过源 NAT 的连接跟踪项,输出结果类似于以下内容:

tcp 6 114 TIME_WAIT src=10.0.0.10 dst=10.8.2.12 sport=5536 dport=80 src=10.8.2.12 dst=192.168.1.2 sport=80 dport=5536 [ASSURED]

这个连接跟踪项表示一条从 10.0.0.10:5536 到 10.8.2.12:80 的连接。与前面示例不同的是,回复方向的四元组不是原始方向四元组的简单翻转:源地址已修改。目标主机(10.8.2.12)将回复数据包发送到 192.168.1.2,而不是 10.0.0.10。每当 10.0.0.10 发送新的报文时,具有此连接跟踪项的路由器会将源地址替换为 192.168.1.2。当 10.8.2.12 发送回复报文时,该路由器将目的地址修改回 10.0.0.10。上述源 NAT 行为源自一条 NFT 伪装#Masquerading) 规则:

inet nat postrouting meta oifname "veth0" masquerade

其他类型的 NAT 规则,例如目标地址 DNAT 规则或重定向规则,其连接跟踪项也会以类似的方式显示,回复方向四元组的远端地址或端口与原始方向四元组的远端地址或端口不同。

连接跟踪扩展

连接跟踪的记帐功能和时间戳功能是两个有用的扩展功能。运行 sudo sysctl net.netfilter.nf_conntrack_acct=1 可以在运行 sudo conntrack -L 时显示每个流经过的字节数和报文数。运行 sudo sysctl net.netfilter.nf_conntrack_timestamp=1 为每个连接记录一个开始时间戳,之后每次运行 sudo conntrack -L 时都可以显示这个流从开始经过了多少秒。在上述命令中增加 –output ktimestamp 选项也可以看到流开始的绝对时间。

插入和更改连接跟踪项

你可以手动为状态表添加连接跟踪项,例如:

sudo conntrack -I -s 192.168.7.10 -d 10.1.1.1 --protonum 17 --timeout 120 --sport 12345 --dport 80

这项命令通常被 conntrackd 用于状态复制,即将主防火墙的连接跟踪项复制到备用防火墙系统。于是当切换发生的时候,备用系统可以接管已经建立的连接且不会造成中断。连接跟踪还可以存储报文的带外元数据,例如连接跟踪标记和连接跟踪标签。可以用更新选项(-U)来修改它们:

sudo conntrack -U -m 42 -p tcp

这条命令将所有的 TCP 流的连接跟踪标记修改为 42。

删除连接跟踪项

在某些情况下,你可能想从状态表中删除条目。例如,对 NAT 规则的修改不会影响表中已存在流的经过报文。因此对 UDP 长连接(例如像 VXLAN 这样的隧道协议),删除表项可能很有意义,这样新的 NAT 转换规则才能生效。可以通过 sudo conntrack -D 命令附带可选的地址和端口列表选项,来删除相应的表项,如下例所示:

sudo conntrack -D -p udp  --src 10.0.12.4 --dst 10.0.0.1 --sport 1234 --dport 53

连接跟踪错误计数

conntrack 也可以输出统计数字:

# sudo conntrack -S
cpu=0 found=0 invalid=130 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=10
cpu=1 found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
cpu=2 found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=1
cpu=3 found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0

大多数计数器将为 0。Foundinsert 数将始终为 0,它们只是为了后向兼容。其他错误计数包括:

  • invalid:报文既不匹配已有连接跟踪项,也未创建新连接。
  • insert_failed:报文新建了一个连接,但插入状态表时失败。这在 NAT 引擎在伪装时恰好选择了重复的源地址和端口时可能出现。
  • drop:报文新建了一个连接,但是没有可用的内存为其分配新的状态条目。
  • early_drop:连接跟踪表已满。为了接受新的连接,已有的未看到双向报文的连接被丢弃。
  • error:icmp(v6) 收到与已知连接不匹配的 icmp 错误数据包。
  • search_restart:查找过程由于另一个 CPU 的插入或删除操作而中断。
  • clash_resolve:多个 CPU 试图插入相同的连接跟踪条目。

除非经常发生,这些错误条件通常无害。一些错误可以通过针对预期工作负载调整连接跟踪子系统的参数来降低其发生概率,典型的配置包括 net.netfilter.nf_conntrack_bucketsnet.netfilter.nf_conntrack_max 参数。可在 nf\_conntrack-sysctl 文档 中查阅相应配置参数的完整列表。

当报文状态是 invalid 时,请使用 sudo sysctl net.netfilter.nf_conntrack_log_invalid=255 来获取更多信息。例如,当连接跟踪遇到一个所有 TCP 标志位均为 0 的报文时,将记录以下内容:

nf_ct_proto_6: invalid tcp flag combination SRC=10.0.2.1 DST=10.0.96.7 LEN=1040 TOS=0x00 PREC=0x00 TTL=255 ID=0 PROTO=TCP SPT=5723 DPT=443 SEQ=1 ACK=0

总结

本文介绍了如何检查连接跟踪表和存储在跟踪流中的 NAT 信息。本系列的下一部分将延伸讨论连接跟踪工具和连接跟踪事件框架。


via: https://fedoramagazine.org/network-address-translation-part-2-the-conntrack-tool/

作者:Florian Westphal 选题:lujun9972 译者:cooljelly 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

这是有关 网络地址转换 network address translation (NAT)的系列文章中的第一篇。这一部分将展示如何使用 iptables/nftables 报文跟踪功能来定位 NAT 相关的连接问题。

引言

网络地址转换(NAT)是一种将容器或虚拟机暴露在互联网中的一种方式。传入的连接请求将其目标地址改写为另一个地址,随后被路由到容器或虚拟机。相同的技术也可用于负载均衡,即传入的连接被分散到不同的服务器上去。

当网络地址转换没有按预期工作时,连接请求将失败,会暴露错误的服务,连接最终出现在错误的容器中,或者请求超时,等等。调试此类问题的一种方法是检查传入请求是否与预期或已配置的转换相匹配。

连接跟踪

NAT 不仅仅是修改 IP 地址或端口号。例如,在将地址 X 映射到 Y 时,无需添加新规则来执行反向转换。一个被称为 “conntrack” 的 netfilter 系统可以识别已有连接的回复报文。每个连接都在 conntrack 系统中有自己的 NAT 状态。反向转换是自动完成的。

规则匹配跟踪

nftables 工具(以及在较小的程度上,iptables)允许针对某个报文检查其处理方式以及该报文匹配规则集合中的哪条规则。为了使用这项特殊的功能,可在合适的位置插入“跟踪规则”。这些规则会选择被跟踪的报文。假设一个来自 IP 地址 C 的主机正在访问一个 IP 地址是 S 以及端口是 P 的服务。我们想知道报文匹配了哪条 NAT 转换规则,系统检查了哪些规则,以及报文是否在哪里被丢弃了。

由于我们要处理的是传入连接,所以我们将规则添加到 prerouting 钩子上。prerouting 意味着内核尚未决定将报文发往何处。修改目标地址通常会使报文被系统转发,而不是由主机自身处理。

初始配置

# nft 'add table inet trace_debug'
# nft 'add chain inet trace_debug trace_pre { type filter hook prerouting priority -200000; }'
# nft "insert rule inet trace_debug trace_pre ip saddr $C ip daddr $S tcp dport $P tcp flags syn limit rate 1/second meta nftrace set 1"

第一条规则添加了一张新的规则表,这使得将来删除和调试规则可以更轻松。一句 nft delete table inet trace_debug 命令就可以删除调试期间临时加入表中的所有规则和链。

第二条规则在系统进行路由选择之前(prerouting 钩子)创建了一个基本钩子,并将其优先级设置为负数,以保证它在连接跟踪流程和 NAT 规则匹配之前被执行。

然而,唯一最重要的部分是第三条规则的最后一段:meta nftrace set 1。这条规则会使系统记录所有匹配这条规则的报文所关联的事件。为了尽可能高效地查看跟踪信息(提高信噪比),考虑对跟踪的事件增加一个速率限制,以保证其数量处于可管理的范围。一个好的选择是限制每秒钟最多一个报文或一分钟最多一个报文。上述案例记录了所有来自终端 $C 且去往终端 $S 的端口 $P 的所有 SYN 报文和 SYN/ACK 报文。限制速率的配置语句可以防范事件过多导致的洪泛风险。事实上,大多数情况下只记录一个报文就足够了。

对于 iptables 用户来讲,配置流程是类似的。等价的配置规则类似于:

# iptables -t raw -I PREROUTING -s $C -d $S -p tcp --tcp-flags SYN SYN  --dport $P  -m limit --limit 1/s -j TRACE

获取跟踪事件

原生 nft 工具的用户可以直接运行 nft 进入 nft 跟踪模式:

# nft monitor trace

这条命令会将收到的报文以及所有匹配该报文的规则打印出来(用 CTRL-C 来停止输出):

trace id f0f627 ip raw prerouting  packet: iif "veth0" ether saddr ..

我们将在下一章详细分析该结果。如果你用的是 iptables,首先通过 iptables –version 命令检查一下已安装的版本。例如:

# iptables --version
iptables v1.8.5 (legacy)

(legacy) 意味着被跟踪的事件会被记录到内核的环形缓冲区中。你可以用 dmesgjournalctl 命令来查看这些事件。这些调试输出缺少一些信息,但和新工具提供的输出从概念上来讲很类似。你将需要首先查看规则被记录下来的行号,并与活跃的 iptables 规则集合手动关联。如果输出显示 (nf_tables),你可以使用 xtables-monitor 工具:

# xtables-monitor --trace

如果上述命令仅显示版本号,你仍然需要查看 dmesg/journalctl 的输出。xtables-monitor 工具和 nft 监控跟踪工具使用相同的内核接口。它们之间唯一的不同点就是,xtables-monitor 工具会用 iptables 的语法打印事件,且如果你同时使用了 iptables-nftnft,它将不能打印那些使用了 maps/sets 或其他只有 nftables 才支持的功能的规则。

示例

我们假设需要调试一个到虚拟机/容器的端口不通的问题。ssh -p 1222 10.1.2.3 命令应该可以远程连接那台服务器上的某个容器,但连接请求超时了。

你拥有运行那台容器的主机的登录权限。现在登录该机器并增加一条跟踪规则。可通过前述案例查看如何增加一个临时的调试规则表。跟踪规则类似于这样:

nft "insert rule inet trace_debug trace_pre ip daddr 10.1.2.3 tcp dport 1222 tcp flags syn limit rate 6/minute meta nftrace set 1"

在添加完上述规则后,运行 nft monitor trace,在跟踪模式下启动 nft,然后重试刚才失败的 ssh 命令。如果规则集较大,会出现大量的输出。不用担心这些输出,下一节我们会做逐行分析。

trace id 9c01f8 inet trace_debug trace_pre packet: iif "enp0" ether saddr .. ip saddr 10.2.1.2 ip daddr 10.1.2.3 ip protocol tcp tcp dport 1222 tcp flags == syn
trace id 9c01f8 inet trace_debug trace_pre rule ip daddr 10.2.1.2 tcp dport 1222 tcp flags syn limit rate 6/minute meta nftrace set 1 (verdict continue)
trace id 9c01f8 inet trace_debug trace_pre verdict continue
trace id 9c01f8 inet trace_debug trace_pre policy accept
trace id 9c01f8 inet nat prerouting packet: iif "enp0" ether saddr .. ip saddr 10.2.1.2 ip daddr 10.1.2.3 ip protocol tcp  tcp dport 1222 tcp flags == syn
trace id 9c01f8 inet nat prerouting rule ip daddr 10.1.2.3  tcp dport 1222 dnat ip to 192.168.70.10:22 (verdict accept)
trace id 9c01f8 inet filter forward packet: iif "enp0" oif "veth21" ether saddr .. ip daddr 192.168.70.10 .. tcp dport 22 tcp flags == syn tcp window 29200
trace id 9c01f8 inet filter forward rule ct status dnat jump allowed_dnats (verdict jump allowed_dnats)
trace id 9c01f8 inet filter allowed_dnats rule drop (verdict drop)
trace id 20a4ef inet trace_debug trace_pre packet: iif "enp0" ether saddr .. ip saddr 10.2.1.2 ip daddr 10.1.2.3 ip protocol tcp tcp dport 1222 tcp flags == syn

对跟踪结果作逐行分析

输出结果的第一行是触发后续输出的报文编号。这一行的语法与 nft 规则语法相同,同时还包括了接收报文的首部字段信息。你也可以在这一行找到接收报文的接口名称(此处为 enp0)、报文的源和目的 MAC 地址、报文的源 IP 地址(可能很重要 - 报告问题的人可能选择了一个错误的或非预期的主机),以及 TCP 的源和目的端口。同时你也可以在这一行的开头看到一个“跟踪编号”。该编号标识了匹配跟踪规则的特定报文。第二行包括了该报文匹配的第一条跟踪规则:

trace id 9c01f8 inet trace_debug trace_pre rule ip daddr 10.2.1.2 tcp dport 1222 tcp flags syn limit rate 6/minute meta nftrace set 1 (verdict continue)

这就是刚添加的跟踪规则。这里显示的第一条规则总是激活报文跟踪的规则。如果在这之前还有其他规则,它们将不会在这里显示。如果没有任何跟踪输出结果,说明没有抵达这条跟踪规则,或者没有匹配成功。下面的两行表明没有后续的匹配规则,且 trace_pre 钩子允许报文继续传输(判定为接受)。

下一条匹配规则是:

trace id 9c01f8 inet nat prerouting rule ip daddr 10.1.2.3  tcp dport 1222 dnat ip to 192.168.70.10:22 (verdict accept)

这条 DNAT 规则设置了一个到其他地址和端口的映射。规则中的参数 192.168.70.10 是需要收包的虚拟机的地址,目前为止没有问题。如果它不是正确的虚拟机地址,说明地址输入错误,或者匹配了错误的 NAT 规则。

IP 转发

通过下面的输出我们可以看到,IP 路由引擎告诉 IP 协议栈,该报文需要被转发到另一个主机:

trace id 9c01f8 inet filter forward packet: iif "enp0" oif "veth21" ether saddr .. ip daddr 192.168.70.10 .. tcp dport 22 tcp flags == syn tcp window 29200

这是接收到的报文的另一种呈现形式,但和之前相比有一些有趣的不同。现在的结果有了一个输出接口集合。这在之前不存在的,因为之前的规则是在路由决策之前(prerouting 钩子)。跟踪编号和之前一样,因此仍然是相同的报文,但目标地址和端口已经被修改。假设现在还有匹配 tcp dport 1222 的规则,它们将不会对现阶段的报文产生任何影响了。

如果该行不包含输出接口(oif),说明路由决策将报文路由到了本机。对路由过程的调试属于另外一个主题,本文不再涉及。

trace id 9c01f8 inet filter forward rule ct status dnat jump allowed_dnats (verdict jump allowed_dnats)

这条输出表明,报文匹配到了一个跳转到 allowed_dnats 链的规则。下一行则说明了连接失败的根本原因:

trace id 9c01f8 inet filter allowed_dnats rule drop (verdict drop)

这条规则无条件地将报文丢弃,因此后续没有关于该报文的日志输出。下一行则是另一个报文的输出结果了:

trace id 20a4ef inet trace_debug trace_pre packet: iif "enp0" ether saddr .. ip saddr 10.2.1.2 ip daddr 10.1.2.3 ip protocol tcp tcp dport 1222 tcp flags == syn

跟踪编号已经和之前不一样,然后报文的内容却和之前是一样的。这是一个重传尝试:第一个报文被丢弃了,因此 TCP 尝试了重传。可以忽略掉剩余的输出结果了,因为它并没有提供新的信息。现在是时候检查那条链了。

规则集合分析

上一节我们发现报文在 inet filter 表中的一个名叫 allowed_dnats 的链中被丢弃。现在我们来查看它:

# nft list chain inet filter allowed_dnats
table inet filter {
 chain allowed_dnats {
  meta nfproto ipv4 ip daddr . tcp dport @allow_in accept
  drop
   }
}

接受 @allow_in 集的数据包的规则没有显示在跟踪日志中。我们通过列出元素的方式,再次检查上述报文的目标地址是否在 @allow_in 集中:

# nft "get element inet filter allow_in { 192.168.70.10 . 22 }"
Error: Could not process rule: No such file or directory

不出所料,地址-服务对并没有出现在集合中。我们将其添加到集合中。

# nft "add element inet filter allow_in { 192.168.70.10 . 22 }"

现在运行查询命令,它将返回新添加的元素。

# nft "get element inet filter allow_in { 192.168.70.10 . 22 }"
table inet filter {
   set allow_in {
      type ipv4_addr . inet_service
      elements = { 192.168.70.10 . 22 }
   }
}

ssh 命令现在应该可以工作,且跟踪结果可以反映出该变化:

trace id 497abf58 inet filter forward rule ct status dnat jump allowed_dnats (verdict jump allowed_dnats)

trace id 497abf58 inet filter allowed_dnats rule meta nfproto ipv4 ip daddr . tcp dport @allow_in accept (verdict accept)

trace id 497abf58 ip postrouting packet: iif "enp0" oif "veth21" ether .. trace id 497abf58 ip postrouting policy accept

这表明报文通过了转发路径中的最后一个钩子 - postrouting

如果现在仍然无法连接,问题可能处在报文流程的后续阶段,有可能并不在 nftables 的规则集合范围之内。

总结

本文介绍了如何通过 nftables 的跟踪机制检查丢包或其他类型的连接问题。本系列的下一篇文章将展示如何检查连接跟踪系统和可能与连接跟踪流相关的 NAT 信息。


via: https://fedoramagazine.org/network-address-translation-part-1-packet-tracing/

作者:Florian Westphal 选题:lujun9972 译者:cooljelly 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

在一个有许多加密磁盘的环境中,解锁所有的磁盘是一项困难的任务。 网络绑定磁盘加密 Network bound disk encryption (NBDE)有助于自动解锁 Stratis 卷的过程。这是在大型环境中的一个关键要求。Stratis 2.1 版本增加了对加密的支持,这在《Stratis 加密入门》一文中介绍过。Stratis 2.3 版本最近在使用加密的 Stratis 池时引入了对网络绑定磁盘加密(NBDE)的支持,这是本文的主题。

Stratis 网站 将 Stratis 描述为一个“易于使用的 Linux 本地存储管理”。短视频《使用 Stratis 管理存储》对基础知识进行了快速演示。该视频是在 Red Hat Enterprise Linux 8 系统上录制的,然而,视频中显示的概念也适用于 Fedora Linux 中的 Stratis。

先决条件

本文假设你熟悉 Stratis,也熟悉 Stratis 池加密。如果你不熟悉这些主题,请参考这篇 文章 和前面提到的 Stratis 概述视频

NBDE 需要 Stratis 2.3 或更高版本。本文中的例子使用的是 Fedora Linux 34 的预发布版本。Fedora Linux 34 的最终版本将包含 Stratis 2.3。

网络绑定磁盘加密(NBDE)概述

加密存储的主要挑战之一是有一个安全的方法在系统重启后再次解锁存储。在大型环境中,手动输入加密口令并不能很好地扩展。NBDE 解决了这一问题,允许以自动方式解锁加密存储。

在更高层次上,NBDE 需要环境中的 Tang 服务器。客户端系统(使用 Clevis Pin)只要能与 Tang 服务器建立网络连接,就可以自动解密存储。如果网络没有连接到 Tang 服务器,则必须手动解密存储。

这背后的想法是,Tang 服务器只能在内部网络上使用,因此,如果加密设备丢失或被盗,它将不再能够访问内部网络连接到 Tang 服务器,因此不会被自动解密。

关于 Tang 和 Clevis 的更多信息,请参见手册页(man tangman clevis)、Tang 的 GitHub 页面Clevis 的 GitHub 页面

设置 Tang 服务器

本例使用另一个 Fedora Linux 系统作为 Tang 服务器,主机名为 tang-server。首先安装 tang 包。

dnf install tang

然后用 systemctl 启用并启动 tangd.socket

systemctl enable tangd.socket --now

Tang 使用的是 TCP 80 端口,所以你也需要在防火墙中打开该端口。

firewall-cmd --add-port=80/tcp --permanent
firewall-cmd --add-port=80/tcp

最后,运行 tang-show-keys 来显示输出签名密钥指纹。你以后会需要这个。

# tang-show-keys
l3fZGUCmnvKQF_OA6VZF9jf8z2s

创建加密的 Stratis 池

上一篇关于 Stratis 加密的文章详细介绍了如何设置加密的 Stratis 池,所以本文不会深入介绍。

第一步是捕获一个将用于解密 Stratis 池的密钥。即使使用 NBDE,也需要设置这个,因为在 NBDE 服务器无法到达的情况下,可以用它来手动解锁池。使用以下命令捕获 pool1 密钥。

# stratis key set --capture-key pool1key
Enter key data followed by the return key:

然后我将使用 /dev/vdb 设备创建一个加密的 Stratis 池(使用刚才创建的 pool1key),命名为 pool1

# stratis pool create --key-desc pool1key pool1 /dev/vdb。

接下来,在这个 Stratis 池中创建一个名为 filesystem1 的文件系统,创建一个挂载点,挂载文件系统,并在其中创建一个测试文件:

# stratis filesystem create pool1 filesystem1
# mkdir /filesystem1
# mount /dev/stratis/pool1/filesystem1 /filesystem1
# cd /filesystem1
# echo "this is a test file" > testfile

将 Stratis 池绑定到 Tang 服务器上

此时,我们已经创建了加密的 Stratis 池,并在池中创建了一个文件系统。下一步是将你的 Stratis 池绑定到刚刚设置的 Tang 服务器上。使用 stratis pool bind nbde 命令进行。

当你进行 Tang 绑定时,需要向该命令传递几个参数:

  • 池名(在本例中,pool1
  • 钥匙描述符名称(本例中为 pool1key
  • Tang 服务器名称(在本例中,http://tang-server

记得之前在 Tang 服务器上,运行了 tang-show-keys,显示 Tang 输出的签名密钥指纹是 l3fZGUCmnvKQF_OA6VZF9jf8z2s。除了前面的参数外,还需要用参数 -thumbprint l3fZGUCmnvKQF_OA6VZF9jf8z2s 传递这个指纹,或者用 -trust-url 参数跳过对指纹的验证。

使用 -thumbprint 参数更安全。例如:

# stratis pool bind nbde pool1 pool1key http://tang-server --thumbprint l3fZGUCmnvKQF_OA6VZF9jf8z2s

用 NBDE 解锁 Stratis 池

接下来重启主机,并验证你可以用 NBDE 解锁 Stratis 池,而不需要使用密钥口令。重启主机后,该池不再可用:

# stratis pool list
Name Total Physical Properties

要使用 NBDE 解锁池,请运行以下命令:

# stratis pool unlock clevis

注意,你不需要使用密钥口令。这个命令可以在系统启动时自动运行。

此时,Stratis 池已经可以使用了:

# stratis pool list
Name Total Physical Properties
pool1 4.98 GiB / 583.65 MiB / 4.41 GiB ~Ca, Cr

你可以挂载文件系统,访问之前创建的文件:

# mount /dev/stratis/pool1/filesystem1 /filesystem1/
# cat /filesystem1/testfile
this is a test file

轮换 Tang 服务器密钥

最好定期轮换 Tang 服务器密钥,并更新 Stratis 客户服务器以使用新的 Tang 密钥。

要生成新的 Tang 密钥,首先登录到 Tang 服务器,查看 /var/db/tang 目录的当前状态。然后,运行 tang-show-keys 命令:

# ls -al /var/db/tang
total 8
drwx------. 1 tang tang 124 Mar 15 15:51 .
drwxr-xr-x. 1 root root 16 Mar 15 15:48 ..
-rw-r--r--. 1 tang tang 361 Mar 15 15:51 hbjJEDXy8G8wynMPqiq8F47nJwo.jwk
-rw-r--r--. 1 tang tang 367 Mar 15 15:51 l3fZGUCmnvKQF_OA6VZF9jf8z2s.jwk
# tang-show-keys
l3fZGUCmnvKQF_OA6VZF9jf8z2s

要生成新的密钥,运行 tangd-keygen 并将其指向 /var/db/tang 目录:

# /usr/libexec/tangd-keygen /var/db/tang

如果你再看看 /var/db/tang 目录,你会看到两个新文件:

# ls -al /var/db/tang
total 16
drwx------. 1 tang tang 248 Mar 22 10:41 .
drwxr-xr-x. 1 root root 16 Mar 15 15:48 ..
-rw-r--r--. 1 tang tang 361 Mar 15 15:51 hbjJEDXy8G8wynMPqiq8F47nJwo.jwk
-rw-r--r--. 1 root root 354 Mar 22 10:41 iyG5HcF01zaPjaGY6L_3WaslJ_E.jwk
-rw-r--r--. 1 root root 349 Mar 22 10:41 jHxerkqARY1Ww_H_8YjQVZ5OHao.jwk
-rw-r--r--. 1 tang tang 367 Mar 15 15:51 l3fZGUCmnvKQF_OA6VZF9jf8z2s.jwk

如果你运行 tang-show-keys,就会显示出 Tang 所公布的密钥:

# tang-show-keys
l3fZGUCmnvKQF_OA6VZF9jf8z2s
iyG5HcF01zaPjaGY6L_3WaslJ_E

你可以通过将两个原始文件改名为以句号开头的隐藏文件,来防止旧的密钥(以 l3fZ 开头)被公布。通过这种方法,旧的密钥将不再被公布,但是它仍然可以被任何没有更新为使用新密钥的现有客户端使用。一旦所有的客户端都更新使用了新密钥,这些旧密钥文件就可以删除了。

# cd /var/db/tang
# mv hbjJEDXy8G8wynMPqiq8F47nJwo.jwk   .hbjJEDXy8G8wynMPqiq8F47nJwo.jwk
# mv l3fZGUCmnvKQF_OA6VZF9jf8z2s.jwk   .l3fZGUCmnvKQF_OA6VZF9jf8z2s.jwk

此时,如果再运行 tang-show-keys,Tang 只公布新钥匙:

# tang-show-keys
iyG5HcF01zaPjaGY6L_3WaslJ_E

下一步,切换到你的 Stratis 系统并更新它以使用新的 Tang 密钥。当文件系统在线时, Stratis 支持这样做。

首先,解除对池的绑定:

# stratis pool unbind pool1

接下来,用创建加密池时使用的原始口令设置密钥:

# stratis key set --capture-key pool1key
Enter key data followed by the return key:

最后,用更新后的密钥指纹将 Stratis 池绑定到 Tang 服务器上:

# stratis pool bind nbde pool1 pool1key http://tang-server --thumbprint iyG5HcF01zaPjaGY6L_3WaslJ_E

Stratis 系统现在配置为使用更新的 Tang 密钥。一旦使用旧的 Tang 密钥的任何其他客户系统被更新,在 Tang 服务器上的 /var/db/tang 目录中被重命名为隐藏文件的两个原始密钥文件就可以被备份和删除了。

如果 Tang 服务器不可用怎么办?

接下来,关闭 Tang 服务器,模拟它不可用,然后重启 Stratis 系统。

重启后,Stratis 池又不可用了:

# stratis pool list
Name Total Physical Properties

如果你试图用 NBDE 解锁,会因为 Tang 服务器不可用而失败:

# stratis pool unlock clevis
Execution failed:
An iterative command generated one or more errors: The operation 'unlock' on a resource of type pool failed. The following errors occurred:
Partial action "unlock" failed for pool with UUID 4d62f840f2bb4ec9ab53a44b49da3f48: Cryptsetup error: Failed with error: Error: Command failed: cmd: "clevis" "luks" "unlock" "-d" "/dev/vdb" "-n" "stratis-1-private-42142fedcb4c47cea2e2b873c08fcf63-crypt", exit reason: 1 stdout: stderr: /dev/vdb could not be opened.

此时,在 Tang 服务器无法到达的情况下,解锁池的唯一选择就是使用原密钥口令:

# stratis key set --capture-key pool1key
Enter key data followed by the return key:

然后你可以使用钥匙解锁池:

# stratis pool unlock keyring

接下来,验证池是否成功解锁:

# stratis pool list
Name Total Physical Properties
pool1 4.98 GiB / 583.65 MiB / 4.41 GiB ~Ca, Cr

via: https://fedoramagazine.org/network-bound-disk-encryption-with-stratis/

作者:briansmith 选题:lujun9972 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出