ACS atrás de CGNAT: funciona?

Por que o CGNAT atrapalha só metade do TR-069?

A conversa TR-069 tem dois sentidos, e o CGNAT afeta só um deles.

• Do roteador para o ACS: o equipamento abre uma conexão HTTP ou HTTPS de saída e envia o Inform. Para o CGNAT isso é igual a qualquer acesso a um site. Passa sem problema, e dentro dessa sessão o ACS lê e muda o que quiser.
• Do ACS para o roteador: para pedir uma ação imediata, o ACS faz um Connection Request, uma chamada HTTP ao endereço do equipamento (por padrão na porta 7547). Atrás de CGNAT o roteador tem um endereço da faixa compartilhada 100.64.0.0/10 ou privado, que não é alcançável de fora. A chamada não chega.

É a dúvida que mais aparece. Um cliente nos perguntou, sobre o próprio link: "o ip tem alguma limitação de portas? cgnat?". No TR-069 a resposta é: limita o caminho de volta, não o de ida.

O que é o Inform periódico e qual intervalo usar?

Além de ligar quando reinicia ou quando algo muda, o roteador liga para o ACS de tempos em tempos. Os parâmetros que controlam isso ficam em ManagementServer:

Device.ManagementServer.PeriodicInformEnable    = true
Device.ManagementServer.PeriodicInformInterval  = 300     (segundos)
Device.ManagementServer.PeriodicInformTime      = (horário de referência)

O intervalo é um meio-termo entre agilidade e carga, e a conta é direta. Com 5.000 equipamentos e intervalo de 300 segundos, o ACS recebe em média 5.000 ÷ 300 ≈ 17 sessões por segundo. Com 3.600 segundos, cerca de 1,4 por segundo. Em troca, a tarefa que não teve Connection Request espera até um intervalo inteiro para ser aplicada: 5 minutos no primeiro caso, 1 hora no segundo.

Um cuidado prático: depois de uma queda de energia em um bairro, todos os equipamentos voltam juntos e ligam juntos. Espalhar o PeriodicInformTime evita que o contato periódico também fique sincronizado e vire uma onda a cada intervalo.

Como o STUN resolve o Connection Request?

O Anexo G do TR-069 (que veio do antigo TR-111) descreve como fazer o Connection Request atravessar NAT. O mecanismo:

1. O roteador envia pedidos STUN (UDP) a um servidor STUN. A resposta diz qual endereço e porta públicos o NAT atribuiu a ele.
2. O roteador repete esses pedidos em intervalos curtos, o que mantém o mapeamento do NAT aberto.
3. O roteador informa ao ACS esse endereço público no parâmetro UDPConnectionRequestAddress.
4. Quando precisa de ação imediata, o ACS manda uma mensagem UDP para esse endereço. O roteador recebe e abre uma sessão normal com o ACS, como num Connection Request comum.

Device.ManagementServer.STUNEnable                  = true
Device.ManagementServer.STUNServerAddress           = stun.seu-acs.exemplo
Device.ManagementServer.STUNServerPort              = 3478
Device.ManagementServer.STUNMinimumKeepAlivePeriod  = 30
Device.ManagementServer.NATDetected                 (somente leitura)
Device.ManagementServer.UDPConnectionRequestAddress (somente leitura)

Qual é a ressalva honesta sobre STUN e CGNAT?

Ação na hora atrás de CGNAT depende do firmware. Se o modelo não implementa o Anexo G, não há STUN, e a ação espera o próximo Inform periódico. Mesmo quando implementa, três coisas podem atrapalhar:

• Tempo de expiração do NAT. Se o CGNAT esquece mapeamentos UDP antes do próximo pedido STUN do roteador, o caminho fecha. O intervalo de manutenção (STUNMinimumKeepAlivePeriod) precisa ser menor que esse tempo.
• Filtragem por endereço de origem. Alguns NATs só deixam entrar UDP vindo do mesmo endereço para onde o roteador enviou. Por isso convém que o servidor STUN e o emissor do Connection Request usem o mesmo endereço.
• Firmware com bug. Acontece. A homologação de cada modelo em bancada existe para descobrir antes da virada, e não com o assinante na linha.

Existe ainda uma alternativa no próprio padrão, o Connection Request por XMPP (Anexo K), que também depende de suporte do firmware. Em todos os casos, a regra para o atendimento é a mesma: se o equipamento não aceita ação imediata, a tarefa fica na fila e o atendente informa o prazo do próximo contato.

E se o TR-069 estiver numa VLAN de gerência?

Muitos provedores separam a gerência do tráfego do assinante: a ONU tem uma WAN só para TR-069, numa VLAN com endereçamento privado, fora do CGNAT. Nesse desenho o ACS alcança o equipamento diretamente, desde que exista rota entre essa VLAN e o servidor do ACS, por roteamento interno ou por VPN quando o ACS está fora da rede. É uma decisão de arquitetura da sua rede, com vantagens (Connection Request sem STUN) e custos (rota ou túnel para manter). Os dois desenhos funcionam.

Como testar se o seu equipamento aceita ação na hora?

1. Leia ManagementServer.STUNEnable. Se o parâmetro nem existe no modelo, o firmware provavelmente não implementa o Anexo G.
2. Habilite o STUN apontando para o servidor do ACS e, depois de alguns minutos, leia NATDetected e UDPConnectionRequestAddress.
3. Peça um reboot pelo ACS e cronometre. Se reiniciar em segundos, o caminho de volta funciona. Se esperar o intervalo periódico, não.
4. Repita depois de algumas horas sem tráfego, para ver se o mapeamento do NAT continua de pé.

Como o NuvoACS trata o CGNAT?

O NuvoACS funciona atrás de CGNAT porque usa o caminho de ida do TR-069, que o CGNAT não bloqueia. A ação na hora depende de o firmware suportar STUN; quando não suporta, a ação é aplicada no próximo contato do equipamento, em minutos. Na implantação, que está grátis no lançamento, homologamos os seus modelos em bancada e mostramos qual comportamento cada um tem antes da virada. Para entender o que muda na rotina do suporte, veja como trocar a senha do Wi-Fi sem visita técnica; para o básico do protocolo, o que é ACS TR-069.