A SOCKS proxy betöltheti az üzeneteket, de a hívásoknál elbukik

A szöveges üzenetek SOCKS proxyn keresztül érkeznek, de a hanghívás soha nem jön létre. A proxy nem feltétlenül teljesen hibás. Lehet, hogy az alkalmazás más átvitelt használ a hívásokhoz.

Egy sikeres TCP-kérés bizonyítja az adott művelet TCP-útvonalát. A SOCKS5 is meghatározza az UDP-társítást, de az ügyfélnek, a SOCKS szolgáltatásnak, a hálózati szabályoknak és az alkalmazás beállításainak egyaránt támogatniuk kell a szándékolt UDP-útvonalat.

Több van egy TCP-figyelőnél

A Dante kézikönyv külön kezeli a protokoll- és parancsszabályokat, köztük a connect, udpassociate és udpreply elemeket. Az a szabály, amely csak a már tesztelt TCP-kapcsolatot engedi, nem hozza létre a szükséges UDP-engedélyeket.

Az UDP-társítás továbbító végpontot és visszforgalmat is magában foglal. A tűzfalaknak és a címfordításnak engedélyezniük kell ezt a tényleges útvonalat. A SOCKS TCP-figyelőjének megnyitása nem egyenértékű az UDP-továbbító elérhetővé tételével.

Ellenőrizze az alkalmazás jelenlegi proxy-dokumentációját és beállításait. A különböző verziók eltérően kezelhetik az üzeneteket, a médiát és a hívásokat. Egy régi ügyfélhez írt fórumreceptet nem szabad annak bizonyítékaként bemutatni, hogy minden jelenlegi ügyfél SOCKS-on keresztül irányítja a hívásokat.

Kerülje az összes UDP-port megnyitását első diagnózisként. Határozza meg a továbbító viselkedését és a szándékolt ügyfélkört, majd alkalmazza a megfelelő korlátozott hálózati irányelvet. Hasonlóképpen, a hívásokhoz tartozó proxy-beállítás kikapcsolása közvetlen küldéssel működésre bírhatja a hívást, ami a kifelé vezető útvonalat változtatja meg ahelyett, hogy a proxyn átvezetőt javítaná.

Dokumentálja a sikert műveletenként: üzenetek, médiaátvitel és hívások. Egyetlen működő kérés vagy egy megváltozott böngésző-IP nem bizonyítja, hogy egy másik alkalmazás minden része ugyanazt a proxy-kimenetet használja.