Đích gốc trong chuyển tiếp TCP sang SOCKS trong suốt

Tường lửa có thể thay đổi nơi một kết nối TCP hạ cánh. Nhưng chỉ với thay đổi đó, nó không thể dạy ứng dụng gốc nói SOCKS.

Máy chủ SOCKS thông thường chờ một cuộc thương lượng mô tả đích được yêu cầu. Ứng dụng không biết proxy thì thay vào đó gửi ngay các byte giao thức của chính nó. Chuyển hướng các byte đó thẳng tới bộ lắng nghe SOCKS và hai bên sẽ bất đồng về thông điệp đầu tiên.

Thành phần còn thiếu là bộ chuyển đổi

Một thành phần TCP-sang-proxy trong suốt nằm giữa các giao diện đó. Nó xác định đích mà ứng dụng đã yêu cầu ban đầu, thiết lập phiên SOCKS hoặc HTTP CONNECT phù hợp, rồi chuyển tiếp dữ liệu ứng dụng qua luồng hình thành.

Trên đường Linux iptables của nó, mã nguồn redsocks lấy đích đã được bảo toàn bằng SO_ORIGINAL_DST. Các hệ điều hành và phương thức chuyển hướng khác dùng cơ chế khác. Đây là thuộc tính của bộ chuyển hướng và cấu hình mạng, không phải tính năng của một ứng dụng khách SOCKS thông thường.

Thông tin về đích gốc cũng giải thích vì sao việc chuyển một quy tắc chuyển hướng từ máy chủ proxy sang một cổng không liên quan không phải lúc nào cũng tương đương. Tiến trình nhận cần siêu dữ liệu mà chế độ chặn của nó đòi hỏi. Một địa chỉ được viết lại ở nơi khác có thể không còn cung cấp thông tin đó theo dạng mong đợi.

Giữ phạm vi của bộ chuyển đổi rõ ràng. Một kết nối TCP đã chuyển hướng hoạt động không chứng minh hỗ trợ UDP tùy ý, ICMP hay mọi đường phân giải. Giao thức proxy thượng nguồn và cách hiện thực bộ chuyển đổi vẫn quy định các thao tác được hỗ trợ.

Khi cấu hình thất bại ngay sau khi kết nối, hãy kiểm tra ranh giới giao thức trước khi mở rộng quy tắc truy cập. Một bộ lắng nghe SOCKS hoàn toàn có thể tiếp cận vẫn có thể từ chối những byte chưa bao giờ là yêu cầu SOCKS.