iptables加单个IP白名单需用-I INPUT插入允许规则并确保位于默认DROP之前，否则无效；firewalld则须用rich rule精确控制IP+端口，且需重载生效；连不上时优先排查防火墙状态、云安全组及服务监听地址。
iptables 怎么加单个 IP 白名单规则
直接生效、不重启服务的白名单，核心就是 iptables -I INPUT 插入一条允许规则，并确保它在默认拒绝规则之前。很多人加了规则但没生效，本质是顺序错了——iptables 规则按顺序匹配，一旦匹配到 DROP 就终止，后面再允许也没用。
实操建议：
- 先查当前链顺序：
iptables -nL INPUT --line-numbers，确认默认策略（POLICY DROP或ACCEPT）和已有规则位置 - 插入允许规则（假设只放行 192.168.1.100 的 SSH）：
iptables -I INPUT -s 192.168.1.100 -p tcp --dport 22 -j ACCEPT - 如果默认策略是
ACCEPT，必须额外加一条显式DROP结尾（否则白名单形同虚设）：iptables -A INPUT -j DROP - 加完务必保存：
iptables-save > /etc/iptables/rules.v4（Debian/Ubuntu）或service iptables save（CentOS 6），否则重启就丢
firewalld 开放指定 IP 访问某端口（CentOS 7+/RHEL 8）
firewalld 不支持传统“白名单”概念，而是靠 rich rules 实现 IP 级控制。直接用 --add-source 只能绑定 zone，不能限制端口；真要精确到「某个 IP + 某个端口」，必须写 rich rule。
常见错误现象：执行 firewall-cmd --add-source=192.168.1.100 后发现所有端口都通了——因为这只是把该 IP 划进 public zone，而 public zone 默认允许 ssh、dhcpv6-client 等服务，不是真正意义上的“仅开放指定端口”。
正确做法：
- 写 rich rule（例如只允 192.168.1.100 访问 8080）：
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.100" port port="8080" protocol="tcp" accept' - 别忘了重载：
firewall-cmd --reload - 检查是否生效：
firewall-cmd --list-rich-rules，注意输出里必须含accept，不是reject或drop - 如果已有
--add-port=8080/tcp全局开放，得先删掉，否则 rich rule 会被绕过
为什么加了白名单还是连不上？三个高频漏点
白名单配置本身没问题，但连接失败往往卡在更底层或外围环节。排查时优先看这三项：
-
iptables或firewalld确实运行中：systemctl status iptables或systemctl status firewalld，有些系统默认没开防火墙，你白忙活半天 - 云服务器（阿里云/腾讯云/AWS）有安全组，它在防火墙外层拦截，必须单独配。即使本地
iptables放行了，安全组没开，照样连不通 - 目标服务监听地址不是
0.0.0.0，比如nginx配了listen 127.0.0.1:80，那外部 IP 再白名单也没用——得改成listen *:80或具体内网 IP
要不要用 ufw？简单场景可以，但别信“自动管理”
ufw 是 iptables 的封装，适合桌面或轻量 VPS。但它对白名单的支持很弱：没有原生命令直接加「IP+端口」组合规则，只能靠 ufw allow from 192.168.1.100 to any port 22 这种语法，而且实际生成的 iptables 规则顺序容易混乱。
使用场景明确的话可以省事，但要注意：
- 启用前先关掉其他防火墙：
systemctl stop firewalld && systemctl disable firewalld，否则冲突 -
ufw默认日志关着，调试时务必开：ufw logging on，日志在/var/log/ufw.log - 别依赖
ufw app list里的预设模板，像OpenSSH模板只开 22 端口，不校验来源 IP——白名单还得自己加 rich rule 级别的指令
复杂网络策略下，直接写 iptables 或 firewalld rich rules 更可控，封装层反而增加理解成本
