keepalived的auth_pass实际有效长度为8字节，超出部分被截断；主备端必须字节级一致，否则因md5摘要不匹配导致认证失败、心跳中断、vip不漂移。

Keepalived 的 auth_pass 并没有严格意义上的“长度限制”，但它的实际有效性高度依赖于 VRRP 协议的认证机制和底层实现——它只取前 8 字节作为认证密钥，超出部分会被截断。若主备节点配置的密码字面长度不同、或包含不可见字符（如空格、换行、制表符），极易导致认证失败，表现为心跳中断、状态卡在 INIT、VIP 不漂移等现象。

为什么 auth_pass 超长或不一致会通信失败

VRRP 协议规范（RFC 3768）规定 PASS 认证使用固定 8 字节密钥参与 MD5 摘要计算。Keepalived 实现中会自动截断或补零至 8 字节，但**截断逻辑对两端必须完全一致**。常见陷阱包括：

• 主节点配 auth_pass 123456789（9位），备节点配 auth_pass 12345678（8位）→ 实际都取前 8 字节，看似一致，但若备节点配置文件末尾有隐藏空格（如 12345678 ），则截断后变成 12345678 vs 12345678（含空格），MD5 值不同
• 使用特殊字符（如中文、$、@）时，若编码不统一（UTF-8 vs Latin-1），同样导致字节序列不一致
• 密码含前导/尾随空格，keepalived -t 不报错，但运行时认证静默失败

快速验证 auth_pass 是否真正匹配

不要仅靠肉眼比对配置文件，应通过以下方式交叉确认：

• 在两台机器上分别执行：
  echo -n "your_auth_pass_here" | od -An -t x1 | tr -d ' '
  对比输出的 16 进制字节流是否完全一致（必须是 16 个字符，即 8 字节）
• 检查配置文件实际内容是否含不可见字符：
  cat -A /etc/keepalived/keepalived.conf | grep auth_pass
^I 表示 Tab，$ 表示行尾， （空格）需特别注意
• 启用 Keepalived 调试日志，在 vrrp_instance 块中加入：
  log_detail
  重启后查看 journalctl -u keepalived -n 50，搜索 auth 或 bad auth 关键词

安全又兼容的 auth_pass 配置建议

为规避截断与编码风险，推荐采用以下实践：

• 统一使用 8 位纯 ASCII 字符：如 auth_pass Keep2026、auth_pass HA8bytes，避免数字+字母混合以外的符号
• 禁止使用引号包裹密码（auth_pass "123" 是错误写法，引号会被当作密码一部分）
• 配置后务必执行语法检查：
  keepalived -t -f /etc/keepalived/keepalived.conf
  即使通过，也不代表认证有效，仍需抓包验证
• 配合抓包确认认证是否生效：
  tcpdump -i eth0 -nn -v port 112 | grep -i "auth"
  正常应看到 Authentication Type: Simple Password (1) 且无 Auth Failure

当 auth_pass 疑似失效时的替代方案

如果反复验证仍无法定位问题，可临时绕过认证环节快速判断是否为根本原因：

• 将两端 auth_type 改为 NOPASS（仅限内网可信环境测试）
• 或改用 auth_type AH（IPSec 认证头，更安全但需内核支持，且配置复杂度上升）
• 更推荐的做法是切换为单播模式（unicast_src_ip + unicast_peer），既避开组播干扰，也弱化对 auth_pass 的强依赖

本质上，auth_pass 不是“长度问题”，而是“字节一致性问题”。盯住那 8 个字节，比盯着密码有多长更管用。