Исходные пункты назначения при прозрачной переадресации TCP в SOCKS

Межсетевой экран может изменить, куда попадает TCP-соединение. Но одним этим изменением он не может научить исходное приложение говорить на SOCKS.

Обычный сервер SOCKS ожидает согласования, описывающего запрошенный пункт назначения. Приложение, не знающее о прокси, вместо этого сразу отправляет собственные байты протокола. Направьте эти байты прямо на слушатель SOCKS, и две стороны разойдутся в трактовке первого сообщения.

Недостающий компонент — это транслятор

Прозрачный компонент переадресации TCP на прокси находится между этими интерфейсами. Он определяет пункт назначения, который приложение запросило изначально, устанавливает подходящий сеанс SOCKS или HTTP CONNECT и затем передаёт данные приложения по получившемуся потоку.

На своём пути через Linux iptables исходный код redsocks получает сохранённый пункт назначения с помощью SO_ORIGINAL_DST. Другие операционные системы и способы переадресации используют иные механизмы. Это свойство переадресующего устройства и сетевой настройки, а не обычная возможность клиента SOCKS.

Сведения об исходном пункте назначения также объясняют, почему перенос правила переадресации с хоста прокси на несвязанный шлюз не всегда равноценен. Принимающему процессу нужны метаданные, которых требует его способ перехвата. Адрес, переписанный в другом месте, может уже не давать эти сведения в ожидаемой форме.

Держите границы транслятора явными. Работающее переадресованное TCP-соединение не доказывает поддержку произвольного UDP, ICMP или любого пути распознавателя. Протокол вышестоящего прокси и реализация транслятора по-прежнему определяют поддерживаемые операции.

Если настройка срывается сразу после подключения, проверьте границу протокола, прежде чем расширять правила доступа. Вполне доступный слушатель SOCKS может отвергнуть байты, которые никогда не были запросом SOCKS.