En SOCKS-proxy kan indlæse beskeder, men fejler ved opkald
Med Dantes håndbog og SOCKS5's UDP-krav forklares det, hvorfor en fungerende TCP-rute ikke beviser støtte til en applikations opkaldstrafik.
Tekstbeskeder ankommer gennem en SOCKS-proxy, men et taleopkald oprettes aldrig. Proxyen er ikke nødvendigvis helt i stykker. Applikationen bruger muligvis en anden transport til opkald.
En vellykket TCP-anmodning beviser en TCP-rute for den handling. SOCKS5 definerer også UDP-association, men klienten, SOCKS-tjenesten, netværksreglerne og applikationens indstillinger skal alle understøtte den tilsigtede UDP-rute.
Der er mere end en TCP-lytter
Dante-håndbogen adskiller protokol- og kommandoregler, herunder connect, udpassociate og udpreply. En regel, der kun tillader den TCP-forbindelse, du allerede har testet, fastslår ikke de nødvendige UDP-tilladelser.
UDP-association omfatter også et relay-endepunkt og returtrafik. Firewalls og adresseoversættelse skal tillade netop den rute. At åbne SOCKS' TCP-lytter er ikke det samme som at gøre dens UDP-relay tilgængeligt.
Kontrollér applikationens aktuelle proxy-dokumentation og indstillinger. Forskellige versioner kan håndtere beskeder, medier og opkald forskelligt. En forumopskrift til en gammel klient bør ikke fremstilles som bevis for, at enhver nuværende klient sender opkald gennem SOCKS.
Undgå at åbne alle UDP-porte som første diagnosticering. Fastlæg relay-adfærden og det tilsigtede klientomfang, og anvend derefter den passende begrænsede netværkspolitik. På samme måde kan deaktivering af en proxy-til-opkald-indstilling få et opkald til at virke ved at sende det direkte, hvilket ændrer den udadgående rute i stedet for at reparere den proxyede.
Dokumentér succes pr. handling: beskeder, medieoverførsel og opkald. En enkelt fungerende anmodning eller en ændret browser-IP kan ikke bevise, at enhver del af en anden applikation deler samme proxy-udgang.