Оригинални дестинации при прозрачно препращане от TCP към SOCKS

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

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

Липсващият компонент е транслатор

Прозрачен компонент за препращане от TCP към прокси стои между тези интерфейси. Той открива дестинацията, която приложението е заявило първоначално, установява подходящата SOCKS или HTTP CONNECT сесия и след това препредава данните на приложението по получения поток.

По пътя си с Linux iptables източникът на redsocks извлича запазената дестинация чрез SO_ORIGINAL_DST. Други операционни системи и методи за пренасочване използват различни механизми. Това е свойство на пренасочвача и на мрежовата настройка, а не обикновена функция на SOCKS клиент.

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

Пазете обхвата на транслатора ясен. Работеща пренасочена TCP връзка не доказва поддръжка на произволен UDP, ICMP или на всеки път на resolver. Протоколът на горното прокси и реализацията на транслатора все още определят поддържаните операции.

Когато настройка се провали веднага след свързване, проверете границата на протокола, преди да разширявате правилата за достъп. Напълно достъпен SOCKS слушател може да отхвърли байтове, които никога не са били SOCKS заявка.