商用前必读：LFM2.5-24B-A2B-GGUF 授权协议详解与 LFM Open License v1.0 合规注意事项清单
2026/10/22 7:01:32
干这行十多年，跟iptables打过交道无数次。说实话，市面上讲iptables的教程一抓一大把，但大多数要么是命令堆砌的“字典”，要么是云里雾里的原理复读，真正打开一台服务器就能照着落地解决问题的，少之又少。这份东西不是一个入门简介，而是我平时接服务器、排查问题、做安全加固时反复用到的配置手册，从核心概念到实战套路再到踩坑记录，一次说清楚。
1. iptables到底是什么东西
1.1 从“一张规则表”理解iptables
不理解iptables的人，总觉得它像个黑盒子，敲两行命令能通，删掉一行又不通了，诡异得很。说白了，iptables就是Linux内核里netfilter框架的用户态管理工具，你通过iptables写入的每一条规则，实际上都是在告诉内核：“来了一个包，怎么处理它，你来按我说的做。”
把netfilter想象成公司门口的保安亭，数据包就是来来往往的访客。保安的脑子里装着一条一条的条例：“穿黑衣服的放行，背包的登记一下，没预约的直接请走”。iptables干的事，就是让你能编辑保安脑子里的条例，而且这套条例支持非常精细的条件——从哪来、去哪、什么协议、什么端口、什么时间段，都能写进去。内核处理每个数据包的速度极快，因为它不需要理解业务逻辑，只需要在一串规则里逐条做“是”还是“否”的判断。
所以要玩转iptables，第一件事不是背命令，而是理解它的工作模型：操作系统里的每个数据包，在流经网络协议栈的不同阶段，会经过一张“流量检查点”的关卡列表。这些关卡，官方叫链（Chain），而每个链上挂着一条条规则，形成一个有先后顺序的名单。你写的规则，本质上就是在给这个名单插队或追加。
1.2 四张表、五条链，先记住这两个数字
初次接触iptables的人，最烦的就是“四表五链”的说法。这里我不搞死记硬背，先给它剥开。
所谓五条链，其实就是数据包在Linux主机内部流转时会经过的五个检查点：
- PREROUTING：数据包刚进入网卡、还没做路由决策时经过的点。
- INPUT：数据包经过路由决策后，确认要发给本机进程时经过的点。
- FORWARD：数据包经过路由决策后，确认要转发给别的机器时经过的点。
- OUTPUT：本机进程发出的数据包，刚离开进程时经过的点。
- POSTROUTING：数据包即将离开网卡、发往外部前经过的最后一个点。
再来看四张表。表可以理解成“按功能归类的规则集”，不同表长在相同链上，各管一段：
| 表名 | 主要职责 | 常见挂在哪些链 |
|---|---|---|
| filter | 过滤、放行、拒绝，防火墙的核心 | INPUT、FORWARD、OUTPUT |
| nat | 网络地址转换，改源/改目的IP | PREROUTING、POSTROUTING、OUTPUT |
| mangle | 修改包的头部字段、打标记 | 五条链都能挂 |
| raw | 跳过连接追踪的“免检通道” | PREROUTING、OUTPUT |
平时最常打交道的，90%都是filter表和nat表。mangle和raw属于进阶玩法，多数场景根本轮不到用它们。很多教程上来就给你列四张表，让人望而生畏，实际使用中却用不上，这就是为什么很多人学iptables总觉得“学了一堆用不上”。
1.3 数据包在链里的完整旅程
为了把概念落在实处，我带你看一个数据包的完整旅程。假设一台服务器有外网网卡eth0，内网网卡eth1，同时承担着对外web服务和内网网关的角色。
一个从外网访问服务器80端口的请求，数据包到达eth0之后，第一步跨入PREROUTING链。如果在这里配置了DNAT规则（比如把80端口映射到内网某台机器上），就会在这里改写目的地址。接着内核做路由判断：如果目的IP是本机，就进入INPUT链，由filter表决定是放行还是丢弃；如果目的IP已经被改成内网机器，就进入FORWARD链；如果数据包是从本机进程发出，则直接走OUTPUT链。无论哪种情况，在真正离开主机之前，它还会经过POSTROUTING链，这一站是SNAT（源地址转换）的舞台。
如果你在POSTROUTING里写了MASQUERADE，那这个包出去的时候，源IP会被改写成出口网卡的IP，内网机器就借此共享上网了。
搞清楚这个流向，你才能回答“规则到底该加在哪个链”这个问题。加错了链，就像是在保安亭的后门贴了个前门告示，毫无用处。
2. 规则怎么写给电脑看：匹配与动作拆解
2.1 规则的构成：条件加动作
一条iptables规则，不管命令写得多长，本质上就是在回答两个问题：什么包和怎么办。
iptables -A INPUT -s 192.168.10.5 -p tcp --dport 22 -j DROP拆开来看：
-A INPUT：追加到INPUT链。-s 192.168.10.5：匹配条件是源地址为192.168.10.5。-p tcp：协议为TCP。--dport 22：目的端口为22。-j DROP：匹配后执行的动作是丢弃。
整句话翻译成人话就是：“凡是来自192.168.10.5这台机器、访问本机22端口的TCP流量，统统丢掉。”
这里有个关键点需要强调：iptables是自上而下逐条匹配的，数据包在链里一进来，就从第一条规则开始对比。只要命中某一条规则，就立刻执行对应的动作，后面的规则不会再看到这个包。这就好比发传单的人，只要一个人接了传单就走了，后面的人再递他也不会接。所以规则顺序极度重要，我把这个坑放到后面专门讲。
2.2 常用匹配条件详解
匹配条件是规则的“门槛”，也是iptables最强大的地方。我按实战中使用频率从高到低给你列一份清单：
- 地址类：
-s源地址，-d目的地址。支持单个IP，也支持CIDR网段，比如-s 10.0.0.0/24意思就是整个10.0.0.x网段。 - 接口类：
-i指定数据包从哪个网卡进来的，-o指定从哪个网卡出去。比如-i eth0就匹配“从eth0进来”的包。 - 协议类：
-p tcp、-p udp、-p icmp，不写默认匹配所有协议。 - 端口类：
--dport目的端口、--sport源端口，通常要和-p配合使用。 - 状态类：通过
-m state --state NEW,ESTABLISHED,RELATED或-m conntrack --ctstate来匹配连接状态。这是新手最看不懂但又极其重要的一项。
状态匹配单独拿出来说，它解决了一个核心问题：你放行了本机主动发出去的连接，怎么在外网回应回来的时候认出它是“老朋友”而不是“陌生人”。
Linux内核会维护一张连接追踪表，记录系统中所有的连接状态。一个数据包到达INPUT链时，conntrack模块早就在后台判断好了它属于什么状态：
- NEW：新发起的连接的第一个包。
- ESTABLISHED：已经是活跃连接的一部分，比如你ssh连出去后，服务器回给你的那些包。
- RELATED：跟已有连接相关的辅助连接，典型例子是FTP的数据连接。
- INVALID：根本无法识别的垃圾包，这种包通常直接丢掉，留着百害无一利。
有了状态匹配，你就可以写出这样的经典规则：外面进来的包，只有是“已建立连接”的回包才放行，新连接则走其他规则逐条判断。
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -m conntrack --ctstate INVALID -j DROP这两条规则一上，服务器对外暴露的端口就由你自己掌控了。注意顺序，一定要把“放行回包”放在先，不然你会遇到“能出去但回不来”的诡异状况。
2.3 动作的取舍：DROP与REJECT的区别
动作（-j后面跟的东西）里，新手最先接触的三个是ACCEPT、DROP、REJECT。ACCEPT不用多解释，放走。重点说说DROP和REJECT。
- DROP：包直接扔掉，不回复任何信息。发送方看到的现象就是“发出去没反应，一直等，直到超时”。
- REJECT：包会被扔掉，但会回应一个错误消息（比如
connection refused），发送方会立刻收到拒绝。
大多数人刚学时觉得“DROP更安全”，其实这是有代价的。如果你把服务器SSH端口设置成DROP所有外部访问，从你公司网络连过去，每次都要等到超时才知道连不上，体验极其糟糕。而REJECT虽然“礼貌地亮了红灯”，却等于告诉扫描的人“这个端口有机器活跃着”。所以两者没有绝对好坏，取决于场景：对外隐藏存在感的服务用DROP，对内网不必要端口的拒绝用REJECT，排查问题时REJECT更直观。
还有两个高级且常用的动作必须提及：DNAT和SNAT，这俩是nat表里的灵魂，后面讲端口转发会用到。DNAT是改目的地址（把访问本机某端口的包转给内网某台机器），SNAT是改源地址（让内网包以网关身份出去）。
2.4 规则的增删改查实操
配置iptables，你逃不掉这几个基础命令。先记住，iptables不加-t参数时默认操作的是filter表，操作其他表要显式加-t 表名。
查看当前所有规则：
iptables -L -n -v-L列出规则，-n不做域名解析（否则会卡在DNS查询上），-v显示详细信息。这是在服务器上最常用的检查命令。我习惯再带上--line-numbers，给每行规则标上序号，后面按序号删规则非常方便：
iptables -L -n --line-numbers追加一条规则：
iptables -A INPUT -s 10.0.0.0/8 -j DROP-A是append，拼到链的末尾。如果想把规则插到最前面（或者指定位置），用-I：
iptables -I INPUT 1 -s 10.0.0.0/8 -j DROP意思是把这条规则插到INPUT链的第1位，排在所有规则之前。这个能力在调整规则优先级时极其好用，比如发现某条规则被前面的规则压住了，你可以用-I插到前面去。
删除规则有两个办法。一种是按内容原样删除：
iptables -D INPUT -s 10.0.0.0/8 -j DROP另一种是按序号删除：
iptables -D INPUT 3第二种更快更精准，前提是你先用--line-numbers查到了序号。删除的时候务必睁大眼睛，删错一条动态修改的规则可能瞬间让业务瘫痪。
清空所有规则、重置默认策略：
iptables -F iptables -P INPUT ACCEPT-F清空链上所有规则，-P设置默认策略。这是“救火”操作的第一步，遇到规则写坏导致连不上时，先执行这两条，把服务器恢复到“放行一切”的裸奔状态，再慢慢排查。
3. 实战场景一：服务器安全加固套路
3.1 默认策略怎么定：白名单还是黑名单
很多新手配置服务器防火墙时，习惯一开始就-P INPUT DROP，把默认策略设成全部拒绝，然后再写一条条放行规则。这个思路本身没错，但实操起来非常容易翻车，尤其是在远程机器上操作时，忘放行了一个端口，SSH直接就断，人都上不去，只能去机房或者靠带外管理。
我的建议是：在配置前先确认两条兜底规则。第一步，把SSH来源限制在你能接受的范围内；第二步，在默认策略改成DROP之前，先把放行规则全部写好，并且最后留一条“允许已建立连接回来”的规则。下面给出一个稳妥的加固顺序：
# 1. 先放行回包和已建立的连接 iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # 2. 放行SSH，来源限制为公司出口IP iptables -A INPUT -p tcp -s 203.0.113.0/24 --dport 22 -j ACCEPT # 3. 放行HTTP和HTTPS iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT # 4. 放行本地回环接口，防止内部通信异常 iptables -A INPUT -i lo -j ACCEPT # 5. 最后再改默认策略 iptables -P INPUT DROP这个顺序是我踩过多次坑之后总结出的黄金顺序。如果把第5步提前做，而第1步还没写，那么你当前这台服务器上所有对外TCP连接的回包都会被拦，站在用户角度看就是“网站能打开首页但刷新不了任何数据”。
还有一点，回环接口（lo）的放行容易被忽略。很多本机程序之间通过127.0.0.1通信，比如Nginx反代到本机的某个服务端口，如果loopback被DROP，本机互访直接断掉，现象极其隐蔽。
3.2 用iptables实现简单的防扫描与限速
在公网上开的服务器，每天被扫描是家常便饭。你打开/var/log/syslog或者journalctl看一眼，一片一片的SSH爆破尝试。iptables虽然没有那些专业入侵防御系统花哨，但配合recent模块也能做基础防护。
比如说，限制每分钟内新建的SSH连接次数，超过的直接丢：
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 --name SSH -j DROP拆解一下：第一条规则把每个新连接记录到名为SSH的清单里；第二条规则检查，如果60秒内这个来源IP已经发起了5次以上新连接，就把后续的包丢弃。这个防爆破的思路是：一个正常运维人员不会在一分钟内跳5次SSH连接，但脚本会。
限速同理，用limit模块可以控制ICMP或者UDP的流量速率：
iptables -A INPUT -p icmp -m limit --limit 5/s -j ACCEPT iptables -A INPUT -p icmp -j DROP这里的意思是一秒钟最多放行5个ICMP包，多余的丢弃。--limit 5/s可以改成10/minute等单位，实际使用中顺手就能算清楚：一个“/s”等于每秒多少个包，“/minute”就是每分钟多少个包，没有复杂的换算。
3.3 加固时的常见误区
加固过程中有几个坑，我每年都要帮人擦几次屁股。
第一个误区是忽略icmp类型。有人想“那我干脆把ICMP全禁掉，服务器就隐身了”，结果禁完之后，别人ping不通，自己的机器往外ping也不通，排查网络问题时连测通断的基本工具都没了。更麻烦的是，某些路径上的分片报文需要依赖ICMP才能正常传输，全禁可能导致大包传输一直失败。我通常只限制ICMP的速率，而不是完全封死。
第二个误区是在远程服务器上没留后手就动了默认策略。如果你的服务器不在手边、没有带外管理，先把所有需要放行的规则写完，再切默认DROP策略。最好再开一个临时终端窗口，把规则save到文件里随时准备restore。否则一个手滑，人在机房外，网络全断，急死人不偿命。
第三个误区是改完规则不保存就重启系统。这种场景特别多：你临时手动加了规则，调试通了，服务器跑了一阵子，某次因为内核升级重启了，然后业务就再也连不上了，因为规则是纯内存里的，重启全部归零。这个问题后面专门讲持久化方案。
4. 实战场景二：NAT与端口转发配置
4.1 内网共享上网：SNAT与MASQUERADE
很多公司内网拓扑是：一台Linux服务器充当网关，外网网卡eth0接公网，内网网卡eth1接交换机，内网机器全走它上网。实现这个需求的核心就是SNAT。
最直接的SNAT写法：
iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth0 -j SNAT --to-source 203.0.113.5意思是：从192.168.10.0/24网段过来、要从eth0出去的数据包，把源地址改写成203.0.113.5这台服务器的公网IP。这样内网机器发出的包到达外网时，看起来都来自同一个公网IP，回应也能原路返回。
但如果这台网关的公网IP是动态获取的（比如家庭宽带PPPoE拨号），IP一变，上面的规则就失效了。此时要用MASQUERADE：
iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth0 -j MASQUERADEMASQUERADE最大的特点就是自动动态获取出口网卡的当前IP来做源地址转换，不管IP怎么变都不用改规则。代价是每条新连接都要动态查询一次IP，性能比固定SNAT略低一点。所以办公网络长期固定公网IP的，建议用SNAT；IP不固定的，直接用MASQUERADE，这是最合适的取舍。
还有一件新手必踩的事：配置好了NAT，却发现内网机器还是上不了网。原因大概率是Linux内核默认关闭了IPv4转发功能。看一下：
sysctl net.ipv4.ip_forward如果输出net.ipv4.ip_forward = 0，说明内核压根不允许转发，NAT规则再对也没用。临时开启：
sysctl -w net.ipv4.ip_forward=1永久开启：编辑/etc/sysctl.conf，写入net.ipv4.ip_forward = 1，然后执行sysctl -p生效。这一步是NAT配置里最容易漏掉的“前置条件”，我见过太多人折腾了一下午NAT，最后发现只是没开转发开关。
4.2 端口映射：把公网端口转到内网
需求很常见：内网有一台机器跑了某个服务，但公网用户想直接访问它。又不能给它一个公网IP，那就让服务器当“端口搬运工”，用DNAT把访问自己公网IP特定端口的流量，转给内网机器的特定端口。
典型的配置：
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 192.168.10.8:80意思是：从eth0进来、访问本机8080端口的TCP包，目的地址直接改成192.168.10.8的80端口。
但DNAT只改了目的地址，数据包到了FORWARD链时，还需要filter表放行，否则转发被拦在半路。所以必须同时加一条FORWARD规则：
iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 80 -d 192.168.10.8 -j ACCEPT这里的-o eth1是转发出去要走的网卡，-d 192.168.10.8是真终点。这步很容易被忽略，大多数人配完PREROUTING后测试不通，四处怀疑，最后发现是FORWARD链挡住了。事实上，如果你前面用了严格的默认DROP策略而又没给FORWARD留放行余地，那NAT基本都不会通。
还有一种转发场景，你希望内网那台服务发出的回应包也能正常回来，需要配合POSTROUTING做源地址转换（否则受访的机器看到源IP是内网某个机器，回包直接走内网路由，状态就乱了）。所以常见的完整NAT端口转发是“PREROUTING做DNAT + FORWARD放行 + POSTROUTING做SNAT/MASQUERADE”，三者缺一不可。
4.3 转发时网卡选择的关键点
配置FORWARD规则时，很多人搞不清楚-i和-o到底哪个是进来的、哪个是出去的。我提供一个锚点记忆法：-i看的是“包从哪里进的”，-o看的是“包要从哪里出的”，它们的视角是数据包，不是服务器。数据包从eth0进、即将从eth1出，那么FORWARD规则上就写-i eth0 -o eth1。如果你写反了，数据包到了FORWARD链时，因为-i不匹配，规则直接跳过，包被默认策略丢弃。
碰到复杂的多网卡场景，我建议先在命令行里用iptables -L FORWARD -v观察一下，配合tcpdump看包到底卡在哪条链上，比反复猜测高一万倍效率。
5. 规则的保存与开机自动加载
5.1 为什么重启会丢规则
iptables的规则存储在内存中，它正常运行时不依赖任何磁盘上的配置文件。机器一重启，内核重新初始化，所有规则清零。你要是没做持久化，重启之后就回到“裸奔”状态。
不同发行版提供了不同的保存机制。RHEL/CentOS系通常装了iptables-services，用：
systemctl enable iptables service iptables save保存后规则会写入/etc/sysconfig/iptables，之后每次开机自动恢复。Debian/Ubuntu系则常用netfilter-persistent或iptables-persistent：
apt install iptables-persistent netfilter-persistent save规则默认保存在/etc/iptables/rules.v4和/etc/iptables/rules.v6。
我个人的习惯是，无论在哪个发行版上，都手动执行一遍最原始的备份方式：
iptables-save > /etc/iptables.rules.bakiptables-save会把当前内存里的所有规则导出成文本格式，这个>.bak文件就是一个可以直接vi编辑的规则脚本。恢复时执行：
iptables-restore < /etc/iptables.rules.bak这种方式的好处是：备份文件不绑定发行版的服务框架，任何机器上都能用。我在跨平台迁移防火墙规则时，经常直接把iptables-save导出的文件拷到新机器上再restore，省去一条条重敲命令的功夫。
5.2 开机自动加载的多种姿势
如果你不想安装额外的工具和服务，纯手动做个启动脚本也是可以的。在/etc/rc.local（前提是它存在且有执行权限）里加一行：
iptables-restore < /etc/iptables.rules.bak或者写成systemd单元文件，放到/etc/systemd/system/iptables-restore.service：
[Unit] Description=Restore iptables rules Before=network-pre.target [Service] Type=oneshot ExecStart=/usr/sbin/iptables-restore /etc/iptables.rules.bak RemainAfterExit=yes [Install] WantedBy=multi-user.target然后：
systemctl daemon-reload systemctl enable iptables-restore这种方式的好处是完全自控，不依赖发行版预装的服务，适合那些被精简过、没有安装额外软件包的系统。我在最小化安装的服务器上经常这么干，少装一个包就少一个攻击面。
5.3 保存规则时的实际经验
实际运维中，我强烈建议每改完一组规则，立刻save一份。这是因为iptables没有undo功能，你手动改了十条规则，想要精确回退某一条，只能靠记忆去找。保存文件就是你的存档点，出了问题restore回去，成本最低。
还有个小技巧：保存前镖一眼当前规则是否正常，比如iptables -L -n -v确认没有语法错误、规则顺序正确。然后再save。不然把一份“带病规则”存成启动脚本，服务器下次重启自动加载了病态规则，那就麻烦大了，尤其要检查有没有把默认策略误存成DROP，否则一重启就断网。
6. 常见故障速查与排查心得
6.1 规则没生效，先查这五件事
我处理过很多“我加了规则但不管用”的问题，九成出在这几个地方，按顺序排查基本能定位：
- 规则加错表和链。比如你做了端口映射却加在
-t filter，或者DNAT加到了POSTROUTING而不是PREROUTING。先执行iptables -t nat -L -n -v看nat表里的实际规则。 - 规则顺序被前面的规则拦截。iptables从上往下匹配，假如你前面已经有一条
-s 0.0.0.0/0 -j ACCEPT，后面写的任何DROP都是摆设。用--line-numbers看顺序。 - 没有放行回包。光放行了出去的SYN包，回来的时候被DROP，表现为连接超时。检查是否写了
ESTABLISHED,RELATED放行规则。 - FORWARD链没放行。DNAT只在nat表里改了目的地址，FORWARD链的filter表规则会继续处理数据包，默认DROP策略下必须显式放行。
- 系统转发开关没开。
net.ipv4.ip_forward=0，转发直接不工作，内网包到不了外网，命令执行多少次NAT都白搭。
6.2 规则重启后丢失
这个问题往往在重启后业务中断时才被发现。如果你执行iptables-save没反应，或者systemctl status iptables显示服务未启用，说明规则压根没做持久化。按上一章的内容，要么用发行版自带的服务保存规则，要么写systemd单元自启，选一个就行。我建议你在配置好规则的第一时间就做持久化，不要等。
还有一点很容易被忽视：如果你同时在用firewalld或者ufw这类上层工具，再手动操作iptables，两边会发生规则冲突。firewalld底层也是netfilter，但它有自己的规则管理机制。手动保存的iptables规则可能会在firewalld重载时被覆盖，或者互相踢掉对方的规则。规范做法是选一套管理工具，要么纯用firewalld，要么纯用iptables，不要混着来。我在给公司机器做基线时，会先明确禁用firewalld服务，再启用iptables服务，避免后患。
6.3 手滑写错规则导致断连的救火手段
远程管理服务器，最怕的就是写错默认策略，把自己挡在外面。遇到这种情况不要慌，先想清楚自己还有没有别的通道：云控制台有没有VNC/带外管理？有没有其他跳板机？有通道的话直接登上去，执行：
iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT iptables -F这三条命令的意思是重置所有默认策略为ACCEPT，然后清空所有规则，服务器立刻恢复裸奔状态。之后再重新梳理防火墙规则。如果是通过计划任务、定时脚本自动改的规则，还要记得先把那个脚本停掉，不然后脚又给你加上。
救火归救火，我更推荐防患于未然：写关键规则前，先保留一个能自动恢复的备份，比如执行规则前先跑一遍iptables-save存盘，改完确认无误后再覆盖保存。这个习惯能省下无数个焦头烂额的深夜。
6.4 我的一些个人心得
最后说几点这些年攒下的体会。
第一，iptables的核心价值不是“背命令”，而是“理解数据包的流向”。很多运维人员能背出几十条规则，但出了问题依旧手忙脚乱，就是因为没搞懂规则挂在哪个链、匹配顺序是什么。把四表五链的流转记在脑子里，大部分问题都能自己推出来。
第二，大段大段添加规则时，最好用脚本文件，而不要一条条在shell里敲。把规则写进一个shell脚本，每一行注释清楚用途，既能当存档，又能随时chmod +x执行。我自己常用的是一个“先刷干净再灌新规则”的脚本模板：开头iptables -F、设默认策略，接着逐条加载规则，最后iptables-save落盘。这样既能保证每次部署的环境一致，也方便快速回滚。
第三，iptables在职场上不会过时。虽然有firewalld、nftables这些新一代方案，但大量存量服务器依然跑着iptables，特别是那些要求极简、稳定、不折腾的老系统。掌握iptables，本质上掌握的是netfilter框架的底层逻辑，换到nftables只是语法变化，思路完全通用，学一遍永远不吃亏。