Định tuyến theo chính sách so với SOCKS: lớp nào thực sự làm proxy lưu lượng

Bạn đã thêm một tuyến theo chính sách gửi lưu lượng của một máy khách VPN đến một máy chủ đang chạy trình lắng nghe SOCKS trên cổng 1080. Các gói tin đến, trình lắng nghe không ghi nhật ký gì, và kết nối bị treo. Tuyến không có gì sai: bước nhảy tiếp theo chọn nơi một gói tin đi, và SOCKS là một cuộc trò chuyện mà máy khách phải bắt đầu. Hãy so sánh ba kiến trúc mà người ta thường muốn nói tới khi gửi lưu lượng qua proxy, và sẽ rõ phần nào còn thiếu trong thiết lập của bạn.

Định tuyến, DNAT và SOCKS thay đổi những thứ khác nhau

Một tuyến theo chính sách viết lại một quyết định ở lớp 3. Hai dòng là đủ để gửi lưu lượng của một máy khách đến bước nhảy tiếp theo đã chọn:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

Sau đó, nhân đưa gói tin cho 10.50.0.2 trong khi đích gốc vẫn còn trong tiêu đề IP. Nếu 10.50.0.2 là bộ định tuyến, nó chuyển tiếp gói tin. Nếu đó là máy chủ có daemon SOCKS trên 1080, gói tin không được gửi đến bất cứ thứ gì có thể nhận nó, và DNAT đến cổng 1080 cũng không giúp gì, vì gói tin đã dịch vẫn mang tải trọng ứng dụng gốc thay vì lời chào SOCKS.

SOCKS5 bắt đầu bằng byte phiên bản, danh sách phương thức, trao đổi xác thực và một yêu cầu nêu tên đích. Đó là dữ liệu ứng dụng. Không có mục định tuyến nào và không có đích netfilter nào tạo ra chúng, và đó là so sánh trong một dòng: định tuyến chọn một đường, SOCKS yêu cầu máy chủ tạo kết nối thứ hai.

Trường hợp một: ứng dụng tự nói được SOCKS

Khi chương trình có cài đặt proxy, đây là đường ngắn nhất và không cần thay đổi nhân. Hãy trỏ nó đến trình lắng nghe, cung cấp thông tin đăng nhập nếu máy chủ yêu cầu, và quyết định xem tên được phân giải cục bộ hay chuyển cho proxy. Với curl đây là các cờ khác nhau, và sự khác biệt quan trọng khi đích chỉ được phân giải từ phía proxy:

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

Các ứng dụng bỏ qua biến môi trường proxy, hoặc mở socket thô, không thể được giúp theo cách này. Trình duyệt và hầu hết công cụ HTTP đều ổn; máy khách trò chơi, daemon thư hoặc tệp nhị phân tùy ý của nhà cung cấp thường không. Ranh giới là theo từng ứng dụng và từng giao thức, vì thế tùy chọn này xuất sắc để thử nghiệm và yếu như câu trả lời cho toàn bộ VPN.

Trường hợp hai: bộ tiếp hợp chuyển luồng IP thành phiên proxy

Với những chương trình không nói được SOCKS, việc chuyển đổi phải diễn ra trong thứ gì đó kết thúc lưu lượng IP và mở phiên proxy thay mặt chúng. Thành phần đó sở hữu một giao diện đường hầm, chấp nhận các luồng mà định tuyến theo chính sách đã chọn, thực hiện bắt tay SOCKS cho từng luồng và dựng lại các phản hồi. Tuyến hướng lưu lượng về phía nó; bộ tiếp hợp là thứ tạo ra phiên.

Hãy đọc tài liệu của nó trước khi giao cả một mạng con. Nhiều bộ tiếp hợp mang TCP tốt và chỉ xử lý UDP qua một liên kết UDP của SOCKS5, và không cái nào biến ICMP thành lưu lượng proxy, nên một ping thành công không nói gì về đường proxy. DNS là cái bẫy khác: nếu bộ tiếp hợp phân giải tên cục bộ, các bản ghi chỉ nội bộ sẽ được phân giải thành câu trả lời sai, hoặc thành không gì cả.

Ngăn vòng lặp là chi tiết vận hành cắn người. Các kết nối của chính bộ tiếp hợp đến máy chủ SOCKS không được định tuyến ngược vào bộ tiếp hợp, nên lưu lượng của nó cần một ngoại lệ trong quy tắc hoặc một địa chỉ nguồn riêng. Làm sai điều này và phiên proxy sẽ cố gắng làm proxy cho chính nó.

Trường hợp ba: máy chủ thực ra là một cổng vào được định tuyến

Đôi khi thiết lập đang hoạt động không chứa SOCKS nào cả. Máy chủ từ xa chuyển tiếp gói tin hoặc thực hiện NAT trên chúng, và quy tắc dựa trên nguồn chỉ đơn giản chọn nó làm lối ra. Thiết kế đó là hợp lệ, và nó giải thích vì sao một cấu hình sao chép hoạt động trên mạng này và thất bại trên mạng khác: quy tắc giống hệt, phần còn thiếu là dịch vụ chuyển tiếp ở phía bên kia.

Ba trường hợp tách nhau nhanh chóng. Hãy kiểm tra cái gì thực sự đang lắng nghe, rồi xem những byte đầu tiên đến được máy chủ:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

Byte tải trọng đầu tiên của một máy khách SOCKS thật là 0x05, phiên bản trong lời chào. Nếu bản ghi cho thấy dữ liệu ứng dụng gốc thay vào đó, sẽ không daemon SOCKS nào trả lời, vì cuộc thương lượng chưa bao giờ bắt đầu. Nếu không có gì lắng nghe trên 1080, máy chủ là một cổng vào, và câu hỏi trở thành liệu nó có chuyển tiếp và có đường quay lại hay không.

Chọn lớp bằng bốn câu hỏi

Chương trình có cài đặt proxy không? Hãy dùng nó và dừng ở đó. Lưu lượng có bao gồm UDP hoặc ICMP phải sống sót không? Chỉ cổng vào được định tuyến hoặc NAT mới mang ICMP, và UDP cần một liên kết SOCKS5 mà cả hai đầu đều hỗ trợ. Có phải mọi tiến trình trên máy đều được bao phủ, kể cả những cái bạn không thể cấu hình? Vậy bạn cần một bộ tiếp hợp sở hữu giao diện và kết thúc luồng. Bạn có thể đảm nhận cả định tuyến, DNS và các ngoại lệ ngăn vòng lặp của nó không? Nếu không, cổng vào đơn giản sẽ tốn ít chi phí vận hành hơn.

Một sự phân biệt nên được giữ rõ ràng. Tùy chọn socks-proxy của chính máy khách VPN mô tả cách kết nối đường hầm bên ngoài đến máy chủ của nó, và không nói gì về việc chuyển đổi các luồng bên trong của máy khách. Hai điều này liên tục bị nhầm lẫn trong cùng một phiếu. Hãy quyết định bạn cần mối quan hệ nào trước khi chạm vào một tuyến.