En SOCKS-proxy kan läsa in meddelanden men misslyckas med samtal
Med Dantes handbok och SOCKS5:s UDP-krav förklaras varför en fungerande TCP-väg inte bevisar stöd för ett programs samtaltrafik.
Textmeddelanden kommer in via en SOCKS-proxy, men ett röstsamtal kopplas aldrig upp. Proxyn är inte nödvändigtvis helt trasig. Programmet kan använda en annan transport för samtal.
En lyckad TCP-begäran bevisar en TCP-väg för den åtgärden. SOCKS5 definierar också UDP-association, men klienten, SOCKS-tjänsten, nätverksreglerna och programmets inställningar måste alla stödja den avsedda UDP-vägen.
Det finns mer än en TCP-lyssnare
Dante-handboken skiljer på protokoll- och kommandoregler, inklusive connect, udpassociate och udpreply. En regel som bara tillåter den TCP-anslutning du redan testat upprättar inte de nödvändiga UDP-behörigheterna.
UDP-associationen omfattar också en relay-slutpunkt och returtrafik. Brandväggar och adressöversättning måste tillåta just den vägen. Att öppna SOCKS TCP-lyssnare är inte samma sak som att göra dess UDP-relay nåbart.
Kontrollera programmets aktuella proxy-dokumentation och inställningar. Olika versioner kan hantera meddelanden, media och samtal olika. Ett forumrecept för en gammal klient bör inte presenteras som bevis för att varje nuvarande klient dirigerar samtal via SOCKS.
Undvik att öppna alla UDP-portar som första diagnos. Fastställ relaybeteendet och den avsedda klientomfattningen och tillämpa sedan lämplig begränsad nätverkspolicy. På samma sätt kan en avstängd proxy-för-samtal-inställning få ett samtal att fungera genom att skicka det direkt, vilket ändrar den utgående vägen i stället för att reparera den proxade.
Dokumentera framgång per åtgärd: meddelanden, medieöverföring och samtal. En enda fungerande begäran eller en ändrad webbläsar-IP kan inte bevisa att varje del av ett annat program delar samma proxy-utgång.