VPN na hoście czy klient w Genymotion: zdecyduj, kto posiada tunel

VPN na pulpicie wpływa na Genymotion w dwóch miejscach, a naprawa jednego niczego nie dowodzi o drugim. Pierwsze to połączenie, którego aplikacja desktopowa używa do sterowania urządzeniem wirtualnym; drugie to ścieżka wirtualnej aplikacji Android do prywatnej usługi. Zdecyduj, które z nich naprawdę zmieniasz, zanim dotkniesz adaptera, a następnie zapisz wersję Genymotion Desktop, system operacyjny hosta i hiperwizor, ponieważ wskazówki napisane dla adaptera host-only VirtualBox nie przenoszą się na urządzenie QEMU ani na sesję hostowaną w chmurze.

Dwie ścieżki na jednej maszynie

Ścieżka sterowania biegnie od aplikacji desktopowej Genymotion do urządzenia wirtualnego, często przez sieć host-only. Ścieżka aplikacji biegnie od wnętrza Androida na zewnątrz, do tego, z czym aplikacja rozmawia. VPN na hoście może nieść drugą i złamać pierwszą, dlatego działająca przeglądarka na pulpicie dowodzi bardzo niewiele. Jeden tunel może obsłużyć obie ścieżki albo tylko jedną, a taki układ jest decyzją, nie przypadkiem.

Zapisz, którą ścieżkę diagnozujesz. Większość traconych godzin w tej dziedzinie bierze się ze zmiany DNS prywatnej aplikacji, gdy urządzenie nigdy nie wystartowało, albo z poluzowania VPN na hoście, gdy aplikacja miała po prostu zły resolver.

Utrzymaj łącze sterujące przy życiu

Własna notatka pomocy Genymotion Desktop dokumentuje przypadek VirtualBox: gdy VPN na hoście jest aktywny, Desktop nie widzi już urządzenia wirtualnego, a wyjątkiem, który ma znaczenie, jest prawdziwy adapter host-only wymieniony w menedżerze sieci VirtualBox. Wypisz te adaptery zamiast zgadywać zakres:

VBoxManage list hostonlyifs

Domyślny zakres wydrukowany w dokumentacji nie jest wymówką do całkowitego omijania sieci prywatnej na każdej maszynie. Dodaj najmniejszy wyjątek obejmujący używany adapter i uzyskaj zgodę administratora VPN, ponieważ zarządzany klient może celowo blokować sieć lokalną. Zapisz wyjątek z nazwą adaptera i datą zatwierdzenia. Pół roku później ta notatka jest jedyną rzeczą, która wyjaśnia, dlaczego reguła istnieje.

Ta sama notatka mówi, że kombinacja z QEMU nie została przetestowana z VPN. Traktuj to jako ograniczenie zgodności, a nie jako podpowiedź, że przejście na sieć bridged to naprawi; zmiana adaptera zmienia awarię, ale nie rozwiązuje nieprzetestowanej kombinacji.

Opcja A: pozwól hostowi nieść ruch

Przy tym wyborze pakiety gościa muszą dotrzeć do interfejsu, który VPN jednocześnie dopuszcza i szyfruje. To pytanie o routing, a nie o lampkę stanu: pakiety gościa muszą dotrzeć do interfejsu, który VPN zaszyfruje, a odpowiedzi muszą znaleźć drogę powrotną.

Przeglądarka na hoście dowodzi ścieżki hosta i niczego o tym, czy źródło z urządzenia wirtualnego jest akceptowane. Niektóre klienty VPN traktują ruch przekazywany lub tłumaczony inaczej niż ruch wytworzony lokalnie, więc testuj od wewnątrz Androida, zanim uznasz, że tunel działa. Także resolver Androida nie jest resolverem hosta. Jeśli nazwy rozwiązują się na pulpicie, a w aplikacji zawodzą, przeczytaj konfigurację resolvera gościa, zanim dotkniesz profilu VPN.

Opcja B: uruchom obsługiwanego klienta w Androidzie

Tutaj gość trzyma własny profil, dane logowania, trasy i politykę resolvera. Zwykłe interfejsy VPN Androida nie wymagają dostępu root, więc standardowy klient instaluje się i łączy wewnątrz urządzenia wirtualnego. Zatwierdzenie to ta część, którą ludzie pomijają. Organizacja musi pozwolić na tego klienta i to środowisko urządzenia wirtualnego, a czysty import sam w sobie nie spełnia kontroli rejestracji urządzenia ani stanu. Zapytaj, zanim zbudujesz wokół tego przepływ pracy.

Oba wybory mogą się też nakładać: tunel w Androidzie może dotrzeć do swojego serwera przez tunel już działający na hoście. Taki układ wymaga osiągalnego punktu końcowego i przekazywania, na które naprawdę zezwoliłeś, a nie dwóch zielonych świateł, które przypadkiem świecą się razem.

Sprawdź z aplikacji i zapisz układ

Używaj tej samej aplikacji Android w każdym teście i czytaj, co raportuje: czy adres odpowiada, czy nazwa prywatna się rozwiązuje i co aplikacja zwraca. Trzy obserwacje oddzielają awarię routingu od awarii resolvera i od odrzucenia przez politykę.

Gdy urządzenie nie startuje albo Desktop je traci, traktuj to jako usterkę ścieżki sterowania, a nie usterkę DNS. Ten objaw należy do pierwszej ścieżki, a poprawka jest na hoście, nie w Androidzie. Zakończ, zapisując cztery fakty: wersja Genymotion Desktop, hiperwizor, która strona posiada tunel i dokładny wyjątek host-only, jeśli jakiś dodano. Wybierz udokumentowany układ, który właściciel sieci wspiera, i nie traktuj wyłączania firmowego VPN ani osłabiania kontroli stanu jako neutralnego rozwiązywania problemów, gdy prywatna usługa na nich polega.