Tethering ngược cho Android qua USB: lệnh, kiểm tra, hoàn tác
Tethering ngược gửi lưu lượng của điện thoại qua một bộ chuyển tiếp trên máy chủ. Dựng đường đi từ điện thoại đến máy chủ, giữ VPN của máy chủ trong vòng lặp và kiểm tra từng chặng.
Tethering ngược chuyển lưu lượng của điện thoại sang một máy tính và đưa ra ngoài qua kết nối của máy tính đó. Chỉ một sợi cáp USB thì không làm được: điện thoại cần một dịch vụ bắt giữ đảm nhận việc định tuyến, còn máy tính cần một bộ chuyển tiếp mang các gói tin đó đi tiếp. Đường đi có bốn chặng: ứng dụng, bắt giữ trên điện thoại, bộ chuyển tiếp USB và lối ra của máy chủ, và mỗi chặng có một chủ khác nhau. Cuốn sổ tay này dựng đường đi đó, đặt VPN của máy chủ đúng chỗ và kiểm tra từng chặng trước khi bạn tin vào kết quả.
Lập bản đồ các chặng trước khi chạy bất cứ thứ gì
Mỗi chặng áp dụng chính sách riêng, vì thế một kết quả chạy được ở đầu này không nói gì về đầu kia. Ứng dụng chọn đích và bộ phân giải, dịch vụ bắt giữ quyết định lưu lượng nào đi vào bộ chuyển tiếp, bộ chuyển tiếp chuyển vào các socket của máy chủ, còn định tuyến và VPN của máy chủ quyết định địa chỉ mà đích cuối cùng nhìn thấy.
| Hop | Owner | What it decides |
|---|---|---|
| Application request | The app | Destination, resolver, address family |
| Capture service | Phone VpnService app | Which traffic enters the relay at all |
| ADB relay | Host process | Forwarding phone flows to host sockets |
| Host egress | Host routing and VPN | Exit address and host policy |
Chỉ một ứng dụng khách của dịch vụ VPN có thể giữ vai trò bắt giữ của điện thoại tại một thời điểm, nên ứng dụng VPN thông thường thứ hai không chồng lên bộ chuyển tiếp. Nếu VPN thuộc về máy tính, dịch vụ bắt giữ là mắt nối truy cập về phía máy tính đó, không phải bằng chứng rằng một đường hầm từ xa đã bảo vệ kết quả.
Chuẩn bị bộ chuyển tiếp trước khi chạm vào điện thoại
Gnirehtet là ví dụ được ghi chép về kiến trúc này: một ứng dụng khách của dịch vụ VPN không cần root trên điện thoại cùng một bộ chuyển tiếp được mang qua ADB trên máy chủ, hỗ trợ TCP và UDP trên IPv4. Kho lưu trữ của nó cũng nêu rằng dự án không còn được duy trì tích cực, vì thế hãy coi đó là thiết kế tham chiếu và công cụ đang chạy được cho phòng thí nghiệm, không phải sản phẩm được hỗ trợ để chuẩn hóa trên cả một đội thiết bị được quản lý.
adb devices
adb shell getprop ro.build.version.release
gnirehtet run
Chạy adb devices trước. Điện thoại chưa chấp nhận khóa gỡ lỗi của máy chủ sẽ được báo là chưa được ủy quyền, và bộ chuyển tiếp sẽ không kết nối cho đến khi lời nhắc trên thiết bị được chấp nhận. gnirehtet run cài đặt ứng dụng khách, khởi động bộ chuyển tiếp và kích hoạt bắt giữ; trên phiên bản tách các bước, hãy dùng các lệnh con install, relay và start đã được ghi chép thay thế.
Truy cập ADB là một quan hệ điều khiển thiết bị, không phải thiết lập mạng. Chỉ ủy quyền cho máy tính mà bạn kiểm soát, và lên kế hoạch thu hồi ủy quyền đó khi xong việc.
Đưa VPN của máy chủ trở lại đường đi
Bộ chuyển tiếp là một tiến trình thông thường trên máy chủ, nên các kết nối tiếp theo của nó tuân theo bảng định tuyến của máy chủ. Hồ sơ đường hầm đầy đủ mang chúng đi; đường hầm chia tách có thể không. Nếu VPN của máy chủ dùng điều khiển theo từng ứng dụng, hãy thêm tệp nhị phân của bộ chuyển tiếp vào tập được phép, nếu không bộ chuyển tiếp sẽ tiếp tục dùng giao diện vật lý trong khi trình duyệt trông như được bảo vệ.
ip route get 1.1.1.1
curl -4 https://ifconfig.me
sudo ss -tnp | grep -i relay
Chạy hai lệnh đầu trước và sau khi kết nối VPN của máy chủ. Nếu địa chỉ không đổi, bộ chuyển tiếp không nằm trên đường hầm, bất kể cửa sổ ứng dụng khách nói gì. Đường hầm chỉ dành cho mạng riêng cũng để các đích công cộng đi qua lối ra bình thường của máy chủ, trông như rò rỉ nhưng đó là chính sách bạn đã đặt.
DNS được phân giải trên máy chủ cho lưu lượng đi qua bộ chuyển tiếp, nên bộ phân giải của máy chủ quyết định máy chủ nào nhìn thấy các tên. Thiết lập DNS riêng trên điện thoại không đi qua bộ chuyển tiếp, và bài kiểm tra bộ phân giải phía điện thoại sẽ không mô tả các truy vấn của máy chủ.
Kiểm tra từng chặng riêng rẽ
Ba lần kiểm tra, theo thứ tự này: điện thoại đến được bộ chuyển tiếp, bộ chuyển tiếp đến được đích theo chính sách của máy chủ, và ứng dụng phân giải và dùng đúng đích đó. Dừng ở lần hỏng đầu tiên thay vì tải lại trang và đoán.
adb shell dumpsys connectivity | grep -i -A3 vpn
adb logcat -s GnirehtetRelay:V Gnirehtet:V
Một mục mạng VPN trong bản kết xuất kết nối cho thấy dịch vụ bắt giữ đang hoạt động; nhật ký của chính bộ chuyển tiếp cho thấy các luồng có đến hay không. Thiếu ở một trong hai sẽ tách vấn đề rạch ròi: không bắt giữ là phía điện thoại, không có luồng là phía máy chủ.
Một trình duyệt chạy được trên máy chủ chứng minh đường đi của trình duyệt trên máy chủ, không phải đường đi của tiến trình bộ chuyển tiếp. So sánh các địa chỉ mà mỗi bên báo cáo, và thử một tài nguyên riêng lẫn một trang công cộng, vì đường hầm chỉ dành cho mạng riêng có thể định tuyến một cái mà không định tuyến cái kia.
Tháo gỡ và chọn hành vi khi hỏng
Hoàn tác là một phần của sổ tay. Dừng và gỡ bộ chuyển tiếp, gỡ cài đặt ứng dụng khách bắt giữ, và thu hồi ủy quyền gỡ lỗi của máy chủ trong tùy chọn nhà phát triển của điện thoại khi xong việc.
gnirehtet stop
gnirehtet uninstall
adb kill-server
Quyết định điện thoại nên làm gì khi bộ chuyển tiếp biến mất. Nếu không có lựa chọn rõ ràng, nó có thể quay về dữ liệu di động và làm rò rỉ lưu lượng mà bạn đang cố định tuyến, vì thế hãy đặt hành vi chặn kết nối hoặc chính sách VPN một cách có chủ đích và thử việc tháo gỡ trước khi dựa vào nó.
Ghi lại máy chủ đã được ủy quyền, phiên bản bộ chuyển tiếp, chính sách đường hầm của máy chủ và các bước tháo gỡ. Chính bản ghi đó làm cho lần thiết lập tethering ngược tiếp theo có thể lặp lại thay vì thêm một buổi chiều khám phá lại.