咱们一步步来排查这个问题，毕竟有时候看似奇怪的现象，根源往往是容易忽略的细节：

1. 先确认iptables封禁规则是否真的生效 #

Fail2ban是依托iptables实现IP封禁的，所以第一步得检查规则有没有被正确写入：

• 执行命令查看INPUT链的详细规则：

  sudo iptables -L INPUT -v -n
  

  你要找的是类似DROP tcp -- xxx.xxx.xxx.xxx 0.0.0.0/0 tcp dpt:22的条目，或者有没有名为fail2ban-SSH的专属链（因为你的action配置是iptables[name=SSH,...]，理论上会生成这个链）。
• 如果没看到对应封禁IP的规则，先尝试重启Fail2ban服务再检查：

  sudo systemctl restart fail2ban
  

2. 检查iptables规则的顺序 #

就算规则存在，顺序不对也会直接失效。比如如果你的INPUT链里有一条ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22的允许规则，放在了Fail2ban的DROP规则前面，那么流量会先被允许，封禁规则等于摆设。

• 执行命令查看规则的顺序编号：

  sudo iptables -L INPUT --line-numbers
  

  确保fail2ban-SSH链的引用（或者直接的DROP封禁规则）排在所有允许SSH连接的规则之前。如果顺序不对，你需要调整iptables规则顺序，或者修改Fail2ban的action配置，让它把规则插入到正确位置。

3. 确认SSH服务的实际监听端口 #

你的jail配置里写的是port=ssh（默认22端口），但如果你的SSH服务已经改成了其他端口（比如2222），那Fail2ban封禁的是22端口，自然挡不住实际的SSH连接：

• 检查SSH的监听端口：

  sudo ss -tulpn | grep sshd
  

  看输出里的LISTEN行，比如tcp LISTEN 0 128 *:2222 *:* users:(("sshd",pid=1234,fd=3))就说明端口是2222。
• 如果是这种情况，修改jail.local里的ssh-iptables段，把port=ssh改成实际端口（比如port=2222），然后重启Fail2ban。

4. 排查firewalld的干扰 #

openSUSE Leap 42.2默认可能运行firewalld，它会和纯iptables规则产生冲突，导致Fail2ban的封禁规则失效：

• 先检查firewalld状态：

  sudo systemctl status firewalld
  

  如果显示active，有两种解决方式：
  • 禁用firewalld，改用iptables：

    sudo systemctl stop firewalld
    sudo systemctl disable firewalld
    sudo systemctl enable iptables
    sudo systemctl start iptables
    

  • 或者修改Fail2ban的action配置，适配firewalld：
    将ssh-iptables里的action改成：

    action = firewallcmd-ipset[name=SSH, port=ssh, protocol=tcp]
    

    之后重启Fail2ban。

5. 验证Fail2ban的封禁状态 #

确认Fail2ban确实把测试IP加入了封禁列表：

• 查看ssh-iptables jail的状态：

  sudo fail2ban-client status ssh-iptables
  

  输出里的Banned IP list应该包含你的测试IP。
• 查看Fail2ban日志（通常在/var/log/fail2ban.log），确认有没有Ban xxx.xxx.xxx.xxx的记录，同时留意是否有无法添加iptables规则的报错信息。

6. 最后检查ignoreip配置 #

虽然你写的ignoreip = 127.0.0.1/8 192.168.1.0/24，但还是确认下你的测试IP不在这个网段里——比如如果测试IP是192.168.1.100，那会被Fail2ban直接忽略，不会触发封禁。

按照上面的步骤逐一排查，应该能定位到问题所在。

内容的提问来源于stack exchange，提问作者Greg