Un proxy SOCKS pode cargar mensaxes pero fallar nas chamadas

As mensaxes de texto chegan a través dun proxy SOCKS, pero unha chamada de voz nunca se conecta. O proxy non está necesariamente roto por completo. Pode que a aplicación use outro transporte para as chamadas.

Unha solicitude TCP correcta demostra unha ruta TCP para esa operación. SOCKS5 tamén define a asociación UDP, pero o cliente, o servizo SOCKS, as regras de rede e a configuración da aplicación deben admitir a ruta UDP prevista.

Hai máis ca un oínte TCP

O manual de Dante separa as regras de protocolo e de comandos, incluíndo connect, udpassociate e udpreply. Unha regra que só permite a conexión TCP que xa probou non establece os permisos UDP necesarios.

A asociación UDP tamén implica un punto final de retransmisión e tráfico de retorno. As devasas e a tradución de enderezos deben permitir esa ruta real. Abrir o oínte TCP de SOCKS non equivale a facer accesible o seu retransmisor UDP.

Revise a documentación e a configuración actuais do proxy da aplicación. Distintas versións poden tratar as mensaxes, os medios e as chamadas de forma diferente. Unha receita de foro para un cliente antigo non debería presentarse como proba de que todo cliente actual encamiña as chamadas a través de SOCKS.

Evite abrir todos os portos UDP como primeiro diagnóstico. Determine o comportamento do retransmisor e o ámbito previsto de clientes e logo aplique a política de rede restrinxida axeitada. Do mesmo xeito, desactivar un axuste de proxy para chamadas pode facer que unha chamada funcione enviándoa directamente, o que cambia a ruta de saída en lugar de reparar a que pasa polo proxy.

Documente o éxito por operación: mensaxes, transferencia de medios e chamadas. Unha soa solicitude que funcione ou un IP de navegador cambiado non poden demostrar que cada parte doutra aplicación comparte a mesma saída de proxy.