ADB și emulatorul Android eșuează în spatele unui VPN: trei căi

Vă conectați la VPN-ul biroului și Android Studio pierde emulatorul care rulează, adb start-server se blochează, iar un telefon fizic în Wi-Fi dispare din lista de dispozitive. Pare că un singur tunel blochează un singur produs. În practică eșuează trei căi separate în trei moduri: descoperirea dispozitivelor prin adb, rețeaua virtuală a emulatorului și resolverul gazdei. Tunelul deține de obicei doar ultima, și adesea doar o parte din ea.

Trei socketuri, trei proprietari

Serverul adb ascultă pe portul 5037 al gazdei și vorbește cu dispozitivele prin USB sau TCP, cu mDNS pentru descoperirea în rețea. Emulatorul rulează în spatele propriului router virtual: oaspetele este 10.0.2.15, gateway-ul este 10.0.2.2, iar serverul DNS este 10.0.2.3, iar procesul emulatorului traduce totul în socketuri ale gazdei. Resolverul gazdei este locul unde clientul VPN instalează DNS-ul și domeniile de căutare.

Această separare explică de ce o corecție pare să funcționeze pentru un instrument și nu pentru altul. Un client care schimbă resolverul gazdei lasă procesul emulatorului cu starea resolverului citită la pornire. Un client care filtrează multicast strică descoperirea fără să atingă DNS-ul. Un client care filtrează adaptoare virtuale refuză emulatorul în timp ce browserul gazdei continuă să funcționeze. Fiecare simptom are altă cauză, așa că identificați calea care eșuează înainte de a schimba vreo setare.

Începeți cu ce vede adb

Rulați adb devices înainte de a atinge VPN-ul. O listă goală este o problemă de transport, nu de rutare, și nicio setare a tunelului nu va repara un dispozitiv pe care serverul nu l-a enumerat niciodată. Reporniți serverul curat: mai întâi adb kill-server apoi adb start-server, și citiți ieșirea pentru a vedea ce port a ocupat. Dacă pornirea însăși se blochează, descoperirea mDNS este suspectul obișnuit într-o rețea care filtrează multicast; soluția documentată este pornirea serverului cu descoperirea dezactivată:

ADB_MDNS_OPENSCREEN=0 adb start-server
adb devices

Pentru un dispozitiv fizic, USB este cea mai scurtă cale. Dacă aveți nevoie de TCP, puneți dispozitivul în modul de ascultare cu adb tcpip 5555 și conectați-vă la adresa și portul dispozitivului, adb connect 192.0.2.10:5555. Portul 5037 este portul serverului gazdei, nu portul pe care ascultă un dispozitiv.

Testați emulatorul din interior

Emulatorul răspunde la DNS din 10.0.2.3, iar acel resolver este alimentat de procesul gazdei. Când clientul VPN schimbă resolverul gazdei, emulatorul îl poate moșteni; când clientul filtrează procesul emulatorului sau lista de adaptoare se schimbă după pornire, nu poate. Separați cele două cu o țintă numerică și un nume din același shell. adb shell ping -c 2 10.0.2.2 demonstrează că rețeaua virtuală ajunge la partea gazdei. O căutare de nume după aceea arată dacă rezoluția a trecut granița.

Apoi rulați aceeași căutare de nume pe gazdă. Gazda rezolvă și emulatorul nu înseamnă că ruptura este între resolverul gazdei și rețeaua virtuală a emulatorului, nu în tunel. Ambele eșuează înseamnă că resolverul gazdei este locul de privit. Repornirea emulatorului după conectarea VPN merită o încercare, pentru că unii clienți instalează o stare a resolverului pe care un proces de emulator în rulare nu o preia.

Verificați resolverul gazdei și filtrele clientului

Un client cu tunel complet înlocuiește resolverul gazdei cu al său, iar un client split-DNS adaugă domenii de căutare și redirectoare condiționate. Numele interne depind adesea de acea configurație split-DNS, așa că uitați-vă ce folosește gazda cât timp sunteți conectat: adresa resolverului, domeniul de căutare și dacă zona internă este rutată către DNS-ul corporativ. Un resolver care răspunde la nume publice dar nu la cele interne este o chestiune de politică, nu un tunel stricat.

Unele clienți corporativi blochează și traficul de la adaptoare virtuale. Pentru un driver de filtrare, emulatorul arată ca un adaptor virtual, așa că gazda poate funcționa perfect în timp ce politica refuză emulatorul. Acea politică nu este vizibilă de la stația de lucru, iar ghicirea setărilor de proxy nu o va dezvălui. Dacă gazda rezolvă și emulatorul rămâne blocat indiferent de setări, escaladarea corectă este la echipa care deține politica clientului.

Ordinea verificărilor și ce înseamnă fiecare rezultat

Lucrați de sus în jos și opriți-vă la primul rând care eșuează. Fiecare rezultat indică un alt proprietar, iar niciunul nu se rezolvă reinstalând Android Studio.

Doar ultimele două rânduri sunt întrebări de VPN în sensul obișnuit, și doar ultimul despre conținutul DNS. Documentația adb acoperă portul serverului și variabilele de mediu menționate aici, suficient pentru a păstra onestă partea de transport în timp ce testați restul.