keepalived 的 auth_pass 是 vrrp 报文校验凭证而非加密密钥，必须全节点严格一致（含大小写、无空格特殊符、最多取前8字符），否则导致静默失败；它不加密报文，仅校验来源合法性，需配合网络隔离与定期轮换等纵深防御措施。
Keepalived 的 auth_pass 不是加密密钥，而是 VRRP 报文的校验凭证，配置不当会直接导致主备失联、VIP 不漂移，但又不会报错退出——这是最危险的“静默失败”。安全的核心不在“多复杂”，而在“严一致”和“防暴露”。
密码必须短而准，且全节点完全一致
auth_pass 最多只取前 8 个字符，超长会被截断；大小写敏感；不能含空格或特殊符号（如 $、! 在 shell 或配置解析中易出错）。生产环境建议用 6–8 位组合：大小写字母 + 数字，例如 Ngx@2026 或 KpL9mQ2x。
- 主、备节点的
auth_pass字符串必须逐字相同（包括末尾换行、缩进空格都不应存在） - 同一
vrrp_instance下的virtual_router_id必须相同，否则认证前就已判定为“非同组”，认证块本身无效 - 严禁使用
1111、pass123、keepalived等默认/可预测口令
认证只是第一道门，不是通信加密
PASS 认证仅校验报文来源合法性，不加密内容。VRRP 组播报文仍以明文在二层网络中传输，攻击者抓包即可看到 auth_pass 原值（虽然只用于哈希比对，但明文暴露等于放弃所有防护前提）。
- 务必限制 VRRP 流量范围：在交换机 ACL 或主机防火墙（如
iptables -A INPUT -d 224.0.0.18 -j ACCEPT）只放行集群节点间通信 - 禁用管理网口参与 VRRP：
interface必须指定专用心跳网卡（如ens33），而非eth0这类通用接口 - 避免跨网段部署 VRRP 实例——它本就是链路层协议，跨路由需额外配置，且大幅增加暴露面
定期轮换与同步更新机制
密码不是设一次就一劳永逸。当人员变动、系统重装或安全审计要求时，必须统一更新所有节点，且确保零窗口期失效。
- 更新前先停掉备用节点 Keepalived，再改主节点配置并 reload，确认 VIP 稳定后再同步更新备节点
- 推荐将
auth_pass抽离为外部变量文件（如/etc/keepalived/auth.conf），通过 include 引入，便于批量替换 - 更新后立即验证：
tcpdump -i ens33 vrrp -nn应能双向捕获报文；journalctl -u keepalived -n 30不出现ignoring received advert... wrong auth日志
别依赖它防“内鬼”，要靠它挡“外扰”
KEEPALIVED 的认证机制本质是防未授权设备伪造 VRRP 报文触发脑裂或抢占 VIP，不是防内部运维误操作或恶意节点。真正的纵深防御需要配合：
- 操作系统层面：关闭非必要端口，限制 root 登录，启用 sudo 日志审计
- 网络层面：心跳链路物理隔离或 VLAN 划分，禁用 STP 防环以外的二层协议
- 应用层面：Nginx 自身健康检查 + Keepalived track_script 联动，避免 VIP 漂在 Nginx 已宕却未感知的节点上
