Proxy SOCKS qua SSH trên Android: vì sao chỉ một nửa ứng dụng của bạn kết nối

Bạn đăng nhập qua SSH, thêm -D 1080 và lệnh thành công. Giờ đã có một trình lắng nghe SOCKS trên điện thoại, và một nửa ứng dụng vẫn đi ra qua dữ liệu di động. Đó là kết quả bình thường, không phải đường hầm hỏng: ssh -D tạo một điểm cuối proxy, và ứng dụng Android chỉ dùng proxy nếu có gì đó buộc chúng. Đi qua chuỗi từng bước cho thấy mỗi phần của công việc thực sự nằm ở đâu.

Bắt đầu từ nơi lưu lượng bắt đầu

Chọn một ứng dụng lẽ ra phải dùng đường hầm và kiểm tra xem nó có thiết lập proxy riêng không. Trình duyệt có trường SOCKS là trường hợp dễ: trỏ nó tới 127.0.0.1:1080, bật DNS từ xa nếu thiết lập đó tồn tại, và yêu cầu đi qua. Một ứng dụng chat, ứng dụng bản đồ hay trò chơi không có trường đó không có cách nào dùng trình lắng nghe, và không gì bạn gõ vào lệnh SSH thay đổi được điều đó.

Trước khi liên quan tới bất cứ thứ gì khác, hãy chứng minh trình lắng nghe hoạt động từ chính shell của điện thoại với một ứng dụng khách nói SOCKS trực tiếp:

ssh -N -D 1080 [email protected]
curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me

Địa chỉ trả về phải là của máy chủ SSH, không phải của điện thoại. Nếu đúng, nửa proxy đã xong và phần còn lại là về độ phủ. Nếu không, hãy sửa phía SSH trước: xác thực bằng khóa, khả năng máy chủ tới được đích và lối ra của chính máy chủ SSH.

Thêm phần mà Android cần

Ứng dụng không có thiết lập proxy cần thứ gì đó bắt gói tin của chúng và biến chúng thành kết nối proxy. Trên thiết bị không root, đó là một bộ chuyển đổi dịch vụ VPN: ứng dụng nhận giao diện ảo và chuyển lưu lượng đã chọn tới trình lắng nghe SOCKS cục bộ. Chuỗi trở thành ứng dụng, bộ chuyển đổi, trình lắng nghe SOCKS, kết nối SSH, đích.

Cài bộ chuyển đổi, cấp quyền VPN và chọn các ứng dụng hoặc tuyến nó phải bắt. Biểu tượng chìa khóa trên thanh trạng thái khi đó đại diện cho bộ chuyển đổi, không phải một VPN thương mại riêng. Android chỉ cho phép một kết nối dịch vụ VPN hoạt động cho mỗi hồ sơ người dùng, nên khởi chạy ứng dụng VPN thứ hai không thêm một lớp vào chuỗi: nó cạnh tranh cho cùng vai trò.

Đây cũng là bước mà một thử nghiệm thành công có thể đánh lừa bạn. Nếu bộ chuyển đổi chỉ được đặt để bắt trình duyệt bạn đã trỏ tới proxy, mọi thứ hoạt động và không gì khác được phủ. Đọc danh sách bắt trước khi kết luận thiết bị đang trong đường hầm.

Giữ vận chuyển SSH ngoài việc bắt

Bản thân kết nối SSH không được đưa trở lại đường hầm SOCKS mà nó duy trì. Nếu bộ chuyển đổi bắt lưu lượng của ứng dụng SSH, đường hầm phụ thuộc vào một kết nối đang chờ đường hầm, và kết quả là một vòng lặp kẹt hoặc thất bại ngay khi bộ chuyển đổi khởi động.

Các triển khai tích hợp bảo vệ socket vận chuyển của riêng chúng. Với các ứng dụng riêng, bạn cần một ngoại lệ được hỗ trợ: để ứng dụng SSH ngoài việc bắt, hoặc loại trừ điểm cuối SSH theo địa chỉ. Cả hai đều có giá. Loại trừ toàn bộ ứng dụng terminal cũng bỏ hoạt động mạng không liên quan của nó khỏi đường hầm, và ngoại lệ địa chỉ sẽ hỏng khi địa chỉ máy chủ thay đổi hoặc khi tên được phân giải khác ở kết nối tiếp theo.

Kiểm tra ngoại lệ từ bên ngoài: kết nối lại bộ chuyển đổi, sau đó xác nhận phiên SSH sống sót và yêu cầu qua proxy vẫn báo địa chỉ máy chủ. Một phiên hoạt động cho đến khi bộ chuyển đổi khởi động rồi đóng băng chính là vòng lặp đó.

Theo DNS và UDP đến cuối chuỗi

Chuyển tiếp động của OpenSSH mang các kết nối TCP. Nó không phải vận chuyển UDP-associate hay ICMP, và bộ chuyển đổi không thể tạo ra chuyển tiếp UDP bằng cách nhận gói UDP. Bất cứ thứ gì khăng khăng dùng UDP, gồm QUIC và phương tiện WebRTC, sẽ thất bại hoặc rơi về TCP tùy ứng dụng.

DNS cần quyết định riêng. Ứng dụng phân giải tên cục bộ sẽ gửi truy vấn qua trình phân giải thông thường trước khi kết nối, nên đường hầm mang kết nối nhưng không mang việc tra cứu. Một ứng dụng khách hiểu proxy có tùy chọn DNS từ xa tránh được điều đó; ứng dụng bị bắt mà không có tùy chọn đó thì không. Kiểm tra trình phân giải nào đã trả lời thay vì cho rằng bộ chuyển đổi đã thay đổi nó.

Giữ trình lắng nghe SOCKS gắn với loopback, xác minh khóa máy chủ của máy chủ SSH trong lần dùng đầu tiên, và để việc xác thực HTTPS bình thường tại chỗ cho trang cuối. SSH bảo vệ đoạn từ điện thoại đến máy chủ; nó không mã hóa những gì máy chủ làm sau đó.

Kiểm tra hai vòng đời và quyết định

Bộ chuyển đổi và phiên SSH có vòng đời riêng. Nếu SSH sập trong khi bộ chuyển đổi vẫn tiếp tục bắt, ứng dụng có thể treo mà không có lỗi rõ ràng, vì gói tin của chúng vẫn đi vào một giao diện ảo không còn lối ra hoạt động. Nếu bộ chuyển đổi dừng, ứng dụng hoặc đi trực tiếp hoặc bị chặn, tùy chính sách VPN của thiết bị.

Cố ý thử cả hai chiều: giết phiên SSH khi bộ chuyển đổi đang chạy, sau đó dừng bộ chuyển đổi khi SSH vẫn hoạt động. Điều điện thoại làm trong mỗi trường hợp chính là chính sách bạn thực sự triển khai, bất kể hướng dẫn cài đặt nói gì.

Nếu quy trình làm việc cần độ phủ toàn thiết bị với chế độ thất bại có thể dự đoán, một VPN IP thật, hoặc một bộ chuyển đổi được duy trì thiết kế cho chuỗi này, là câu trả lời trung thực. Một phiên shell để chạy bên cạnh một ứng dụng bắt không liên quan không phải đường hầm thiết bị được duy trì; đó là hai thành phần không có thỏa thuận về điều gì xảy ra khi một trong hai kết thúc.