SOCKS 프록시는 메시지는 불러오지만 통화에서는 실패한다

텍스트 메시지는 SOCKS 프록시를 통해 도착하지만 음성 통화는 연결되지 않습니다. 프록시가 반드시 완전히 고장 난 것은 아닙니다. 애플리케이션이 통화에 다른 전송 방식을 사용할 수 있습니다.

성공한 TCP 요청은 해당 작업에 대한 TCP 경로를 증명합니다. SOCKS5는 UDP 연관도 정의하지만, 클라이언트, SOCKS 서비스, 네트워크 규칙, 애플리케이션 설정이 모두 의도한 UDP 경로를 지원해야 합니다.

TCP 리스너만 있는 것이 아니다

Dante 설명서는 프로토콜 규칙과 명령 규칙을 구분하며 connect, udpassociate, udpreply 등이 있습니다. 이미 테스트한 TCP 연결만 허용하는 규칙은 필요한 UDP 권한을 확립하지 않습니다.

UDP 연관에는 릴레이 엔드포인트와 반환 트래픽도 포함됩니다. 방화벽과 주소 변환이 그 실제 경로를 허용해야 합니다. SOCKS의 TCP 리스너를 여는 것은 UDP 릴레이를 도달 가능하게 만드는 것과 같지 않습니다.

애플리케이션의 현재 프록시 문서와 설정을 확인하십시오. 버전마다 메시지, 미디어, 통화를 다르게 처리할 수 있습니다. 오래된 클라이언트를 위한 포럼 조리법을 모든 현재 클라이언트가 통화를 SOCKS로 라우팅한다는 증거로 제시해서는 안 됩니다.

첫 진단으로 모든 UDP 포트를 여는 것은 피하십시오. 릴레이 동작과 의도한 클라이언트 범위를 확인한 다음 적절한 제한 네트워크 정책을 적용하십시오. 마찬가지로 통화용 프록시 설정을 비활성화하면 통화를 직접 보내 작동하게 할 수 있는데, 이는 프록시 경로를 고치는 대신 외부 경로를 바꾸는 것입니다.

작업별로 성공을 기록하십시오: 메시지, 미디어 전송, 통화. 하나의 성공한 요청이나 바뀐 브라우저 IP로는 다른 애플리케이션의 모든 부분이 같은 프록시 출구를 공유한다는 것을 증명할 수 없습니다.