Serwer proxy SOCKS może wczytywać wiadomości, ale zawodzi przy połączeniach
Na podstawie podręcznika Dante i wymagań UDP w SOCKS5 wyjaśniono, dlaczego działająca ścieżka TCP nie dowodzi obsługi ruchu połączeń aplikacji.
Wiadomości tekstowe docierają przez serwer proxy SOCKS, ale połączenie głosowe nigdy nie zostaje nawiązane. Proxy nie musi być całkowicie zepsute. Aplikacja może używać do połączeń innego transportu.
Udane żądanie TCP dowodzi istnienia ścieżki TCP dla tej operacji. SOCKS5 definiuje także asocjację UDP, ale klient, usługa SOCKS, reguły sieciowe i ustawienia aplikacji muszą obsługiwać zamierzoną trasę UDP.
To coś więcej niż nasłuch TCP
Podręcznik Dante rozdziela reguły protokołu i poleceń, w tym connect, udpassociate i udpreply. Reguła zezwalająca tylko na już przetestowane połączenie TCP nie ustanawia wymaganych uprawnień UDP.
Asocjacja UDP obejmuje też punkt końcowy przekazywania i ruch powrotny. Zapory sieciowe i translacja adresów muszą zezwalać na tę rzeczywistą trasę. Otwarcie nasłuchu TCP w SOCKS nie jest tym samym co udostępnienie jego przekazywania UDP.
Sprawdź aktualną dokumentację i ustawienia proxy w aplikacji. Różne wersje mogą odmiennie obsługiwać wiadomości, multimedia i połączenia. Przepisu z forum dla starego klienta nie należy przedstawiać jako dowodu, że każdy obecny klient kieruje połączenia przez SOCKS.
Nie zaczynaj diagnostyki od otwierania wszystkich portów UDP. Ustal zachowanie przekazywania i zamierzony zakres klientów, a następnie zastosuj odpowiednią ograniczoną politykę sieciową. Podobnie wyłączenie ustawienia proxy dla połączeń może sprawić, że połączenie zadziała, bo zostanie wysłane bezpośrednio, co zmienia trasę wyjściową, a nie naprawia tej przez proxy.
Dokumentuj powodzenie według operacji: wiadomości, przesyłanie multimediów i połączenia. Jedno działające żądanie lub zmieniony adres IP przeglądarki nie dowodzi, że każda część innej aplikacji korzysta z tego samego wyjścia proxy.