Proxy SOCKS5 cho OpenVPN: đường hầm TCP hay proxy các ứng dụng?

Những mạng chỉ cho phép ra ngoài qua proxy là nơi một hồ sơ đang chạy đột nhiên chết. Địa chỉ proxy là biến ít thú vị nhất trong thất bại đó. Mọi thứ được quyết định bởi hình dạng lưu lượng mà proxy sẽ chuyển, vì các proxy này gửi một luồng byte và đường hầm UDP không phải như vậy. Điều đó để lại hai kiến trúc, và chúng hỏng ở những chỗ khác nhau.

Một ràng buộc quyết định thiết kế

SOCKS5 thực sự có quy định chế độ liên kết UDP. Tuy vậy, hỗ trợ proxy của ứng dụng khách OpenVPN lại được xây quanh các luồng: socks-proxy được ghi tài liệu cho hồ sơ TCP, và proxy HTTP CONNECT không có đường nào cho datagram. Một dòng tài liệu quyết định kiến trúc trước khi bạn chạm vào tệp cấu hình.

Vậy câu hỏi không phải là chọn proxy nào. Mà là đường hầm trở thành một luồng, hay vẫn là datagram và để thứ khác hấp thụ việc proxy.

Phương án A: biến đường hầm thành luồng

Việc này cần một máy chủ có trình lắng nghe TCP và một hồ sơ khách nêu tên proxy. Cả hai phần đều cần, và phía máy chủ là phần người ta quên:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

Thay dòng cuối bằng http-proxy proxy.internal 8080 khi proxy nói HTTP, và thêm tệp thông tin đăng nhập nếu nó yêu cầu. Proxy phải sẵn sàng thực hiện CONNECT tới cổng VPN của bạn, và máy chủ phải trả lời trên TCP; trình lắng nghe chỉ UDP sẽ bỏ qua nỗ lực đó. Chọn 443 là bước thực tế, vì nhiều mạng hạn chế chỉ cho phép nó và ít thứ khác.

Cái giá là TCP chồng lên TCP. Một phân đoạn bên ngoài bị mất sẽ chặn mọi luồng bên trong dùng chung kết nối đó, nên việc phục hồi thường độc lập trở thành chia sẻ. Việc thiết lập cũng lâu hơn, và một đường ra ngoài chập chờn trở thành đường hầm chập chờn thay vì chậm.

Phương án B: để đường hầm yên

Khi đường hầm phải ở lại UDP, đường hầm không phải nơi bạn cấu hình bất cứ thứ gì. Thay vào đó, TCP đi ra từ ứng dụng được chuyển hướng tới một trình lắng nghe SOCKS cục bộ, và ứng dụng không bao giờ biết có proxy. Trên Linux đó thường là redsocks cộng với một quy tắc NAT REDIRECT trong bảng nat.

Lại chỉ TCP. Một proxy chỉ HTTP như privoxy không thể chuyển các giao thức tùy ý, và thiết kế này cũng không thêm hỗ trợ datagram cho ứng dụng.

Nói trực tiếp với từng ứng dụng về proxy thường tốt hơn ở nơi phần mềm hỗ trợ. Dễ kiểm toán hơn, và nó hỏng ở chỗ bạn thực sự nhìn thấy.

Mỗi phương án hỏng ở đâu

Phương án A hỏng khi máy chủ thiếu trình lắng nghe TCP, khi proxy từ chối mục tiêu CONNECT, hoặc khi luồng bên ngoài bị bóp dưới mức đường hầm cần. Hai trường hợp đầu để lại một mục trong nhật ký proxy; trường hợp thứ ba để lại một kết nối được thiết lập rồi có cảm giác sai. Đọc nhật ký đó trước khi sửa hồ sơ, vì nó tách vấn đề quyền khỏi vấn đề dung lượng. Một CONNECT hoàn tất chuyển việc điều tra vào bên trong đường hầm.

Phương án B hỏng với mọi thứ cần datagram, với các giao thức mà proxy không hiểu, và âm thầm trên các máy chủ nơi quy tắc chuyển hướng tồn tại nhưng việc định tuyến lại gửi lưu lượng đi vòng qua nó.

Không phương án nào thay đổi yêu cầu về thiết bị. Các gói vẫn cần một nút TUN hoặc TAP trước khi nhân định tuyến chúng, nên tiến trình vẫn cần quyền trên /dev/net/tun. Một lớp bọc thay đổi điều xảy ra sau khi nút đó mở, không phải việc bạn có cần nó hay không.

Chứng minh bạn đã xây con đường nào

Hãy nhìn các socket thay vì biểu tượng khay. Tiến trình VPN phải giữ một kết nối đã thiết lập tới địa chỉ proxy, và proxy phải đã ghi lại mục tiêu được yêu cầu tới:

ss -tnp | grep openvpn

Sau đó nhắm tới một đích chỉ đường hầm mới phục vụ được, và một tên chỉ trình phân giải của đường hầm mới trả lời được. Một kết nối proxy hoàn tất với đường hầm đã chết thường có nghĩa là đầu xa chưa bao giờ cung cấp transport được nêu trong hồ sơ của bạn.

Ghi lại transport và proxy chấp nhận ở một nơi lâu bền. Khi cùng hồ sơ đó hỏng trên mạng khác, ghi chú ấy loại trừ hoặc xác nhận proxy trong vài giây.