高可用集群心跳失败若源于防火墙拦截，须直查通信端口与协议：corosync用udp 5404–5405，keepalived用vrrp（ip 112），需分别验证监听、放行规则及抓包确认连通性。
高可用集群心跳失败，如果根源是防火墙拦截，排查要直奔通信端口和协议，不能只看服务是否在跑。
确认集群用的是哪种心跳机制
不同方案依赖的协议和端口完全不同：
- Corosync 默认走 UDP 5404–5405 端口（多播或单播），必须用
ss -uln | grep ':540'验证监听状态 - Keepalived 使用 VRRP 协议（IP 协议号 112），不是 TCP/UDP 端口，需用
iptables -L INPUT -n | grep 112或nft list chain inet filter input检查是否放行 - 某些自定义脚本或 Pacemaker 的 ping 类资源可能依赖 ICMP，但不推荐作为主心跳——它无法区分网络分区和真实宕机
检查防火墙实际放行规则
关闭防火墙只是临时验证手段，真正要定位问题，得看规则是否生效：
- RHEL/CentOS 8+ 用
firewall-cmd --list-all，重点看ports和icmp-blocks区域；若用了 rich rules，执行firewall-cmd --list-rich-rules - Ubuntu/Debian 系统若启用 ufw，运行
ufw status verbose，确认对应端口或协议的状态是ALLOW - 直接使用 iptables 的环境，检查 INPUT 链：关注是否有
-p 112（VRRP）或-p udp --dport 5404:5405规则，且位置不能被前面的 DROP 规则拦截
验证节点间底层连通性是否真被阻断
别只依赖 ping 或 telnet，它们测的不是心跳用的路径：
- 对 Corosync：在节点 A 执行
nc -u 5404 -w1，再在节点 B 上用tcpdump -i any udp port 5404抓包，看有没有进来的 UDP 包 - 对 Keepalived：在节点 A 运行
tcpdump -i any ip proto 112，同时在节点 B 启动 Keepalived，观察是否有 VRRP 广播/组播报文发出并被对方收到 - 注意网卡绑定和多路径：如果心跳走的是专用网卡（如 eth2），确保防火墙规则作用在对应接口，而不是默认的 eth0
检查日志里有没有明确的拒绝记录
系统级日志会留下痕迹，比凭空猜测更可靠：
- 启用防火墙日志后，
journalctl -u firewalld --since "1 hour ago" | grep DROP可看到被丢弃的数据包详情 - Corosync 日志（
/var/log/cluster/corosync.log）中出现Cannot send message或no route to host时，配合抓包基本能锁定是防火墙还是路由问题 - Keepalived 日志（默认在
/var/log/messages或 journal）若反复报recv buffer size too small或no interface found for VRRP，也可能是防火墙干扰了内核协议栈处理
