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>+ 定期探测） - 切换过程有完整日志（含时间戳、角色变更、脚本执行结果）
- 故障注入测试通过（如
killall keepalived模拟主宕机，验证秒级接管） - 网络隔离与认证到位（多播范围可控、密码不为空、无明文暴露）
盲目开启 vrrp_strict，只会让系统更脆弱、更难调试、更不符合 SLA 要求。
