vrrp_strict不是安全加固手段，启用会破坏高可用性并引发合规风险；它仅强制rfc规范校验，导致单播模式、vip与网卡不匹配等合理配置被拒，应禁用并改用防火墙隔离、认证加固、状态监控等真正有效措施。
vrrp_strict 不是安全加固手段，启用它反而会破坏高可用性，带来合规风险。它只是 VRRP 协议的严格校验开关，强制要求配置完全符合 RFC 规范，而生产环境中的常见合理配置恰恰会被它拒绝。
启用 vrrp_strict 会触发哪些典型问题
该参数一旦开启，Keepalived 会拒绝以下实际常用且合法的配置：
- 使用单播模式（unicast_peer）——云环境、VPC 场景下推荐方式
- 未将 virtual_ipaddress 绑定到 interface 所指的物理网卡（如 VIP 在 bond0，但 interface 写的是 eth0）
- VRRPv2 实例中配置 IPv6 地址
- 缺少非核心字段（如旧版本会校验 smtp_server 或 notification_email）
- 没有定义任何 virtual_ipaddress 的实例（某些健康检查场景需先启动服务再动态绑定 VIP）
它不解决真正的安全合规需求
vrrp_strict 完全不提供加密、认证、防篡改、访问控制或审计能力。等保、金融行业对“高可用容错”和“故障自愈”的合规要求，靠它无法满足。相反，因它导致的 VIP 不可达、切换失败、服务中断等问题，会直接违反 SLA，构成合规短板。
生产环境中应禁用并采用有效替代措施
正确做法是注释或删除配置中的 vrrp_strict 行，并叠加以下真正起效的安全与合规手段：
- 网络层隔离：用防火墙限制 VRRP 流量（协议号 112，组播地址 224.0.0.18），只允许可信节点互通
- 认证加固：必须启用 authentication { auth_type PASS; auth_pass xxx; }（注意仅前 8 位有效）
- 状态可观测：配置 notify_master/notify_backup 脚本，记录每次切换时间、原因、VIP 变更到独立日志
- 健康检查闭环：通过 vrrp_script 检查后端服务（如 curl -f http://127.0.0.1/health），失败时自动降级 priority
验证是否已正确规避 strict 风险
检查运行态表现比看配置更重要：
- 启动后执行 ip -br a show，确认 VIP 正常出现在 MASTER 节点
- 在两端执行 journalctl -u keepalived -n 50 | grep "ignoring"，不应出现 “due to strict mode” 类报错
- 手动 stop 主节点 keepalived，VIP 应在 1 秒内漂移到备节点；恢复后，VIP 应立即切回（preemption 默认开启）
