SOCKS прокси може да вчитува пораки, но не успева при повици
Преку Dante прирачникот и UDP барањата на SOCKS5 се објаснува зошто работна TCP патека не докажува поддршка за повичниот сообраќај на апликација.
Текстуалните пораки пристигнуваат преку SOCKS прокси, но гласовниот повик никогаш не се поврзува. Проксито не е нужно целосно расипано. Апликацијата може да користи друг пренос за повиците.
Успешно TCP барање докажува TCP патека за таа операција. SOCKS5 исто така дефинира UDP здружување, но клиентот, SOCKS услугата, мрежните правила и поставките на апликацијата мора да ја поддржуваат саканата UDP рута.
Има повеќе од TCP слушател
Dante прирачникот ги одделува правилата за протокол и за команди, вклучувајќи connect, udpassociate и udpreply. Правило што дозволува само веќе тестираната TCP врска не ги воспоставува потребните UDP дозволи.
UDP здружувањето вклучува и крајна точка за препраќање и повратен сообраќај. Огнените ѕидови и преводот на адреси мора да ја дозволат таа вистинска патека. Отворањето на TCP слушателот на SOCKS не е исто како да се направи неговиот UDP препраќач достапен.
Проверете ја актуелната документација и поставки за прокси во апликацијата. Различни верзии можат различно да ракуваат со пораки, медиуми и повици. Рецепт од форум за стар клиент не треба да се претставува како доказ дека секој сегашен клиент ги насочува повиците преку SOCKS.
Избегнувајте отворање на сите UDP порти како прва дијагноза. Определете го однесувањето на препраќачот и предвидениот опсег на клиенти, потоа примените соодветна ограничена мрежна политика. Исто така, исклучувањето на поставката за прокси при повици може да го проработи повикот со директно испраќање, што ја менува надворешната рута наместо да ја поправи проксираната.
Документирајте го успехот по операција: пораки, пренос на медиуми и повици. Едно работечко барање или променета IP адреса на прелистувачот не може да докаже дека секој дел од друга апликација го дели истиот излез на проксито.