Keepalived e VRRP no Linux: gateway redundante, passo a passo

Se o servidor Linux que faz o papel de gateway ou firewall da rede cair, tudo atrás dele perde saída para a internet até alguém trocar a rota na mão ou subir a máquina de novo. O VRRP (Virtual Router Redundancy Protocol, RFC 3768/5798) resolve isso sem depender de intervenção humana: dois servidores dividem um único IP virtual e, se o que está ativo falhar, o outro assume em menos de 3 segundos com a configuração padrão — sem trocar DHCP, sem mexer em rota estática, sem o cliente perceber.

Por que VRRP em vez de só monitorar e trocar a rota na mão

Monitoramento com alerta (Zabbix, Grafana) avisa que o gateway caiu, mas alguém ainda precisa entrar no switch ou nos hosts e apontar a rota para o servidor reserva. Isso leva minutos, às vezes com o time dormindo. VRRP elimina esse intervalo porque os clientes da rede nunca apontam para o IP real de nenhum dos dois servidores — apontam para o IP virtual, que “pertence” a quem estiver com a prioridade mais alta e vivo no momento. Trocar o dono do IP é um processo de dois servidores conversando via multicast a cada segundo, não um humano correndo para o teclado.

É o mesmo mecanismo por trás do HSRP da Cisco (protocolo proprietário equivalente) e do que appliances comerciais de firewall chamam de “cluster ativo-passivo” — só que de graça, em qualquer distribuição Linux.

Pré-requisitos

Dois servidores Ubuntu ou Debian na mesma VLAN/segmento L2 (VRRP depende de multicast ou unicast local, não atravessa roteamento L3 sem túnel), acesso root, e um IP livre no mesmo /24 dos dois para servir de IP virtual. Se os servidores fazem NAT ou roteamento de verdade — não só o failover do endereço — habilite o encaminhamento de pacotes nos dois:

echo 'net.ipv4.ip_forward=1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

1. Instalar o Keepalived nos dois nós

O comando é o mesmo nos dois servidores — a diferença vem só na configuração:

sudo apt update
sudo apt install -y keepalived

2. Configurar o nó MASTER

Edite /etc/keepalived/keepalived.conf no servidor que deve ficar ativo por padrão. Troque eth0 pela interface real e 192.168.1.1 pelo IP virtual que a rede vai usar como gateway:

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass trocar-esta-senha
    }
    virtual_ipaddress {
        192.168.1.1/24 dev eth0
    }
}

O virtual_router_id precisa ser idêntico nos dois nós e único na VLAN — se outro cluster VRRP na mesma rede usar o mesmo número, os dois grupos vão brigar pelo mesmo IP virtual sem avisar ninguém. A priority mais alta é quem vira MASTER quando os dois estão saudáveis.

3. Configurar o nó BACKUP

No segundo servidor, mesmo arquivo, só troca state e priority:

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass trocar-esta-senha
    }
    virtual_ipaddress {
        192.168.1.1/24 dev eth0
    }
}

A auth_pass do VRRPv2 trafega em texto claro — serve para o protocolo ignorar um vizinho mal configurado na mesma VLAN, não para segurança de verdade. Quem protege o cluster é ACL de switch e segmentação de VLAN, não essa senha.

4. Fazer o failover reagir à internet cair, não só ao processo morrer

Por padrão o Keepalived só verifica se o processo dele mesmo está de pé. Se o servidor MASTER perder o link com o provedor mas o Keepalived continuar rodando, o IP virtual não migra — e a rede fica sem saída mesmo com o “gateway” respondendo. É o buraco mais comum de quem configura VRRP e nunca testa de verdade.

A correção é um vrrp_script que testa conectividade real e derruba a prioridade se falhar. Crie o script nos dois nós:

sudo tee /etc/keepalived/check_wan.sh >/dev/null <<'EOF'
#!/bin/bash
ping -c 1 -W 1 8.8.8.8 >/dev/null 2>&1
EOF
sudo chmod +x /etc/keepalived/check_wan.sh

E referencie no keepalived.conf dos dois nós, dentro e fora do bloco vrrp_instance:

vrrp_script chk_wan {
    script "/etc/keepalived/check_wan.sh"
    interval 2
    weight -30
    fall 2
    rise 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass trocar-esta-senha
    }
    virtual_ipaddress {
        192.168.1.1/24 dev eth0
    }
    track_script {
        chk_wan
    }
}

weight -30 tira 30 pontos da prioridade quando o script falha duas vezes seguidas (fall 2). Com MASTER em 150 e BACKUP em 100, uma queda de WAN no MASTER derruba a prioridade efetiva para 120 — ainda acima do BACKUP fixo em 100. Ajuste o peso para que a perda de conectividade sempre resulte em prioridade menor que a do outro nó; é aritmética simples, mas é o passo que a maioria dos tutoriais pula.

5. Subir e testar o failover de verdade

sudo systemctl enable --now keepalived
sudo systemctl restart keepalived

Confirme que o IP virtual só aparece no nó MASTER:

ip addr show eth0 | grep 192.168.1.1

Teste de verdade, não apenas leia a configuração: derrube o Keepalived do MASTER e observe o BACKUP assumir a partir de outro terminal, com ping contínuo contra o IP virtual rodando desde um terceiro host:

sudo systemctl stop keepalived   # no MASTER
sudo journalctl -u keepalived -f # no BACKUP, observe a transição para MASTER

Com advert_int 1 (o padrão), a perda de 3 anúncios consecutivos dispara o failover — na prática, sub-3 segundos de indisponibilidade. Depois do teste, suba o Keepalived no primeiro nó de novo; como a prioridade dele é maior, ele reassume o papel de MASTER (comportamento chamado de preemption, ligado por padrão).

Perguntas frequentes

VRRP funciona em VMs na AWS, GCP ou Azure?
Não direto. Essas nuvens bloqueiam multicast e ARP gratuito entre instâncias, que é como o VRRP normalmente anuncia a troca de dono do IP. Dá para usar unicast_peer no lugar de multicast, mas migrar o IP virtual entre interfaces de rede virtuais ainda exige um script de notify que chama a API do provedor para mover o Elastic IP ou a rota da VPC — nessas plataformas, o mecanismo nativo de failover do provedor costuma ser mais simples que replicar VRRP.

Posso ter mais de dois servidores no mesmo grupo VRRP?
Sim. Todos entram com state BACKUP e prioridades diferentes, exceto o que for MASTER inicial; quem tiver a segunda maior prioridade assume se o MASTER cair, e assim por diante.

O que acontece se dois grupos VRRP na mesma VLAN usarem o mesmo virtual_router_id?
Os servidores dos dois grupos passam a interpretar os anúncios um do outro como parte do mesmo cluster, disputam o mesmo IP virtual e alternam de estado sem padrão previsível. Mantenha uma lista dos IDs em uso por VLAN.

Multicast ou unicast, qual usar?
Multicast (endereço 224.0.0.18) é o padrão e funciona bem na maioria dos switches. Troque para unicast_src_ip e unicast_peer quando o switch tiver IGMP snooping mal configurado derrubando os anúncios, ou em ambientes de nuvem que não repassam multicast.

O failover interrompe conexões TCP em andamento?
Sim, as sessões TCP que passavam pelo nó que caiu são perdidas — VRRP move o endereço, não o estado da conexão. Para NAT e firewall com estado, isso significa reconexão do cliente, não continuidade de sessão. Sincronização de estado de conexão exige um mecanismo à parte, como conntrackd.

Conclusão

Com dois servidores Ubuntu, um IP livre na VLAN e o vrrp_script testando conectividade real — não só se o processo está de pé — dá para montar um gateway redundante em menos de meia hora. O ponto que decide se o cluster funciona em produção não é a sintaxe do vrrp_instance, é testar o failover derrubando o serviço de propósito antes de confiar nele: é a única forma de saber se a prioridade, o peso do script e o tempo de convergência estão calibrados para o SLA que a rede precisa.