Oryginalne cele w przezroczystym przekazywaniu TCP do SOCKS
Wyjaśnia, dlaczego przezroczyste przekazywanie TCP do SOCKS wymaga translatora, który odzyskuje oryginalny cel przed negocjacją z proxy.
Zapora może zmienić, gdzie trafia połączenie TCP. Samą tą zmianą nie zdoła jednak nauczyć aplikacji źródłowej mówić w SOCKS.
Zwykły serwer SOCKS oczekuje negocjacji opisującej żądany cel. Aplikacja, która nie zna proxy, wysyła zamiast tego od razu własne bajty protokołu. Przekieruj te bajty prosto do nasłuchu SOCKS, a obie strony nie zgodzą się co do pierwszej wiadomości.
Brakującym elementem jest translator
Przezroczysty element TCP-do-proxy znajduje się między tymi interfejsami. Ustala cel, o który aplikacja pierwotnie prosiła, nawiązuje odpowiednią sesję SOCKS lub HTTP CONNECT, a następnie przekazuje dane aplikacji przez powstały strumień.
Na swojej ścieżce Linux iptables źródło redsocks pobiera zachowany cel za pomocą SO_ORIGINAL_DST. Inne systemy operacyjne i metody przekierowania używają odmiennych mechanizmów. To właściwość przekierowywacza i konfiguracji sieci, a nie zwykła funkcja klienta SOCKS.
Informacja o oryginalnym celu wyjaśnia też, dlaczego przeniesienie reguły przekierowania z hosta proxy na niepowiązaną bramę nie zawsze jest równoważne. Proces odbierający potrzebuje metadanych wymaganych przez jego tryb przechwytywania. Adres przepisany gdzie indziej może już nie dostarczać tej informacji w oczekiwanej postaci.
Utrzymuj zakres translatora w sposób jawny. Działające przekierowane połączenie TCP nie dowodzi obsługi dowolnego UDP, ICMP ani każdej ścieżki resolvera. Protokół nadrzędnego proxy i implementacja translatora nadal określają obsługiwane operacje.
Gdy konfiguracja zawodzi zaraz po połączeniu, sprawdź granicę protokołu, zanim rozszerzysz reguły dostępu. Doskonale osiągalny nasłuch SOCKS może odrzucić bajty, które nigdy nie były żądaniem SOCKS.