VPN trên máy chủ hay ứng dụng khách bên trong Genymotion: quyết định bên nào sở hữu đường hầm

Một VPN trên máy tính ảnh hưởng tới Genymotion ở hai chỗ, và sửa chỗ này không chứng minh được gì về chỗ kia. Thứ nhất là kết nối mà ứng dụng trên máy tính dùng để điều khiển thiết bị ảo; thứ hai là đường đi của ứng dụng Android ảo tới một dịch vụ riêng. Hãy quyết định bạn thực sự đang thay đổi cái nào trước khi chạm vào bộ điều hợp, sau đó ghi lại phiên bản Genymotion Desktop, hệ điều hành máy chủ và trình ảo hóa, vì hướng dẫn viết cho bộ điều hợp host-only của VirtualBox không chuyển sang thiết bị QEMU hay phiên được lưu trữ trên đám mây.

Hai đường đi trên một máy

Đường điều khiển chạy từ ứng dụng Genymotion trên máy tính tới thiết bị ảo, thường qua một mạng host-only. Đường của ứng dụng chạy từ bên trong Android ra ngoài tới bất cứ thứ gì ứng dụng nói chuyện cùng. VPN trên máy chủ có thể chở đường thứ hai và làm đứt đường thứ nhất, vì thế một trình duyệt chạy được trên máy tính chứng minh rất ít. Một đường hầm có thể phục vụ cả hai đường hoặc chỉ một, và cách bố trí đó là một quyết định, không phải tình cờ.

Ghi lại bạn đang chẩn đoán đường nào. Phần lớn thời gian bị mất trong lĩnh vực này đến từ việc đổi DNS của ứng dụng riêng khi thiết bị chưa từng khởi động, hoặc nới lỏng VPN trên máy chủ khi ứng dụng chỉ đơn giản dùng sai bộ phân giải.

Giữ kết nối điều khiển sống

Ghi chú hỗ trợ Desktop của chính Genymotion ghi lại một trường hợp VirtualBox: khi VPN trên máy chủ bật lên, Desktop không còn thấy thiết bị ảo nữa, và ngoại lệ quan trọng là bộ điều hợp host-only thật được liệt kê trong trình quản lý mạng của VirtualBox. Hãy liệt kê các bộ điều hợp đó thay vì đoán một dải:

VBoxManage list hostonlyifs

Một dải mặc định in trong tài liệu không phải cái cớ để bỏ qua toàn bộ mạng riêng trên mọi máy. Chỉ thêm ngoại lệ nhỏ nhất bao trùm bộ điều hợp đang dùng, và xin quản trị viên VPN phê duyệt, vì một ứng dụng khách được quản lý có thể cố ý chặn mạng cục bộ. Ghi ngoại lệ kèm tên bộ điều hợp và ngày phê duyệt. Nửa năm sau, ghi chú đó là thứ duy nhất giải thích vì sao quy tắc tồn tại.

Cùng ghi chú đó nói rằng tổ hợp QEMU chưa được thử với VPN. Hãy coi đó là giới hạn tương thích chứ không phải gợi ý rằng chuyển sang mạng bridged sẽ sửa được; đổi bộ điều hợp làm đổi dạng lỗi, nhưng không giải quyết tổ hợp chưa thử.

Phương án A: để máy chủ chở lưu lượng

Với lựa chọn này, gói tin của khách phải tới một giao diện mà VPN vừa cho phép vừa mã hóa. Đây là câu hỏi định tuyến, không phải đèn trạng thái: gói tin của khách phải tới giao diện mà VPN sẽ mã hóa, và các phản hồi phải tìm được đường về.

Một trình duyệt trên máy chủ chứng minh đường đi của máy chủ và không nói gì về việc nguồn từ thiết bị ảo có được chấp nhận hay không. Một số ứng dụng khách VPN xử lý lưu lượng được chuyển tiếp hay biên dịch khác với lưu lượng sinh ra cục bộ, nên hãy thử từ bên trong Android trước khi kết luận đường hầm hoạt động. Bộ phân giải của Android cũng không phải bộ phân giải của máy chủ. Nếu tên phân giải được trên máy tính mà thất bại trong ứng dụng, hãy đọc cấu hình bộ phân giải của khách trước khi chạm vào hồ sơ VPN.

Phương án B: chạy một ứng dụng khách được hỗ trợ bên trong Android

Ở đây khách giữ hồ sơ, thông tin xác thực, tuyến và chính sách phân giải của riêng mình. Các giao diện VPN thông thường của Android không cần quyền root, nên một ứng dụng khách chuẩn được cài và kết nối bên trong thiết bị ảo. Phê duyệt là phần người ta bỏ qua. Tổ chức phải cho phép ứng dụng khách đó và môi trường thiết bị ảo đó, còn một lần nhập sạch tự nó không đáp ứng kiểm tra đăng ký thiết bị hay kiểm tra trạng thái. Hãy hỏi trước khi dựng quy trình quanh nó.

Hai lựa chọn cũng có thể xếp chồng: một đường hầm bên trong Android có thể tới máy chủ của nó qua đường hầm đã chạy trên máy chủ. Cách bố trí đó cần một điểm cuối tiếp cận được và việc chuyển tiếp mà bạn thực sự cho phép, không phải hai đèn xanh tình cờ cùng sáng.

Kiểm chứng từ ứng dụng và ghi lại cách bố trí

Dùng cùng một ứng dụng Android cho mọi lần thử và đọc những gì nó báo: địa chỉ có trả lời không, tên riêng có phân giải được không và ứng dụng trả về gì. Ba quan sát tách lỗi định tuyến khỏi lỗi bộ phân giải và khỏi việc bị chính sách từ chối.

Khi thiết bị không khởi động, hoặc Desktop mất nó, hãy coi đó là lỗi của đường điều khiển chứ không phải lỗi DNS. Triệu chứng đó thuộc về đường thứ nhất, và cách sửa nằm trên máy chủ, không phải bên trong Android. Kết thúc bằng việc ghi bốn dữ kiện: phiên bản Genymotion Desktop, trình ảo hóa, bên nào sở hữu đường hầm và ngoại lệ host-only chính xác nếu có thêm. Chọn một cách bố trí có tài liệu mà chủ mạng ủng hộ, và đừng coi việc tắt VPN doanh nghiệp hay làm yếu kiểm tra trạng thái là cách xử lý trung tính khi dịch vụ riêng dựa vào chúng.