Um proxy SOCKS pode carregar mensagens mas falha nas chamadas

As mensagens de texto chegam através de um proxy SOCKS, mas uma chamada de voz nunca se liga. O proxy não está necessariamente totalmente avariado. A aplicação pode usar outro transporte para as chamadas.

Um pedido TCP bem-sucedido prova um caminho TCP para essa operação. O SOCKS5 também define a associação UDP, mas o cliente, o serviço SOCKS, as regras de rede e as configurações da aplicação têm todos de suportar a rota UDP pretendida.

Há mais do que um ouvinte TCP

O manual do Dante separa as regras de protocolo e de comandos, incluindo connect, udpassociate e udpreply. Uma regra que permite apenas a ligação TCP já testada não estabelece as permissões UDP necessárias.

A associação UDP também envolve um ponto final de retransmissão e tráfego de retorno. As firewalls e a tradução de endereços têm de permitir esse caminho real. Abrir o ouvinte TCP do SOCKS não equivale a tornar o respetivo retransmissor UDP alcançável.

Verifique a documentação e as configurações atuais de proxy da aplicação. Versões diferentes podem tratar mensagens, multimédia e chamadas de forma diferente. Uma receita de fórum para um cliente antigo não deve ser apresentada como prova de que todos os clientes atuais encaminham chamadas através do SOCKS.

Evite abrir todas as portas UDP como primeiro diagnóstico. Determine o comportamento do retransmissor e o alcance pretendido dos clientes e depois aplique a política de rede restrita adequada. Da mesma forma, desativar uma definição de proxy para chamadas pode fazer com que uma chamada funcione ao enviá-la diretamente, o que altera a rota externa em vez de reparar a que passa pelo proxy.

Documente o sucesso por operação: mensagens, transferência de multimédia e chamadas. Um único pedido funcional ou um IP de navegador alterado não podem provar que todas as partes de outra aplicação partilham a mesma saída de proxy.