Un proxy SOCKS può caricare i messaggi ma fallire sulle chiamate

I messaggi di testo arrivano attraverso un proxy SOCKS, ma una chiamata vocale non si connette mai. Il proxy non è necessariamente del tutto guasto. È possibile che l'applicazione usi un altro trasporto per le chiamate.

Una richiesta TCP riuscita dimostra un percorso TCP per quell'operazione. SOCKS5 definisce anche l'associazione UDP, ma il client, il servizio SOCKS, le regole di rete e le impostazioni dell'applicazione devono tutti supportare il percorso UDP previsto.

C'è più di un listener TCP

Il manuale Dante separa le regole di protocollo e di comando, tra cui connect, udpassociate e udpreply. Una regola che consente solo la connessione TCP già testata non stabilisce le autorizzazioni UDP necessarie.

L'associazione UDP comporta anche un endpoint di relay e traffico di ritorno. I firewall e la traduzione degli indirizzi devono consentire quel percorso reale. Aprire il listener TCP di SOCKS non equivale a rendere raggiungibile il suo relay UDP.

Controlla la documentazione e le impostazioni proxy attuali dell'applicazione. Versioni diverse possono gestire messaggi, contenuti multimediali e chiamate in modo diverso. Una ricetta da forum per un vecchio client non va presentata come prova che ogni client attuale instrada le chiamate tramite SOCKS.

Evita di aprire ogni porta UDP come prima diagnosi. Determina il comportamento del relay e l'ambito previsto dei client, poi applica la politica di rete limitata appropriata. Allo stesso modo, disattivare un'impostazione proxy per le chiamate può far funzionare una chiamata inviandola direttamente, il che cambia il percorso verso l'esterno invece di riparare quello che passa dal proxy.

Documenta il successo per operazione: messaggi, trasferimento di contenuti multimediali e chiamate. Una singola richiesta funzionante o un IP del browser cambiato non possono dimostrare che ogni parte di un'altra applicazione condivida la stessa uscita del proxy.