vrrp_strict不是安全加固项，而是vrrp协议严格校验开关，启用后因拒绝常见合法配置而破坏高可用性，导致vip不可达、切换失败等问题，应禁用并采用防火墙隔离、认证加密、健康检查等替代措施保障合规。

vrrp_strict 并不能增强双机热备的“安全合规”，相反，它在多数生产环境中会破坏高可用性，导致 VIP 不可达、服务中断、切换失败等问题。它不是安全加固项，而是 VRRP 协议的严格校验开关，启用后反而容易引发合规风险（如 SLA 不达标、故障恢复超时）。

下面从实际配置和运维角度讲清楚它的作用、典型问题及正确应对方式：

vrrp_strict 的真实作用

该指令强制 Keepalived 完全遵循 RFC 3768（VRRPv2）或 RFC 5798（VRRPv3）协议规范，启用后将拒绝以下合法且常见配置：

• 配置了任何 virtual_ipaddress（即没有 VIP 的实例无法启动）
• 使用单播模式（unicast_peer）
• 在 VRRPv2 中配置 IPv6 地址
• 未绑定到物理接口的 VIP（如 VIP 在 bond0 上，但 interface 写的是 eth0）
• 缺少 smtp_server 或 notification_email 等非核心字段（部分旧版本会校验）

⚠️ 注意：它不提供加密、认证强化、防篡改或审计日志等真正意义上的安全能力，也不满足等保、金融行业对“高可用容错”或“故障自愈”的合规要求。

生产中启用 vrrp_strict 常见故障

• VIP 配置正确但 ip addr show 看不到，ping VIP 超时
• 主备切换后 VIP 不漂移，systemctl status keepalived 显示 active but no VIP
• 日志报错：VRRP_Instance(VI_1) ignoring received advertisement... due to strict mode
• 启动失败，提示 invalid configuration: no virtual_ipaddress defined（即使已定义）

正确做法：禁用 strict，靠其他机制保障合规

# ✅ 推荐配置（注释掉或删除这一行）
# vrrp_strict

# ✅ 替代性合规手段
global_defs {
    router_id lb01
    vrrp_skip_check_adv_addr   # 提升性能，跳过重复报文地址校验
    vrrp_garp_interval 0.2     # 加速 ARP 刷新，缩短故障恢复时间
    vrrp_gna_interval 0.2      # 加速邻居通告更新
}

• 网络层防护：用防火墙限制 VRRP 多播包（目标 224.0.0.18，协议 112），只允许可信节点互通
• 认证加固：必须启用 authentication { auth_type PASS; auth_pass 12345678; }（注意仅前8位有效）
• 状态可观测：配置 notify_master /etc/keepalived/notify.sh 脚本，记录切换时间、原因、IP 变更到独立日志
• 健康检查闭环：搭配 vrrp_script 检查后端服务（如 curl -f http://127.0.0.1/health），失败时自动降级 priority

总结

vrrp_strict 是协议一致性开关，不是安全开关。把它当作“合规必需项”是典型误解。真正的高可用合规，依赖的是：

• VIP 漂移可验证（ip a | grep <vip></vip> + 定期探测）
• 切换过程有完整日志（含时间戳、角色变更、脚本执行结果）
• 故障注入测试通过（如 killall keepalived 模拟主宕机，验证秒级接管）
• 网络隔离与认证到位（多播范围可控、密码不为空、无明文暴露）

盲目开启 vrrp_strict，只会让系统更脆弱、更难调试、更不符合 SLA 要求。