Por que o Firewall Checker Não Mente
O 3CX tem um verificador de firewall automatizado embutido que valida a configuração de seu firewall em termos de “encaminhamento de porta” e também de “preservação de porta”.
Encaminhamento de Portas
O 3CX verificará se o “Full Cone NAT” está configurado corretamente no dispositivo de firewall/gateway. O Full Cone NAT permite que qualquer entidade externa se conecte ao 3CX sem a necessidade de o firewall confirmar primeiro que o pacote real se originou do 3CX antes de permitir a conexão. Isso é muito importante principalmente para os Provedores de VoIP, pois o servidor SIP não é o mesmo servidor (Endereço IP de origem) que entregará o áudio final ao seu sistema. Em alguns casos, a implementação do firewall definirá o tráfego de entrada “não permitido” em uma lista de negação, o que impedirá uma conexão com o destino, mesmo que o 3CX comece a enviar dados (áudio) para o destino.
Preservação de Porta
A preservação da porta é outro fator importante que é verificado pelo verificador de firewall. Ele detecta se o firewall altera a porta durante a tradução do IP da LAN para o IP da WAN. Tecnicamente falando, isso não deveria importar, mas depende da implementação do provedor se ele responde à porta de origem do transporte do 3CX vista no cabeçalho UDP em vez do que é definido pela RFC. A RFC define que um servidor SIP DEVE responder ao IP e à porta de “contato” definidos, que estão no conteúdo da mensagem SIP. Para eliminar quaisquer “dúvidas”, o verificador de firewall também valida esse mapeamento. É necessário que, se uma mensagem SIP for gerada localmente pelo 3CX a partir da porta de origem 5060 (Porta SIP padrão) e depois traduzida para o endereço IP público (IP da WAN), a porta, nesse caso 5060, permaneça inalterada.
Para fazer isso, o verificador de firewall executará dois testes independentes com o primeiro Servidor STUN configurado em seu sistema. Por padrão, ele é definido como stun.3cx.com. É altamente recomendável que isso não seja alterado. Em geral, o verificador de firewall é uma forma programática de detectar seu endereço IP público, semelhante ao uso de um site como “what is my IP”, mas é estendido para verificar também a porta.
Examplos
Abaixo está uma verificação de firewall com falha relatada pelo Console de Gerenciamento 3CX e uma captura wireshark correspondente do fluxo. Neste guia, elaboraremos as etapas executadas pelo verificador de firewall e mostraremos os resultados. A captura do wireshark está limitada a mostrar apenas a “porta 3378 ou a porta 3379”, na qual esse teste se baseou. É importante para o verificador de firewall que o firewall do Windows esteja desativado. A instalação do 3CX cria exceções para alguns aplicativos do 3CX, mas não para o verificador de firewall em si!
Teste 1
O 3CX interrompe os serviços para liberar a porta local a fim de vinculá-la ao verificador de firewall. Este documento se concentrará apenas na primeira porta a ser testada (5060), mas o procedimento é o mesmo para todas as outras portas.
A imagem acima mostra as etapas a seguir:
- O servidor 3CX local, com endereço IP 192.168.3.159, envia uma solicitação clássica stun para stun.3cx.com com IP 198.50.247.220.
- Da porta local 5060 UDP.
- Para 3478, que é a porta padrão do servidor stun.
- Declarando que o Servidor STUN NÃO deve alterar seu IP ou a Porta para responder a essa solicitação.
Cada solicitação tem um “ID de Transação” exclusivo para garantir de forma confiável que os dados recebidos pertençam à solicitação inicial. Em casos raros, você pode ver que o servidor envia várias solicitações, mas nunca recebe uma resposta, conforme mostrado abaixo. Isso implica que:
a) O tráfego de saída foi bloqueado pelo firewall ou b) Nenhum retorno foi passado de volta para o servidor. Em ambos os casos, verifique as configurações do firewall!
O servidor Stun então responde com:
- Uma resposta de vinculação para as solicitações
- Em seguida, define que o IP e a Porta públicos de onde a solicitação foi enviada são iguais à porta 5060 e o endereço IP é XX.XX.96.162.
Com base na definição anterior, a preservação da porta está funcionando, pois o servidor stun pode ver o PABX na porta definida. Se você vir qualquer outra porta no campo “Mapped-Address”, a verificação do firewall falhará e a preservação da porta NÃO estará funcionando corretamente.
Teste 2
No teste 2, o servidor enviará uma solicitação para o mesmo servidor stun anterior.
No entanto,
- O Servidor 3CX marca a solicitação como sendo diferente da anterior e define “Change IP and Change Port” como (1). Isso significa que o servidor stun deve enviar sua resposta de volta ao 3CX, porém a partir de um endereço IP e de uma Porta que agora são desconhecidos pelo firewall que espera uma resposta à solicitação.
- Está claro que o servidor enviou a mesma solicitação três vezes sem receber uma resposta do servidor stun. Isso indica que o NAT de cone completo não está funcionando.
Em comparação com o teste 1, em que o servidor 3CX envia ativamente dados para o servidor stun e recebe uma resposta, o teste 2 mostra que os dados retornam de uma fonte com a qual o 3CX nunca conversou (ou seja, o servidor de áudio de um provedor de VoIP) e não foi possível receber nenhuma resposta. Nesse caso, entre em contato com o fabricante do firewall para resolver o problema.
A resposta correta seria receber dados no segundo teste, em que o “Mapped-Address” é exatamente o mesmo que no teste 1 para IP e Porta.
Se quiser ver de onde o tráfego deveria ter vindo, verifique os registros do firewall para ver os endereços IP dos servidores stun da 3CX. Esperava-se que a resposta viesse dos servidores stun do 3CX, mas ela nunca chegou ao NIC do 3CX.
Teste SIP ALG (desde a V15.5 SP1)
Além do teste de NAT existente, o 3CX avalia se o firewall tem o SIP ALG ativado. Em resumo, SIP ALG são funções encontradas em alguns dispositivos de firewall que inspecionam, além da lista de acesso de IP/Portas de origem e destino, o conteúdo dos pacotes. Nesse caso, o SIP. Para o administrador do 3CX, isso pode causar vários problemas e, devido ao fato de as alterações nas mensagens SIP serem feitas por um salto intermediário, os rastreamentos feitos no 3CX não mostrarão essas alterações. No entanto, elas podem causar problemas de incompatibilidade com telefones IP remotos ou provedores de VoIP.
Validação: A 3CX gerará uma mensagem INVITE genérica e a enviará para um serviço on-line hospedado pela 3CX. Com exceção do endereço IP público, todas as outras informações são renderizadas de forma genérica.
O 3CX local gera um valor de hash CRC32 a partir da mensagem enviada e espera, em troca, uma resposta do serviço de nuvem de que o hash terá o mesmo valor.
Se o valor de retorno “X-CSREQ” corresponder ao valor calculado localmente, espera-se que o SIP ALG não tenha adulterado a mensagem ou não esteja presente. Se os valores não corresponderem, o teste mostra que um salto entre o 3CX e o serviço on-line alterou o conteúdo = SIP ALG.
Em uma base de validação, o valor de hash esperado pode ser calculado, uma vez que o wireshark capturou o INVITE de saída para o serviço de detecção de SIP ALG.
Clique com o botão direito do mouse no Invite enviado pelo 3CX, Copy, Bytes, Hex Stream. Abra: https://www.sunshine2k.de/coding/javascript/crc/crc_js.html
E cole o fluxo hexadecimal copiado nos Dados de Entrada do CRC
O Resultado fornecido deve corresponder ao valor retornado.
Última Atualização
Este documento foi atualizado pela última vez em 25 de janeiro de 2019
Copyright © 2025