Оригинални одредишта во транспарентно проследување од TCP кон SOCKS

Еден огнен ѕид може да промени каде слетува TCP врската. Но само со таа промена не може да го научи изворното приложение да зборува SOCKS.

Обичен SOCKS сервер очекува преговори што го опишуваат бараното одредиште. Приложение што не знае за проксито наместо тоа веднаш ги испраќа сопствените протокол-бајти. Пренасочете ги тие бајти право кон SOCKS слушател и двете страни ќе се разидат околу првата порака.

Компонентата што недостасува е преведувач

Транспарентна компонента за TCP кон прокси стои меѓу тие интерфејси. Таа го открива одредиштето што приложението првично го побарало, воспоставува соодветна SOCKS или HTTP CONNECT сесија, а потоа ги проследува податоците на приложението по добиениот тек.

На својата Linux iptables патека, изворниот код на redsocks го добива зачуваното одредиште со SO_ORIGINAL_DST. Други оперативни системи и методи на пренасочување користат различни механизми. Ова е својство на пренасочувачот и на мрежното поставување, а не обична функција на SOCKS клиент.

Информацијата за оригиналното одредиште објаснува и зошто преместувањето на правило за пренасочување од домаќинот на проксито на неповрзана порта не е секогаш еквивалентно. Процесот што прима ги бара метаподатоците што ги налага неговиот режим на пресретнување. Адреса препишана на друго место можеби веќе не ја дава таа информација во очекуваната форма.

Држете го опсегот на преведувачот јасен. Работна пренасочена TCP врска не докажува поддршка за произволно UDP, ICMP или секоја патека на разрешувач. Протоколот на надреденото прокси и реализацијата на преведувачот сè уште ги одредуваат поддржаните операции.

Кога поставувањето не успее веднаш по поврзувањето, проверете ја границата на протоколот пред да ги проширите правилата за пристап. Совршено достапен SOCKS слушател може да одбие бајти што никогаш не биле SOCKS барање.