En SOCKS-proxy kan laste meldinger, men feiler på anrop
Med Dantes håndbok og SOCKS5 sine UDP-krav forklares det hvorfor en fungerende TCP-rute ikke beviser støtte for en applikasjons anropstrafikk.
Tekstmeldinger ankommer gjennom en SOCKS-proxy, men en taleanrop kobles aldri opp. Proxyen er ikke nødvendigvis helt ødelagt. Applikasjonen bruker kanskje en annen transport for anrop.
En vellykket TCP-forespørsel beviser en TCP-rute for den operasjonen. SOCKS5 definerer også UDP-assosiasjon, men klienten, SOCKS-tjenesten, nettverksreglene og applikasjonsinnstillingene må alle støtte den tiltenkte UDP-ruten.
Det er mer enn en TCP-lytter
Dante-håndboken skiller protokoll- og kommandoregler, inkludert connect, udpassociate og udpreply. En regel som bare tillater TCP-tilkoblingen du allerede har testet, etablerer ikke de nødvendige UDP-tillatelsene.
UDP-assosiasjon innebærer også et relay-endepunkt og returtrafikk. Brannmurer og adresseoversettelse må tillate nettopp den ruten. Å åpne SOCKS sin TCP-lytter er ikke det samme som å gjøre UDP-relayet tilgjengelig.
Sjekk applikasjonens gjeldende proxy-dokumentasjon og innstillinger. Ulike versjoner kan håndtere meldinger, medier og anrop ulikt. En forumoppskrift for en gammel klient bør ikke presenteres som bevis for at enhver nåværende klient ruter anrop gjennom SOCKS.
Unngå å åpne alle UDP-porter som første diagnose. Fastslå relayatferden og det tiltenkte klientomfanget, og bruk deretter riktig begrenset nettverkspolicy. På samme måte kan deaktivering av en proxy-for-anrop-innstilling få et anrop til å virke ved å sende det direkte, noe som endrer den utgående ruten i stedet for å reparere den proxyede.
Dokumenter suksess per operasjon: meldinger, medieoverføring og anrop. En enkelt fungerende forespørsel eller en endret nettleser-IP kan ikke bevise at enhver del av en annen applikasjon deler samme proxy-utgang.