Një proxy SOCKS mund të ngarkojë mesazhe por dështon në thirrje

Mesazhet me tekst mbërrijnë përmes një proxy SOCKS, por një thirrje zanore nuk lidhet kurrë. Proxy nuk është domosdoshmërisht plotësisht i prishur. Aplikacioni mund të përdorë një transport tjetër për thirrjet.

Një kërkesë TCP e suksesshme dëshmon një rrugë TCP për atë veprim. SOCKS5 përcakton gjithashtu asociimin UDP, por klienti, shërbimi SOCKS, rregullat e rrjetit dhe cilësimet e aplikacionit duhet të gjitha të mbështesin rrugën UDP të synuar.

Ka më shumë se një dëgjues TCP

Manuali Dante ndan rregullat e protokollit dhe të komandave, duke përfshirë connect, udpassociate dhe udpreply. Një rregull që lejon vetëm lidhjen TCP që keni testuar tashmë nuk vendos lejet e nevojshme UDP.

Asociimi UDP përfshin gjithashtu një pikë të fundme përcjelljeje dhe trafik kthimi. Muret e zjarrit dhe përkthimi i adresave duhet të lejojnë pikërisht atë rrugë. Hapja e dëgjuesit TCP të SOCKS nuk është e njëjtë me bërjen e përcjellësit të tij UDP të arritshëm.

Kontrolloni dokumentacionin dhe cilësimet aktuale të proxy-t të aplikacionit. Versione të ndryshme mund t'i trajtojnë ndryshe mesazhet, mediat dhe thirrjet. Një recetë forumi për një klient të vjetër nuk duhet të paraqitet si provë që çdo klient aktual i drejton thirrjet përmes SOCKS.

Shmangni hapjen e çdo porte UDP si diagnozën e parë. Përcaktoni sjelljen e përcjelljes dhe shtrirjen e synuar të klientëve, pastaj zbatoni politikën e duhur të kufizuar të rrjetit. Po ashtu, çaktivizimi i një cilësimi proxy për thirrjet mund ta bëjë një thirrje të funksionojë duke e dërguar drejtpërdrejt, gjë që ndryshon rrugën e jashtme në vend që të riparojë atë përmes proxy-t.

Dokumentoni suksesin sipas veprimit: mesazhet, transferimi i medias dhe thirrjet. Një kërkesë e vetme që funksionon ose një IP shfletuesi e ndryshuar nuk mund të dëshmojnë se çdo pjesë e një aplikacioni tjetër ndan të njëjtin dalje proxy.