Proxy não conversa com Server: diagnosticando rota, firewall e porta TCP 10051
Como separar DNS, rota, TCP 10051, modo ativo e configuração do frontend quando um Zabbix Proxy não consegue conversar com o Server.
Quando um Zabbix Proxy aparece offline, “é firewall” costuma ser uma das primeiras frases da conversa.
Às vezes é.
Mas em uma ativação real de novos proxies, apareceram dois problemas diferentes com sintomas parecidos:
- em um proxy, a porta pública do Server respondia, mas o Server rejeitava a conexão com
connection is not allowed; - em outro, a conectividade até o endereço público na TCP 10051 inicialmente não fechava e depois foi ajustada, mas a fonte recuperada não registra uma causa raiz técnica única para essa etapa.
A diferença entre os dois casos é justamente o motivo deste artigo.
“Proxy offline” não é diagnóstico. É só o ponto de partida.
Primeiro: entender o sentido da conexão #
O proxy estava configurado em modo ativo.
Conceitualmente:
| |
Nesse modo, o proxy inicia a comunicação com o Zabbix Server.
Então a pergunta de rede principal é:
| |
Isso é diferente de investigar agente passivo, onde o sentido e a porta podem ser outros.
Antes de abrir firewall aleatoriamente, eu confirmo o modo do proxy e o fluxo que deveria existir.
Validar configuração local antes da rede #
Alguns comandos simples ajudam a evitar horas investigando a camada errada.
| |
Depois:
| |
O objetivo é responder:
| |
Se o Hostname não corresponde ao proxy cadastrado no frontend, o TCP pode estar perfeito e o Server ainda assim não aceitar a sessão como esperado.
DNS precisa resolver para o endereço certo #
No ambiente desse caso, os novos proxies deveriam chegar ao Server pelo endereço público, não por um endereço privado usado em outro segmento.
Isso torna DNS parte do diagnóstico.
| |
ou:
| |
Se o nome resolve para uma rede que o proxy não alcança, o restante da configuração pode estar correto e ainda assim a comunicação nunca chega ao destino.
Testar a porta antes de culpar o Zabbix #
Com o endereço resolvido:
| |
ou, quando necessário:
| |
O resultado divide o problema em dois grupos.
TCP não conecta #
Investigar:
- rota;
- NAT;
- firewall local;
- firewall de borda;
- security group/lista equivalente;
- serviço realmente escutando;
- endereço/IP incorreto.
TCP conecta #
Agora a rede básica até a porta está comprovada.
O foco muda para:
- configuração do proxy;
Hostname;- cadastro no frontend;
- modo ativo/passivo;
- criptografia/TLS;
- permissões/restrições do Server;
- logs do proxy e do Server.
Essa separação evita um erro comum: continuar mexendo em firewall depois que o nc já provou que a sessão TCP chega ao Server.
Caso 1: a porta funcionava, mas o Server dizia connection is not allowed #
Em um dos proxies, o teste de TCP 10051 pelo caminho público funcionava.
Mesmo assim, a comunicação não completava e o log mostrava erro compatível com rejeição pelo Server:
| |
A correção documentada foi no cadastro do proxy no frontend: o campo Proxy address estava preenchido de forma incompatível com o caminho real usado pelo proxy via NAT/endereço público.
Depois de limpar esse campo para o proxy ativo, ele passou a aparecer online.
A validação registrada depois da correção mostrava:
- proxy online;
- versão 7.0.x;
- milhares de itens associados;
- dezenas de hosts sob o proxy.
O ponto importante é que não era uma falha de TCP.
A porta já estava acessível.
Era uma restrição/configuração na camada Zabbix.
Caso 2: o proxy nem chegava à TCP 10051 #
Outro proxy da mesma ativação começou em um estado diferente.
O teste até o endereço público do Server na porta 10051 não conectava.
Nesse momento, ainda não fazia sentido discutir Proxy address como causa principal porque a sessão sequer chegava ao Server.
As camadas candidatas eram:
| |
Depois, o ambiente foi ajustado e o proxy também ficou conectado.
Mas aqui existe uma limitação importante da fonte histórica:
não ficou registrado qual alteração específica fechou a causa desse segundo caso.
Então eu não transformaria “firewall/rota” em RCA pública só porque era a camada provável de investigação.
O que dá para afirmar é:
- inicialmente a TCP 10051 pública não conectava;
- depois houve ajuste;
- o proxy terminou conectado;
- a fonte recuperada não identifica com precisão qual regra/rota/NAT foi a causa definitiva.
Logs ajudam a separar rede de aplicação #
No proxy:
| |
ou o arquivo configurado em LogFile.
Procurar termos como:
| |
Essas mensagens representam estados diferentes.
Por exemplo, em outro ambiente de proxy ativo, linhas recorrentes de:
| |
já eram evidência de que o fluxo Proxy → Server estava funcionando. Os erros restantes estavam na coleta Proxy → Agents, não na comunicação com o Server.
Isso impede um diagnóstico genérico do tipo “o proxy não funciona” quando, na verdade, uma parte da cadeia já está saudável.
A cadeia completa importa #
Um Zabbix Proxy pode estar online no Server e ainda ter problemas para coletar os hosts atrás dele.
São fluxos diferentes:
| |
Por isso eu separo o diagnóstico em duas perguntas:
O proxy consegue falar com o Server? #
Validar DNS, rota, TCP 10051, modo e cadastro.
O proxy consegue falar com os dispositivos que monitora? #
Validar rota interna, TCP/UDP da interface monitorada e o protocolo correspondente.
Misturar as duas coisas gera mudanças em firewall no lado errado.
Checklist que uso para Proxy ativo offline #
| |
O aprendizado dos dois casos #
Dois proxies podem aparecer “offline” por motivos completamente diferentes.
No primeiro, a porta estava aberta e o Server recebia a tentativa — a correção ficou no cadastro do próprio Zabbix.
No segundo, a comunicação nem chegava à TCP 10051 no começo — a investigação pertencia primeiro à rede, e a fonte histórica não permite cravar qual ajuste foi a RCA final.
A ordem de investigação que ficou desse trabalho foi:
| |
Porque “não conecta” pode significar desde pacote que nunca chegou até conexão perfeitamente recebida e rejeitada pela aplicação.
Me chama.
Manda o contexto, os sintomas e o que já foi testado. Bora organizar as evidências antes de sair mexendo.