ip6tables-save详解：IPv6防火墙规则备份与恢复实战

如果你在 Linux 上配置过 IPv6 防火墙，大概率经历过这样的场景：花半小时敲了一串ip6tables规则，各种链、各种匹配条件，好不容易调通了，结果一不小心按了重启，规则全没了，又得从头再来。或者你在一台机器上把 IPv6 规则调好，想在另一台机器上复现，结果只能对着屏幕一条一条重新敲。这时候你就知道ip6tables-save有多香了。

这个命令的作用很简单，就是把当前内核里生效的 IPv6 防火墙规则整体导出来，输出成可读的文本格式。注意关键词：内核。你平时用ip6tables增删改查的是内核网络协议栈里正在运行的规则，ip6tables-save做的就是把这些运行状态“拍照”下来，存成一个你肉眼能看懂、机器也能恢复回去的文本文件。配合ip6tables-restore，一套“导出—保存—恢复”的完整流程就有了。

这篇文章我会从命令的基本用法讲起，再到规则文件每一行怎么读、怎么写，接着给出一套完整的实战操作流程，最后把我实际运维中踩过的坑和排查思路一并列出来。适合谁看？搞 Linux 运维的系统工程师、网络管理员，以及嵌入式开发中需要处理 IPv6 网络的开发者。哪怕你对 iptables 还不熟，只要跟着操作一遍，也能很快上手。

1. ip6tables-save 到底是干嘛的

1.1 IPv6 防火墙管理的现实困境

很多人对 IPv6 网络的态度是“先跑起来再说”，地址配上、路由通掉，就以为万事大吉。真正做网络安全的人都知道，IPv6 环境下的防火墙策略复杂度和坑，一点不比 IPv4 少。IPv6 无状态地址自动配置、邻居发现协议、扩展头处理，每一项都会产生新的攻击面。这时候，如果你还是守在 IPv4 的老思路里，只用iptables管规则，IPv6 的流量就处于裸奔状态。

我之前在一台服务器上遇到过这样的情况：IPv4 的防火墙策略做得密不透风，端口全封了，结果 IPv6 地址忘了处理，攻击者直接通过 IPv6 地址绕了进来。原因很简单，iptables只处理 IPv4 流量，IPv6 流量由ip6tables单独管理。从技术层面上讲，这两套工具读写的是内核里完全不同的两张规则表，互不干扰。所以，管理 IPv6 防火墙必须专门用ip6tables这套工具链，ip6tables-save就是其中负责“导出快照”的那个角色。

1.2 ip6tables 工具家族的分工

ip6tables这个家族里，大家配合得比较紧密的有四个命令。ip6tables本身负责增删改查，配置规则；ip6tables-save负责把当前内核里的规则导出成文本，格式是可读的；ip6tables-restore负责把导出文件重新加载回内核；还有ip6tables-apply，不过这个用的相对少，主要是安全测试时临时应用规则，检测有问题会自动回滚。

这套分工其实是继承自 IPv4 时代的iptables工具链，设计得很成熟。ip6tables-save作为“拍照”工具，最大的好处在于它的输出格式是稳定的、机器可读的，这意味着你不仅能手动查看规则内容，还能在脚本里调用它做备份、做对比、做自动化部署。我在实际工作中最常用的一个做法，就是写完一堆 IPv6 规则后，马上执行ip6tables-save备份一份，防止后面改坏了能快速回滚。

2. 命令语法与核心参数一次讲透

2.1 最常用的三种调用方式

ip6tables-save的用法比ip6tables本身简单太多。它不像ip6tables那样有一大堆参数要记，基本就是一个“查看”工具，把内核里的规则导出来，没有额外的复杂选项。最常见的三种方式如下。

# 方式一：直接输出全部规则到终端 ip6tables-save # 方式二：导出到文件 ip6tables-save > /etc/ip6tables-rules.v6 # 方式三：只导出一张表（比如 filter 表） ip6tables-save -t filter

第一种方式适合快速看一眼当前规则状态；第二种是实际运维中最常用的，把规则备份下来；第三种适合你只关心某一张表的时候用。默认情况下，ip6tables-save会把内核中所有表的规则全部导出，包括 filter、mangle、raw、security 这些常见的表。如果你想节省输出量或者排查方向很明确，用-t指定表就能聚焦看某一类规则。

2.2 参数细节：-c、-t、-f

虽然命令本身就三个参数，但每个参数背后的含义和使用场景值得认真展开。

-t参数上面提到了，指定导出的表名。例如--table filter只会导出 filter 表的规则。做这个参数的时候，有个容易忽略的细节：-t和--table是等价的，但如果你同时用了多个-t，后面一个会覆盖前面一个，不会有报错。我就遇到过在脚本里写了两遍-t，结果导出结果和自己预想的不一样，排查半天才发现是参数覆盖的问题。

-c参数是用来导出计数器（counter）信息的。规则和计数器是绑定的，计数器记录该规则匹配了多少个包、多少字节。默认情况下ip6tables-save不会输出计数器，加上-c之后，每条规则前面会出现类似[12:3456]形式的计数。这个参数在性能分析和流量统计场景下很有用，但要注意的是，计数器导出后再恢复，会把当前的计数也一并恢复进去，这可能会干扰你对流量变化趋势的判断。

-f参数在部分版本中可用，含义是“过滤掉特定规则”，比如按照规则编号或者特定表项来过滤。不过说实话，这个参数在ip6tables-save上的使用率不高，不同 Linux 发行版的内核版本对这个参数的支持也不完全一致。我在 CentOS 7 和 Ubuntu 20.04 上测试过，有些老版本对-f的解析就是简单的通配符匹配，不太稳定，所以如果你只想导出某类特定规则，我的建议是直接用grep过滤输出结果，而不是依赖-f。

2.3 导出文件的字段含义

ip6tables-save导出的文件，看到的人第一反应可能是：这什么玩意儿？一堆符号和字母。其实它的格式非常规整，读懂之后你会发现这就是一套“规则描述语言”。

文件的第一行是一串注释，以#开头，记录了生成该文件的时间，大概是这样的：

# Generated by ip6tables-save v1.8.2 on Fri Jan 6 10:30:00 2024

这一行纯粹是给人类看的，恢复规则的时候会被自动忽略。接着是按表分组的规则段，每一段的开头是*表名，比如*filter就表示接下来是 filter 表的规则。表名之后是链的定义，格式是这样的：

:INPUT ACCEPT [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0]

冒号后面是链名，紧接着是这条链的默认策略，方括号里是计数器。比如:INPUT ACCEPT [0:0]的意思就是：INPUT 链的默认策略是 ACCEPT，当前匹配了 0 个包、0 字节。这个计数如果加了-c参数才会被包括在输出中，但链定义的这一行，不管加不加都会显示计数器。

再往下就是具体的规则条目了，每一行以-A开头，表示追加到某条链，后面的-s、-p、-j等标志和你平时敲ip6tables命令时用的完全一样。比如：

-A INPUT -s 2001:db8::/32 -p tcp -m tcp --dport 22 -j ACCEPT

这条规则的意思是：来自2001:db8::/32网段的 TCP 流量，目标是 22 端口，放行。文件末尾是COMMIT，表示这一段规则结束，恢复操作执行到COMMIT时才会真正把这一整段规则提交到内核中。

3. 实战演示：导出、检查、恢复一条龙

3.1 实操环境说明

我这里以一台 Ubuntu 20.04 的服务器为例演示。系统自带ip6tables和ip6tables-save，版本是 iptables v1.8.4。要确认你的环境里有没有这两个命令，可以执行which ip6tables-save，如果有输出就说明已经装了。如果没有，在 Ubuntu/Debian 上安装 iptables 工具包即可，在 CentOS/RHEL 上则是yum install iptables-services。这里我补充一个容易踩的坑：很多精简安装的 Linux 系统默认只装了iptables，但ip6tables-save不在其中，需要额外安装iptables的完整套件才能使用。

在开始之前，我先往内核里添加几条 IPv6 规则，模拟一个真实场景：允许回环接口流量，允许本网段的 SSH 访问，其他外部 IPv6 访问默认拒绝。下面的命令里，我故意把规则写得规范和复杂一点，方便后面展示导出文件的样子。

# 清空现有规则（注意：这条会清空所有 IPv6 规则，慎用） ip6tables -F # 设置默认策略 ip6tables -P INPUT DROP ip6tables -P FORWARD DROP ip6tables -P OUTPUT ACCEPT # 允许回环接口 ip6tables -A INPUT -i lo -j ACCEPT # 允许本网段 SSH 访问（假设网段是 2001:db8:1::/64） ip6tables -A INPUT -s 2001:db8:1::/64 -p tcp --dport 22 -m state --state NEW -j ACCEPT # 允许已建立的连接和相关的回包流量 ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

3.2 把规则导出到文件

规则添加好以后，导出就非常简单了。直接执行：

ip6tables-save > my-firewall.rules

然后查看文件内容：

cat my-firewall.rules

输出大概是这个样子的：

# Generated by ip6tables-save v1.8.4 on Sat Feb 3 14:22:11 2024 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -s 2001:db8:1::/64 -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT COMMIT

注意看-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT这一行，我敲命令的时候写的是ESTABLISHED,RELATED，但保存后它自动变成了RELATED,ESTABLISHED。这是内核处理规则时对状态匹配顺序做了归一化，不影响实际效果，但理解这一点有助于你在手写规则文件时不要过度纠结顺序。

导出的文件里，表的顺序也是固定的，一般 filter 表排在最前面，然后是 mangle、raw、security 等，这是由内核中表的初始化顺序决定的，不是随机排列。

3.3 恢复规则到内核

恢复操作利用的是ip6tables-restore，它读取ip6tables-save导出的文件，把规则重新加载进内核。命令格式如下：

ip6tables-restore < my-firewall.rules

执行完以后可以再调用ip6tables-save检查一遍，看看恢复结果是否和预期一致。这里有个细节值得说明：ip6tables-restore默认会先清空对应表里的所有规则，再加载文件中的规则，也就是说它做的是一个“整表替换”的操作，不是增量追加。这个特性既是优点也是风险。优点是恢复前不用手动清空，缺点是如果文件里的规则不完整，恢复后可能丢失部分策略。如果你希望恢复时清空所有规则再重建，可以加-F参数，不过默认情况下 restore 执行到COMMIT时也会把未包含在文件里的链重置。

我个人的习惯是：恢复之前先手动执行一次ip6tables -F清空，再用ip6tables-restore加载，这样整个状态是最干净的。尤其在多张表并存的情况下，避免旧规则残留导致行为怪异。

3.4 让规则开机自动加载

规则恢复是一次性操作，重新启动后又会丢失。要解决这个问题，最简单的办法是把规则文件放在固定位置，然后用 systemd 服务在开机时自动恢复。不同发行版内置的机制不太一样，我重点说 Ubuntu 和 CentOS 的两种常见做法。

在 Ubuntu 上，很多人会写一个 systemd service。我先创建一个服务文件：

[Unit] Description=Restore IPv6 firewall rules Before=network-pre.target Wants=network-pre.target [Service] Type=oneshot ExecStart=/usr/sbin/ip6tables-restore /etc/ip6tables-rules.v6 RemainAfterExit=yes [Install] WantedBy=multi-user.target

然后启用服务：

sudo systemctl enable ip6tables-restore.service sudo systemctl start ip6tables-restore.service

在 CentOS 7/8 上，如果装了iptables-services包，通常会有现成的ip6tables服务，规则文件放在/etc/sysconfig/ip6tables，直接用systemctl enable ip6tables && systemctl start ip6tables即可。

这里有一个很重要的注意点：systemd 服务设置Before=network-pre.target是有讲究的。防火墙规则要在网络接口配置前就位，否则接口配置阶段产生的 IPv6 邻居发现广播等流量可能绕过防火墙。虽然 IPv6 邻居发现报文走的是链路层的特殊通道，不会被 filter 表拦截，但整体顺序还是越早加载越好。

4. 规则文件格式深度拆解

4.1 行结构逐段解读

有些场景下，你可能不满足于只在命令行交互式操作，而是希望直接修改规则文件、批量添加规则，然后一次性恢复进去。这时候就需要彻底读懂ip6tables-save生成的每一行。

前面已经提过，规则文件由*表名开始，链定义、规则条目、COMMIT结束。我来逐段拆解一下一个实际文件。

第一段是标题和注释信息：

# Generated by ip6tables-save v1.8.4 on Sat Feb 3 14:22:11 2024

这些注释行在恢复时会被忽略。但我在实际调试中经常故意往规则文件里加自己的注释，用#开头，标注这条规则是干嘛的、什么时候加的、针对什么问题添加的。因为ip6tables-restore会自动跳过所有注释行，这种“留痕”做法对团队协作非常友好，相当于给规则写了一份免费文档。

接下来是链定义：

*filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0]

这三行的含义前面已经解释过。补充一个容易忽略的点：链定义里的默认策略可以是ACCEPT、DROP、QUEUE或RETURN。如果你写了一个自定义链，它也会出现在这里，默认策略通常是-。比如你创建过MYCHAIN这个自定义链，在保存文件里就是:MYCHAIN - [0:0]。

再往下是规则条目，每一条规则的格式其实和你在终端敲命令时几乎一样，只是少了命令本身。举个例子：

-A INPUT -s 2001:db8:1::/64 -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT

这一行对应你敲的命令是：

ip6tables -A INPUT -s 2001:db8:1::/64 -p tcp --dport 22 -m state --state NEW -j ACCEPT

你会发现保存文件里多了-m tcp，这是ip6tables在匹配 TCP 协议时自动加载的扩展模块，属于输出规范化的一部分。另外，顺序上也有些微调，比如-m state --state NEW会被移动到--dport 22后面。理解了这些细小的差异，你在手写规则文件时就不会被看似“多出来”的片段搞懵。

4.2 手工编辑规则文件的安全姿势

既然规则文件是纯文本，自然可以手工编辑。但手工编辑有风险，稍有不慎就会导致恢复失败。我给出手工编辑时的三个原则。

第一，编辑前先备份原文件。这一步看似多余，但关键时刻能救命。我吃过一次亏，编辑规则文件时不小心删掉了一行-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT，恢复规则后 SSH 连接直接断掉，因为已经建立的连接也不通了。如果没有备份，就得去物理控制台或者带外管理系统恢复网络，非常狼狈。

第二，修改规则后，先用ip6tables-restore --test尝试验证文件格式。这个参数会解析文件，如果语法有问题会直接报错，不会真正修改内核规则。我在 Ubuntu 20.04 上测试过，--test能发现大部分常见的格式错误，比如缺少COMMIT、链名拼写不对、匹配条件写错。不过要提醒一句，--test只负责语法检查，不检查规则是否存在逻辑错误，比如你把端口写成 22 口而不是 22，如果格式正确它不会报错，这就需要自己多留个心眼。

第三，编辑完成后恢复前，先临时开启一个额外的 “逃生通道”。最稳妥的做法是：如果你是通过 SSH 远程管理的，不要直接把规则文件里的 SSH 端口规则删掉或改掉，可以先在规则文件里多留一条临时放行规则，恢复成功后再调整。或者使用screen或tmux会话执行恢复操作，万一断连还能重连回去看状态。这些习惯是真的能救命的。

4.3 多张表并存时的处理

一个完整的ip6tables-save输出往往不止 filter 表，还包含 mangle、raw、security 等表。如果你用ip6tables-save不做任何参数导出全部表，文件里会包含多段。每段各自以*表名开头，以COMMIT结束。

恢复多张表时，ip6tables-restore会按文件的顺序依次处理各张表。需要注意：如果你在raw表里配置了NOTRACK规则，它会影响到后面 filter 表的连接跟踪状态，只有当整个文件全部恢复完成后，所有表才同时生效。所以，如果你发现某条规则没有生效，不要只看 filter 表，还要检查 mangle 和 raw 表是否有相关跳转或标记操作。这类问题隐蔽性很强，我在一次 IPv6 网关配置中排查了半天，最后发现是 mangle 表里的一条MARK规则把流量打上了标记，filter 表的规则基于这个标记做了不同处理，逻辑链条是这样的：mangle 的规则比想象中影响更大。

还有一个经验：多次导出。如果你想快速比较当前内核规则和文件规则的区别，可以分别执行ip6tables-save并输出到两个文件，再用diff比较。比如：

ip6tables-save > now.rules diff now.rules my-firewall.rules

这样就能清楚地看到哪些规则是后来添加的，哪些被删除了。这个技巧在我审计规则变更时帮了大忙，特别是多人共同维护服务器时，有了 diff 结果，就能知道某条规则是谁在什么时候改的。当然，前提是前面说的，养成在规则文件里写注释的习惯。

5. 常见问题与排查技巧实录

5.1 命令不存在或权限不足

最典型的问题就是执行ip6tables-save时报错，提示command not found。这和之前提到的精简安装有关。就算系统里有ip6tables，也不一定有ip6tables-save。如果你用的是 Ubuntu/Debian，执行下面命令安装：

sudo apt update sudo apt install iptables ip6tables

如果是 CentOS/RHEL，执行：

sudo yum install iptables-services

安装完成后，ip6tables-save和ip6tables-restore都会出现。再强调一次，ip6tables-save需要 root 权限执行，因为要读取内核中的规则表。普通用户执行会遇到Permission denied，不过好消息是，即使是 root 身份执行，ip6tables-save不会对内核规则做任何修改，它只是读取，这一点可以放心。

5.2 导出的规则恢复时报错

恢复时报错最常遇到的场景是ip6tables-restore: line 10 failed之类的提示。这种报错说明文件第 10 行附近有问题。常见的原因有以下几种：

• 文件格式混合了 IPv4 的语法。比如你误把iptables-save的输出和ip6tables-save的输出拼在了一个文件里。IPv4 地址如192.168.1.0/24放在 IPv6 规则里，ip6tables-restore肯定不认。
• 链定义和规则条的链名不一致。比如链定义写的是:INPUT DROP [0:0]，规则条却写成了-A INPT -s ...，那明显拼接错了。
• 缺少COMMIT。如果没有COMMIT，ip6tables-restore会一直等待，最后报错。

排查的思路是：用ip6tables-restore --test做语法验证，它会告诉你具体哪一行有问题。如果没有--test，你也可以把规则文件分段恢复，比如先用编辑器删掉一部分，看哪一段恢复失败，用二分法快速定位。

5.3 IPv6 规则莫名丢失

我有段时间很困惑：明明恢复了规则，过了一阵子再去执行ip6tables-save，发现规则少了几条。最后发现是两个原因。第一个原因是其他脚本也在操作ip6tables，比如某些服务启动时会调用ip6tables -F清空规则，或者安全软件会在自己启动时接管防火墙。第二个原因是有人用了ip6tables-restore恢复了一个不完整的文件，整表替换后旧规则全部被冲掉了。

这个问题在容器化环境里尤其常见。Docker、Kubernetes 这些容器网络组件会动态修改 iptables/ip6tables 规则，如果规则文件和它们的操作冲突，就会出现“规则被覆盖”的现象。排查思路是：在规则丢失的时间点，查看系统日志里有没有相关操作记录，同时检查有没有其他守护进程在调用 ip6tables 工具。我的建议是，如果你在公司内部使用容器平台，对 IPv6 防火墙规则的变更尽量做变更评审，走过流程，避免规则被半路截胡。

5.4 常见问题速查表

6. 实际运维中的扩展玩法

6.1 定时备份防火墙规则

规则备份是个好习惯，尤其是生产环境。我习惯用 cron 每天备份一次规则，保留最近几份历史，这样如果哪天发现规则被改动、网络行为异常，可以在历史备份里找到“正常时期”的规则进行对比。

#!/bin/bash # /usr/local/sbin/backup-ip6tables.sh BACKUP_DIR="/var/backups/firewall" STAMP=$(date +%Y%m%d-%H%M%S) mkdir -p "$BACKUP_DIR" ip6tables-save > "$BACKUP_DIR/ip6tables-$STAMP.rules" find "$BACKUP_DIR" -name 'ip6tables-*.rules' -mtime +7 -delete

然后在 crontab 里加一行：

0 2 * * * /usr/local/sbin/backup-ip6tables.sh

注意备份文件的权限。防火墙规则里可能包含内部网段信息，虽然不是密码级别，但属于敏感的配置数据，建议chmod 600限制只有 root 能读取。

6.2 与 systemd 集成实现可靠加载

前面提到的 systemd service 方案可以做得更精细。如果你有多张表、多个配置文件的需求，可以编写一个支持通配符加载的脚本。我写过一个加载器，它会扫描某个目录下的所有.rules文件，按文件名字母顺序依次恢复。这样做的好处是，你可以把规则按业务模块拆分成不同文件，例如99-drop-all.rules、10-allow-ssh.rules，方便单独调整而不影响其他部分。

我提醒一个实践中的细节：ip6tables-restore默认是“整表替换”，如果你按文件拆分，就要特别注意每个文件包含的是不同的表或者不同逻辑段的规则。比如一个文件只管理 filter 表，另一个文件只管理 mangle 表，这样恢复时才不会互相覆盖。如果两个文件都对 filter 表做了操作，后加载的文件很可能会把先加载文件的规则清掉，产生难以察觉的规则缺失。

6.3 在脚本中动态修改规则

很多自动化场景下，运维脚本会临时添加规则，比如某个安全加固任务需要临时封禁某个 IPv6 地址。脚本里常见做法是：先ip6tables-save把当前规则保存到变量，再添加临时规则，等任务完成后用ip6tables-restore把原规则恢复回来。

# 封禁临时 IP ORIGINAL_RULES=$(ip6tables-save) ip6tables -A INPUT -s $BAD_IP -j DROP # 业务逻辑处理... # 处理完毕，恢复原有规则 echo "$ORIGINAL_RULES" | ip6tables-restore

这种基于“保存—修改—恢复”的脚本模式比手动记录增删的规则要可靠得多，因为你不需要精确知道加了多少条规则、删了多少条，整体恢复就好。要注意的是，变量里如果包含特殊字符，恢复时 echo 加管道的方式要注意引号，最好直接用printf输出。这里我踩过坑：脚本里用了echo "$ORIGINAL_RULES"，结果某些环境变量里带了斜杠，echo 解析时没处理好，导致恢复失败。后面改成：

printf '%s\n' "$ORIGINAL_RULES" | ip6tables-restore

执行效果很稳。

6.4 和 IPv4 规则联动的思路

虽然iptables-save和ip6tables-save是两套独立工具，但在实际项目中，IPv4 和 IPv6 的防火墙策略往往需要一起规划和审计。你可以分别导出两份规则文件，统一命名备份，并在变更文档里注明哪些规则是同时影响双栈的。比如某条规则在 IPv4 里放行了 80 端口，但在 IPv6 里忘了配，就会导致 IPv6 用户访问不了网站。这类“双栈一致性”问题，靠人工对着两份文件检查效率很低，建议写一段小脚本把两个文件里相同策略的部分做归一化比对。如果你在配置 IPv6 访问控制时，参考过类似于“华三 IPv6 ACL 配置实验”的流程，你就会理解为什么这类一致性检查如此重要。很多网络设备上，IPv4 和 IPv6 的 ACL 是分开配置的，漏配任何一端都会造成访问异常。

我个人在实际操作中有一个小习惯：任何 IPv6 防火墙规则变更完成后，一定顺手执行一次ip6tables-save > /etc/ip6tables-rules.v6，把最新状态固化下来。这不只是为了备份，更像是一种“工作闭环”的仪式感。改完规则不保存，你永远不知道自己哪一天会因为这个懒散动作付出代价。说到底，ip6tables-save这个命令本身简单到不能再简单，但把它用好的关键，是你在多大程度上愿意为自己的网络环境建立起“规则即代码、规则可追溯、规则可回滚”的工程化意识。这条经验，是我在多次半夜爬起来抢救防火墙配置之后，总结出来的最真心的一句体会。