Redsocks lắng nghe trên loopback nhưng lưu lượng VPN không bao giờ đến

Một đường hầm được dựng lên, máy khách có thể ping cổng, nhưng mọi yêu cầu web đi qua đường proxy đều chết. Tiến trình redsocks đang chạy và cổng của nó đang lắng nghe, nên dịch vụ trông khỏe mạnh từ chính cổng. Thứ thất bại là bước giao hàng: một gói được chuyển hướng từ đường hầm không đáp xuống socket mà bạn đã khởi động. Địa chỉ ràng buộc và đích chuyển hướng phải khớp nhau, và thường chỉ một trong hai được kiểm tra.

Một gói đã chuyển hướng thực sự đáp xuống đâu

Proxy trong suốt trên một cổng dùng REDIRECT trong bảng nat tại PREROUTING để viết lại đích của một kết nối đến thành một cổng cục bộ. Đích được viết lại là một địa chỉ cục bộ như giao diện mà gói đi vào nhìn thấy, không phải địa chỉ loopback của một tiến trình được khởi động ở nơi khác. Một trình lắng nghe chỉ gắn với 127.0.0.1 chấp nhận các kết nối vốn đã là cục bộ trên máy chủ, và đây chính là trường hợp vẫn hoạt động trong khi lưu lượng đường hầm thất bại. Loopback của chính máy khách là địa chỉ thứ ba và không bao giờ là đích của quy tắc trên cổng.

Vì vậy trước khi chạm vào thông tin đăng nhập của tầng trên, hãy xác lập hai sự thật: quy tắc viết lại sang địa chỉ cục bộ nào, và socket proxy được gắn vào địa chỉ nào.

Đọc trình lắng nghe và quy tắc chuyển hướng cùng nhau

In bảng socket và các quy tắc nat trong cùng một lượt, vì một quy tắc trỏ đến cổng mà không ai sở hữu trông giống hệt một quy tắc trỏ đến địa chỉ sai. sudo ss -ltnp | grep redsocks hiển thị địa chỉ ràng buộc và tiến trình sở hữu. sudo iptables -t nat -S PREROUTING hiển thị đích REDIRECT, và sudo iptables -t nat -L PREROUTING -v -n cho biết có thứ gì khớp với nó hay không.

Một bước nhảy vào chuỗi người dùng tên REDSOCKS không đạt được gì trừ khi chuỗi đó tồn tại và mang các loại trừ dự định cùng hành động REDIRECT. Hãy đọc chuỗi mà nó nhảy vào bằng sudo iptables -t nat -S REDSOCKS thay vì giả định rằng cái tên làm công việc đó.

Sau đó so sánh hai giá trị. Nếu quy tắc chuyển hướng đến một địa chỉ cổng trên cổng 12345 và trình lắng nghe báo cáo 127.0.0.1:12345, sự không khớp giải thích lỗi mà không cần chẩn đoán thêm.

Ràng buộc hẹp, rồi giới hạn những gì có thể đến nó

Cấu hình mẫu của tầng trên mặc định đặt trình lắng nghe trên loopback vì một lý do chính đáng: proxy trong suốt chấp nhận kết nối thay cho bất kỳ ai có thể đến nó. Đổi ràng buộc sang 0.0.0.0 sửa được việc giao hàng và đồng thời mở cổng trên mọi giao diện, đây là một thay đổi bảo mật, không phải sửa chữa trung tính. Hãy ưu tiên ràng buộc vào địa chỉ cục bộ cụ thể mà việc chuyển hướng nhắm tới, và giữ cổng đóng trên các giao diện không tin cậy. Nếu bắt buộc phải ràng buộc rộng hơn, hãy thêm quy tắc tường lửa trên máy chủ chỉ cho phép dải nguồn của đường hầm và lưu lượng cục bộ của chính cổng.

Mở cổng trên giao diện công cộng không bao giờ cần thiết cho lưu lượng VPN được chuyển hướng, vì kết nối kết thúc cục bộ sau khi viết lại. Đừng phơi proxy ra internet để một chuyển hướng cục bộ hoạt động.

Chứng minh bằng một kết nối mới từ máy khách

Kiểm tra từ một máy khách VPN thật với một kết nối TCP mới, không phải từ shell trên cổng. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com trên máy khách chạy thử đường đi đã chuyển hướng từ đầu đến cuối.

Sau đó xác nhận rằng một kết nối trực tiếp đến trình lắng nghe từ mạng không tin cậy vẫn bị từ chối, và kết nối thượng nguồn của chính proxy không bị bắt lại bởi cùng quy tắc. Việc bắt đệ quy biểu hiện như một proxy tự kết nối với chính nó và không bao giờ hoàn thành yêu cầu. Thêm đích của proxy vào tập loại trừ, hoặc đánh dấu các gói đi ra của nó để chuỗi bỏ qua chúng.

Cuối cùng, hãy nhớ những gì đường đi này không bao phủ. Chuyển hướng TCP thông thường của redsocks không biến UDP, QUIC hay DNS thành lưu lượng SOCKS, và các đích riêng thường cần loại trừ rõ ràng. Một bài kiểm tra cục bộ thành công chỉ chứng minh đường loopback vốn không bao giờ là vấn đề.