Початкові пункти призначення в прозорому переспрямуванні TCP у SOCKS

Міжмережевий екран може змінити, куди потрапляє TCP-з'єднання. Але самим цим він не може навчити початковий застосунок говорити SOCKS.

Звичайний сервер SOCKS очікує узгодження, що описує запитаний пункт призначення. Застосунок, який не знає про проксі, натомість одразу надсилає власні байти протоколу. Спрямуйте ці байти просто до слухача SOCKS, і дві сторони розійдуться в погляді на перше повідомлення.

Відсутній складник — це транслятор

Прозорий складник переспрямування TCP на проксі стоїть між цими інтерфейсами. Він визначає пункт призначення, який застосунок запитав початково, встановлює належний сеанс SOCKS або HTTP CONNECT, а потім передає дані застосунку отриманим потоком.

На своєму шляху через Linux iptables код redsocks отримує збережений пункт призначення за допомогою SO_ORIGINAL_DST. Інші операційні системи та способи переспрямування використовують інші механізми. Це властивість переспрямовувача й налаштування мережі, а не звичайна можливість клієнта SOCKS.

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

Тримайте межі транслятора явними. Робоче переспрямоване TCP-з'єднання не доводить підтримку довільного UDP, ICMP чи будь-якого шляху розв'язувача. Протокол вищого проксі та реалізація транслятора й далі визначають підтримувані операції.

Якщо налаштування зривається одразу після з'єднання, перевірте межу протоколу, перш ніж розширювати правила доступу. Цілком доступний слухач SOCKS може відкинути байти, які ніколи не були запитом SOCKS.