集群内部节点端口阻断需聚焦真实通信路径：Corosync用UDP 5404–5405，Keepalived用IP协议112，ZooKeeper用2888/3888；须验证监听、防火墙放行（含规则顺序）、抓包确认双向连通，并查日志中DROP或拒绝记录。
集群内部节点端口阻断，不能只看“服务起来没”或“ping得通”，得聚焦通信路径的真实通行能力。核心是确认心跳/数据协议对应的具体端口或协议号是否被防火墙、网卡策略或系统规则拦截，且收发双向都畅通。
先确认集群用的是哪种通信机制
不同高可用方案依赖完全不同的底层协议：
-
Corosync/Pacemaker 默认走 UDP 5404–5405（多播或单播），必须用
ss -uln | grep ':540'在每个节点上验证监听状态，注意绑定地址是否为0.0.0.0或专用心跳网卡 IP -
Keepalived 用 VRRP 协议（IP 协议号 112），不是端口概念，需检查防火墙是否放行
-p 112，命令如iptables -L INPUT -n | grep 112或nft list chain inet filter input -
ZooKeeper 集群节点间通信走 2888（选举）和 3888（数据同步），客户端连接是 2181；要用
netstat -tuln | grep -E ':(2888|3888|2181)'确认监听，且telnet node-ip 2888仅能测 TCP 连通性，不能替代真实选举流量验证
查防火墙是否真放行了对应规则
关闭防火墙只是辅助验证，关键要定位规则是否生效、位置是否合理：
- RHEL/CentOS 8+：运行
firewall-cmd --list-all，重点看ports（如5404-5405/udp）、icmp-blocks和rich rules；若用了 rich rule，补查firewall-cmd --list-rich-rules - Ubuntu/Debian + ufw：执行
ufw status verbose，确认目标端口或协议的状态列为ALLOW，且策略应用在正确的INCOMING方向 - 直接使用 iptables/nftables：检查
INPUT链中是否有匹配规则，尤其注意顺序——若前面有REJECT或DROP规则，且位置靠前，后续放行规则将不生效
用抓包验证底层通信是否真正抵达
别依赖 telnet 或 nc -zv，它们无法复现真实协议行为：
- 对 Corosync：在节点 A 执行
nc -u -w1 nodeB-ip 5404 < /dev/null，同时在节点 B 运行tcpdump -i eth2 udp port 5404 -nn -c 2（指定心跳网卡），看是否收到 UDP 包 - 对 Keepalived：在节点 A 运行
tcpdump -i eth2 ip proto 112 -nn -c 2，启动 Keepalived 后观察是否有 VRRP 报文发出；在节点 B 同样抓包，确认能否收到 - 若抓不到包，但
ping和telnet都通，基本可锁定是防火墙未放行协议/端口，或网卡绑定策略（如 bond mode）干扰了多播/组播转发
看日志找拒绝痕迹
系统不会默默丢包，会留下线索：
- 启用防火墙日志后：
journalctl -u firewalld --since "30 minutes ago" | grep DROP可看到被拦截的源 IP、目标端口/协议号 - Corosync 日志（
/var/log/cluster/corosync.log）出现Cannot send message或No route to host，结合抓包结果，能区分是防火墙拦截还是路由/网卡问题 - Keepalived 日志（通常在
/var/log/messages或 journal）反复报VRRP_Instance(XXX) Dropping received VRRP packet...，大概率是协议 112 被拦或校验失败
