Trình giả lập Android và VPN trên máy chủ: ảnh chụp DNS và NAT

Khi trình giả lập không truy cập được một máy chủ build mà trình duyệt trên máy chủ vẫn mở bình thường, câu hỏi hữu ích không phải là VPN có hoạt động hay không. Câu hỏi là guest thiếu cơ chế nào trong hai cơ chế. Thiết bị ảo chạy ngăn xếp mạng riêng của nó phía sau NAT của trình giả lập, và danh sách resolver của nó là bản sao được chụp lúc khởi động, nên một tunnel đến sau sẽ thay đổi đường đi của máy chủ mà không thay đổi thứ guest hỏi. Hiểu hai lớp này giải thích gần như mọi biến thể của vấn đề này.

Guest là một ngăn xếp riêng sau NAT cố định

Mạng chế độ người dùng của QEMU đặt guest tại 10.0.2.15 với gateway tại 10.0.2.2, và dịch vụ DNS tại 10.0.2.3 đến 10.0.2.6. Lưu lượng đi ra của guest không được kernel máy chủ chuyển tiếp; nó được dịch thành socket phía máy chủ, một socket cho mỗi kết nối của guest, và những socket đó đi ra từ không gian địa chỉ của máy chủ. Đó là lý do một kết nối của guest thừa hưởng quyết định định tuyến của máy chủ ngay khi được tạo, và cũng là lý do guest không có mục nào trong bảng định tuyến nêu tên tunnel của bạn.

Cùng cơ chế đó cho guest một lối ra hữu ích. 10.0.2.2 là bí danh của giao diện loopback trên máy chủ, nên một dịch vụ đang lắng nghe trên 127.0.0.1 ở laptop có thể truy cập từ guest tại địa chỉ đó. Mọi thứ client chỉ công bố trên loopback đều truy cập được theo cách này, và đây là cơ sở của bố cục proxy được mô tả bên dưới.

Điều guest không thể làm là quan sát mạng của máy chủ như thể đó là namespace của nó. Không có bridge, không có bảng định tuyến dùng chung và không có resolver thừa kế; chỉ có dịch vụ NAT nhận các gói của nó và ảnh chụp mà trình khởi chạy đã lấy khi thiết bị ảo khởi động.

DNS là ảnh chụp, không phải khung nhìn trực tiếp

Khi khởi động, trình giả lập đọc danh sách resolver của máy chủ và cấp cho guest tối đa bốn máy chủ, được công bố tại các địa chỉ 10.0.2.3 đến 10.0.2.6. Nếu tunnel đang xuống vào lúc đó, ảnh chụp chứa resolver công cộng mà laptop đang dùng, và guest tiếp tục hỏi nó suốt đời. Tên công cộng phân giải được, tên nội bộ thất bại, và mọi triệu chứng đều chỉ về VPN trong khi giá trị thực sự cũ là một danh sách resolver được chụp vài phút trước khi tunnel lên.

Vì vậy việc sửa thứ tự không phải là chuyện dân gian. Kết nối tunnel trước, sau đó khởi động lại trình giả lập, và ưu tiên khởi động nguội hơn là khôi phục ảnh chụp, vì ảnh quick-boot có thể trở lại với trạng thái resolver và định tuyến đã lưu trước đó. Nếu cần xem guest đang dùng gì, hãy hỏi thiết bị chứ không phải máy chủ:

adb shell dumpsys connectivity | grep -i -A2 dns
adb shell ping -c 1 build.internal.example

Trình giả lập cũng nhận một resolver chỉ định khi khởi chạy, hữu ích khi bạn biết chính xác máy chủ nào guest nên dùng và nguy hiểm khi máy chủ đó là công cộng:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Resolver công cộng không có bản sao của vùng nội bộ, nên ghim một cái biến vấn đề thứ tự thành lỗi vĩnh viễn. Nếu profile đẩy DNS riêng, hãy để tunnel cung cấp nó và khởi động nguội guest thay vì mã hóa cứng địa chỉ.

Định tuyến theo máy chủ tại thời điểm kết nối

Vì kết nối của guest trở thành socket của máy chủ, quyết định định tuyến được đưa ra khi socket được tạo. Tunnel lên trước yêu cầu nghĩa là yêu cầu đi ra qua tunnel, tuân theo các route của profile. Một profile split-tunnel chỉ mang theo các prefix được chọn sẽ sẵn lòng để subnet riêng của bạn ở ngoài, nên khả năng đến được máy chủ là một giả thuyết về guest, không phải kết quả. Các kết nối hiện có của guest giữ nguyên đường đi lúc được tạo, đó là lý do client kết nối lại không phải lúc nào cũng sửa được bản tải xuống bị kẹt trong trình giả lập.

Việc kiểm chứng thuộc về giao diện của máy chủ, không phải số liệu của guest:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Nếu yêu cầu của guest xuất hiện trên giao diện tunnel, định tuyến đang hoạt động và vấn đề nằm ở phía trên. Nếu nó xuất hiện trên giao diện vật lý, profile không bao phủ prefix đó, và không cấu hình lại nào phía guest thay đổi được điều đó.

Khi client chỉ cung cấp proxy loopback

Một số client thương mại hoàn toàn không tạo tunnel hệ thống. Chúng công bố một listener HTTP hoặc SOCKS trên 127.0.0.1 và mong các ứng dụng dùng nó. Guest không thấy socket đó trực tiếp, nhưng có thể bảo trình giả lập dùng nó, hoặc qua các điều khiển mở rộng (Settings, rồi Proxy, chế độ thủ công, máy chủ 127.0.0.1 và cổng mà client in ra) hoặc khi khởi chạy:

emulator -avd Pixel_API_34 -http-proxy http://127.0.0.1:8080

Sao chép cổng từ cửa sổ client; một cổng đoán mò sẽ thất bại âm thầm và trông như tunnel hỏng. Hãy nhớ điều này bao gồm gì: cài đặt proxy HTTP được các ứng dụng hiểu proxy tôn trọng, còn socket thô bỏ qua hoàn toàn. Nếu khối lượng công việc là một binary native tự mở kết nối, đường proxy không tương đương với tunnel và việc so sánh phải được thực hiện rõ ràng.

Chứng minh kết quả từ bên trong guest

Tách việc phân giải khỏi định tuyến bằng hai phép thử trong cùng một phiên. Một tên thất bại trong khi địa chỉ số vẫn trả lời là vấn đề ảnh chụp DNS, và cách sửa là thứ tự hoặc một resolver chỉ định. Nếu cả hai đều thất bại, điều đó chỉ ra định tuyến hoặc chính sách, và bước kiểm tra tiếp theo là ứng dụng có chạy trong work profile với các hạn chế mạng riêng hay không.

Cuối cùng, hãy biết bạn đang kiểm thử trên guest nào. Các ảnh trình giả lập rất cũ được phát hành mà không có hỗ trợ tun mà một client VPN phía guest cần, nên không profile nào có thể hoạt động ở đó; các ảnh hiện tại có hỗ trợ đó. Một client thất bại trên ảnh hiện tại là vấn đề của client hoặc profile, và việc dựng lại tunnel của máy chủ sẽ không thay đổi kết quả.