Como deixar CGNAT redundante: passo a passo para provedores
Como deixar CGNAT redundante: monte dois equipamentos de NAT, cada um com o seu próprio pool de IPs públicos, ligados por roteamento dinâmico que desvia os assinantes sozinho quando um para. Os dois mandam o registro para o mesmo servidor, com relógio sincronizado, para o ofício continuar achando o assinante depois da troca.
Resumo
- Redundância de CGNAT é roteamento, faixas de IP e registro pensados juntos, não só um segundo aparelho.
- Cada equipamento precisa de um pool público próprio, para o IP do ofício dizer qual deles fez a tradução.
- O reserva tem que aguentar a base inteira no pico, senão a troca vira uma segunda queda.
- O registro dos dois vai para o mesmo servidor, com o relógio sincronizado por NTP e o nome de cada equipamento.
Como deixar CGNAT redundante: o que decidir antes
Antes de configurar, decida o arranjo, confira a capacidade do reserva e separe faixas e pools entre os dois equipamentos. Essas três decisões definem se a troca funciona e se o registro continua valendo.
O CGNAT é o único ponto por onde passa todo o IPv4 dos assinantes. Quando ele para, a borda e o concentrador seguem no ar, as sessões PPPoE continuam de pé e mesmo assim ninguém navega, o que confunde o suporte nos primeiros minutos.
A alta disponibilidade de CGNAT resolve isso com um segundo caminho pronto. O passo a passo abaixo é a referência que usamos para pensar o projeto; cada plataforma tem a sua forma de executar cada etapa.
| Peça | Com um equipamento | Com dois equipamentos |
|---|---|---|
| Saída para a borda | Rota estática fixa | Roteamento dinâmico que some quando o equipamento cai |
| Pool de IPs públicos | Um bloco só | Um bloco por equipamento, sem sobreposição |
| Capacidade | Dimensionada para a base | Cada um aguenta a base inteira no pico |
| Registro | Disco ou servidor do próprio NAT | Servidor único, com o nome de cada equipamento |
| Atualização | Sempre adiada | Um equipamento por vez, com o outro segurando a base |
Por que ligar um segundo equipamento não basta
Um segundo CGNAT desligado na prateleira, ou ligado com a mesma configuração do primeiro, não é redundância. Sem roteamento que mude sozinho, alguém precisa acordar e trocar cabo ou rota, e a queda dura o tempo dessa pessoa chegar.
Com a mesma configuração, o problema é pior: dois equipamentos traduzindo para o mesmo IP público geram conflito de portas e um registro em que a mesma porta aparece duas vezes no mesmo minuto.
CGNAT com dois equipamentos, como dividir faixas e pools?
Num CGNAT com dois equipamentos, cada um anuncia à borda apenas o seu pool público, e o concentrador aprende por roteamento qual deles usar. Quando um cai, as rotas dele somem e o tráfego vai sozinho para o outro.
Na prática, o pool público é dividido ao meio. Com um bloco 203.0.113.0/24, o CGNAT-A traduz para 203.0.113.0/25 e o CGNAT-B para 203.0.113.128/25; a faixa interna 100.64.0.0/10 continua a mesma, porque o assinante não muda de endereço quando troca de equipamento.
Normal
A traduz, B espera ou divide
O concentrador prefere o CGNAT-A pelo custo da rota, e a borda conhece os dois pools.
Falha
O CGNAT-A para
O vizinho de roteamento deixa de responder e as rotas anunciadas pelo A saem da tabela.
Troca
B assume a base
O concentrador passa a enviar tudo ao B, que traduz para o pool 203.0.113.128/25.
Volta
A retorna com atraso
O A só recebe tráfego de novo depois de estável, para não causar uma segunda troca.
As conexões abertas no A se perdem na troca, a menos que a plataforma sincronize sessões. Para o assinante, o efeito é a página que recarrega e o jogo que reconecta.
Ativo e reserva ou ativo e ativo?
Em ativo e reserva, um equipamento faz todo o trabalho e o outro só assume na falha, o que simplifica o registro e o diagnóstico. Em ativo e ativo, cada um atende uma parte da base, e a falha afeta só metade dos assinantes.
Um jeito simples de fazer ativo e ativo é dividir por concentrador: o concentrador 1 prefere o CGNAT-A e o concentrador 2 prefere o CGNAT-B, só invertendo o custo das rotas. A regra de capacidade não muda, porque na falha o sobrevivente recebe tudo.
Passo a passo da configuração de referência
A configuração segue seis passos, da capacidade ao teste de falha, sem desligar o equipamento que já está em produção. O segundo CGNAT entra ao lado do primeiro e só recebe assinantes depois de conferido.
- Capacidade: confira se o novo equipamento aguenta o pico da base inteira em sessões, portas e CPU.
- Pool próprio: reserve para ele metade do bloco público, ou um bloco novo, sem sobrepor o do primeiro.
- Roteamento: ligue OSPF ou BGP entre os dois CGNATs, a borda e os concentradores, no lugar das rotas estáticas.
- Anúncios: cada CGNAT anuncia o seu pool para a borda e a rota padrão para os concentradores, com custos diferentes.
- Registro: os dois enviam o registro ao mesmo servidor, com nome próprio e relógio sincronizado.
- Teste: numa janela, desligue o principal, meça o tempo de troca e faça uma consulta de ofício simulada.
/system identity set name=cgnat-a
/ip route
add dst-address=203.0.113.0/25 blackhole comment="pool A anunciado a borda"
/routing ospf instance
add name=ospf-nat router-id=198.51.100.1 redistribute=static \
originate-default=if-installed
/routing ospf area
add name=area0 instance=ospf-nat area-id=0.0.0.0
/routing ospf interface-template
add area=area0 interfaces=para-borda cost=10
add area=area0 interfaces=para-concentrador cost=10
/ip firewall nat
add chain=srcnat src-address=100.64.0.0/10 out-interface-list=WAN \
action=src-nat to-addresses=203.0.113.0/25 comment="trocar pelas regras de portas"
# No CGNAT-B: name=cgnat-b, pool 203.0.113.128/25,
# router-id=198.51.100.2 e cost=20 em para-concentradorA rota blackhole do pool existe só para ser anunciada; se o CGNAT-A cair, o anúncio some junto e a borda para de mandar a volta para ele. A regra de NAT do exemplo é simplificada, e na rede real entram as regras de portas por bloco ou determinísticas.
Quer o segundo CGNAT montado e testado?
Na alta disponibilidade de CGNAT, um Especialista confere a capacidade do reserva, liga a troca por roteamento e desliga o principal numa janela para medir a troca.
Na prática: o teste de falha em janela
O teste é a única prova de que a redundância existe. Faça numa madrugada combinada, com alguém acompanhando o monitoramento e um assinante de teste navegando.
- Antes: anote sessões, CPU e portas em uso nos dois equipamentos.
- Durante: desligue a interface do principal e cronometre até o assinante de teste voltar a navegar.
- Conferência: veja se a borda deixou de anunciar o pool do principal e se o reserva aguentou a carga.
- Volta: religue o principal e confirme que ele só reassume depois do atraso configurado.
Quem já usa VRRP na borda vai reconhecer a lógica de prioridade e atraso, explicada no guia de configuração de VRRP; no CGNAT, a troca por roteamento costuma ser mais limpa, porque o pool acompanha o equipamento.
Como manter logs com CGNAT redundante
Para manter logs com CGNAT redundante, cada equipamento usa um pool público próprio, manda o registro ao mesmo servidor e tem o relógio sincronizado. Assim o IP do ofício aponta o equipamento, e o horário aponta a linha certa.
Com pools separados, a primeira pergunta da consulta se responde sozinha: um ofício com IP de 203.0.113.0/25 vai para o registro do CGNAT-A, e um com IP de 203.0.113.128/25 vai para o do B. Se os dois usassem o mesmo pool, seria preciso olhar os dois registros e torcer para não haver a mesma porta nos dois.
| Forma de dividir portas | O que guardar | Cuidado na troca |
|---|---|---|
| Por blocos | Cada bloco entregue, com equipamento, IP, portas e horário | O reserva gera blocos novos; os dois registros entram na busca |
| Determinística | A fórmula de cada equipamento e o registro das sessões | Documentar a fórmula do reserva para a base inteira |
| Dinâmica | Cada conexão traduzida | Volume dobra no reserva durante a falha |
| Com sessões sincronizadas | Registro de quem criou a conexão | Conexão migrada mantém IP e porta do equipamento original |
O caso que mais engana é o NAT determinístico. O reserva precisa da sua própria fórmula para a base inteira, e essa fórmula precisa estar guardada com a do principal, senão a consulta do período da falha não fecha. O guia de NAT determinístico mostra a conta de cada fórmula.
Relógio e servidor único
Dois equipamentos com relógios diferentes por alguns segundos já bastam para a consulta apontar o assinante errado na hora da troca. Os dois devem usar as mesmas fontes de NTP, e o servidor de registro também.
O registro só no disco do próprio CGNAT se perde junto com ele. A guarda de logs de CGNAT recebe as linhas dos dois equipamentos num lugar só, e a regra de guarda dos registros de conexão segue o Marco Civil da Internet [CONFIRMAR na norma].
Erros comuns ao deixar o CGNAT redundante
Os erros mais comuns só aparecem no dia em que o principal cai, quando já não dá para corrigir com calma. Quase todos vêm de pular o teste de falha.
Evite
- Usar o mesmo pool público nos dois equipamentos. A consulta de ofício fica ambígua e as portas colidem.
- Comprar um reserva menor que o principal. Ele assume e trava no primeiro pico.
- Manter rota estática para o CGNAT. A rota continua apontando para o equipamento parado.
- Deixar o principal reassumir na hora em que volta. Um equipamento instável causa uma troca atrás da outra.
- Guardar o registro só no disco de cada equipamento. Quando um morre, o registro morre junto.
- Nunca testar a troca. A primeira falha real vira o teste, com a base inteira assistindo.
A redundância do CGNAT também depende do que está ao redor. Se o concentrador ou a borda forem únicos, a falha só muda de lugar; a alta disponibilidade de concentrador e a da borda fecham esse caminho.
Quando dar a redundância do CGNAT por pronta?
A redundância está pronta quando a troca foi testada com a base em produção e uma consulta de ofício do período da falha encontrou o assinante. Antes disso, ela é só um segundo equipamento ligado.
Marque o que já foi conferido no seu par de CGNAT
- Cada equipamento tem pool público próprio, sem sobreposição.
- O reserva aguentou a base inteira no pico durante o teste.
- As rotas do equipamento desligado sumiram da borda e do concentrador.
- O tempo de troca foi medido e anotado.
- Uma consulta simulada do período da falha achou o assinante certo.
- Existe alarme quando um dos dois equipamentos para.
Seis marcas indicam um par pronto para produção. Qualquer item vazio é o ponto onde a próxima falha vai aparecer, e vale corrigir antes da próxima atualização.
A Táquion Tech monta CGNAT redundante de forma remota, com faixas separadas, troca por roteamento, registro dos dois lados no mesmo servidor e teste de falha numa janela combinada. Quando o problema do momento é outro, como portas, câmeras ou bloqueio, o guia sobre CGNAT: como resolver separa cada caso.
Perguntas frequentes
CGNAT com dois equipamentos precisa sincronizar sessões?
Não precisa, mas sincronizar evita que as conexões abertas caiam na troca. Sem sincronização, o assinante perde as conexões do momento e reconecta em seguida, o que é aceitável para a maior parte da base.
Como manter logs com CGNAT redundante sem confundir equipamentos?
Dê um pool público próprio a cada equipamento e inclua o nome dele em cada linha enviada ao servidor. Assim o IP do pedido já indica qual registro consultar.
Quanto tempo o assinante fica sem navegar na troca?
Depende do tempo que o roteamento leva para perceber a falha, e com temporizadores padrão de OSPF isso pode passar de meio minuto [CONFIRMAR na versão do equipamento]. Com BFD ligado entre os vizinhos, a detecção cai para frações de segundo.
Dá para usar VRRP para deixar o CGNAT redundante?
Dá, quando os dois equipamentos ficam no mesmo segmento e o concentrador aponta para um gateway virtual. A troca por roteamento costuma ser preferida porque leva junto o anúncio do pool e funciona entre POPs.
O tráfego IPv6 também passa pelo par de CGNAT?
Não, o IPv6 sai sem tradução e depende da redundância da borda e do concentrador. Por isso, quanto mais tráfego em IPv6, menor o estrago de uma falha no CGNAT.
Responsável técnico da Táquion Tech · Registro profissional [PREENCHER]
Mais de 15 anos em operações de rede, com gestão de infraestruturas de TI, administração de data centers e condução de equipes em migrações de TI e telecomunicações, com foco em alta disponibilidade e segurança.
A Táquion Tech é uma empresa de engenharia de redes de Balneário Camboriú (SC) que projeta, opera e dá suporte a redes de provedores de internet e de empresas.
Fontes
- RFC 6888, Common Requirements for Carrier-Grade NATs (CGNs): requisitos de comportamento e de registro num CGNAT
- RFC 7422, mapeamento determinístico de endereços em CGNAT: fórmula que liga a porta pública ao endereço interno, usada para planejar o registro do reserva
- OSPF, documentação do RouterOS 7 (MikroTik): parâmetros de instância, área, modelo de interface e geração da rota padrão
