ADB en die Android-emulator misluk agter ’n VPN: drie roetes

Jy koppel die kantoor-VPN en Android Studio verloor die lopende emulator, adb start-server hang, en ’n fisiese selfoon op Wi-Fi val van die toestellys af. Dit lyk of een produk deur een tonnel geblokkeer word. In die praktyk misluk drie afsonderlike roetes op drie verskillende maniere: adb-toestelontdekking, die emulator se virtuele netwerk en die gasheer-resolver. Die tonnel besit gewoonlik net die laaste een, en dikwels net ’n deel daarvan.

Drie sokkels, drie eienaars

Die adb-bediener luister op poort 5037 op die gasheer en praat met toestelle oor USB of TCP, met mDNS vir netwerkontdekking. Die emulator loop agter sy eie virtuele router: die gas is 10.0.2.15, die deurgang is 10.0.2.2 en die DNS-bediener is 10.0.2.3, alles deur die emulatorproses na gasheersokkels vertaal. Die gasheer-resolver is waar ’n VPN-kliënt DNS en soekdomeine installeer.

Daardie skeiding verduidelik waarom n regstelling vir een stuk gereedskap werk en nie vir ’n ander nie. ’n Kliënt wat die gasheer-resolver verander, laat ’n lopende emulatorproses met die resolvertoestand wat dit by die opstart gelees het. ’n Kliënt wat multicast filtreer, breek ontdekking sonder om DNS aan te raak. ’n Kliënt wat virtuele adapters filtreer, weier die emulator terwyl die gasheer se blaaier bly werk. Elke simptoom het ’n ander oorsaak, so identifiseer die falende roete voordat jy enige instelling verander.

Begin met wat adb kan sien

Voer adb devices uit voordat jy aan die VPN raak. ’n Leë lys is ’n vervoerprobleem, nie ’n roeteringsprobleem nie, en geen tonnelinstelling sal ’n toestel regmaak wat die bediener nooit gelys het nie. Herbegin die bediener skoon met adb kill-server en dan adb start-server, en lees die uitset vir die poort wat dit gebind het. As die opstart self hang, is mDNS-ontdekking die gewone verdagte op ’n netwerk wat multicast filtreer; die gedokumenteerde oplossing is om die bediener met ontdekking gedeaktiveer te begin:

ADB_MDNS_OPENSCREEN=0 adb start-server
adb devices

Vir ’n fisiese toestel is USB die kortste roete. As jy TCP nodig het, plaas die toestel in luistermodus met adb tcpip 5555 en koppel aan die toesteladres en toestelpoort, adb connect 192.0.2.10:5555. Poort 5037 is die gasheer se bedienerpoort en is nie die poort waarop ’n toestel luister nie.

Toets die emulator van binne

Die emulator antwoord DNS vanaf 10.0.2.3, en daardie resolver word deur die gasheerproses gevoed. Wanneer die VPN-kliënt die gasheer-resolver verander, kan die emulator dit erf; wanneer die kliënt die emulatorproses filtreer of die gasheer se adapterlys verander nadat die emulator begin het, kan dit nie. Skei die twee met ’n numeriese teiken en ’n naam uit dieselfde skulp. adb shell ping -c 2 10.0.2.2 bewys dat die virtuele netwerk die gasheerkant kan bereik. ’n Naamsoektog daarna vertel jou of die resolusie die grens oorgesteek het.

Voer dan dieselfde naamsoektog op die gasheer uit. Gasheer los op en emulator nie, beteken die breuk is tussen die gasheer-resolver en die emulator se virtuele netwerk, nie in die tonnel self nie. Albei misluk beteken die gasheer-resolver is die plek om te kyk. Om die emulator te herbegin nadat die VPN koppel, is een poging werd, want sommige kliënte installeer resolvertoestand wat ’n lopende emulatorproses nooit optel nie.

Kontroleer die gasheer-resolver en kliëntfilters

’n Voltonnel-kliënt vervang die gasheer-resolver met sy eie, en ’n split-DNS-kliënt voeg soekdomeine en voorwaardelike doorstuurders by. Interne name hang dikwels van daardie split-DNS-opstelling af, so kyk wat die gasheer gebruik terwyl jy gekoppel is: die resolveradres, die soekdomein en of die interne sone na die korporatiewe DNS gestuur word. ’n Resolver wat publieke name antwoord maar nie interne name nie, is ’n beleidskwessie, nie ’n stukkende tonnel nie.

Sommige korporatiewe kliënte blokkeer ook verkeer van virtuele adapters. ’n Emulator lyk soos ’n virtuele adapter vir ’n filterdrywer, so die gasheer kan volmaak werk terwyl die emulator deur beleid geweier word. Daardie beleid is nie van die werkstasie af sigbaar nie, en om aan proxy-instellings te raai sal dit nie openbaar nie. As die gasheer oplos en die emulator steeds geblokkeer word ongeag resolverinstellings, is die regte eskalasie na die span wat die kliëntbeleid besit.

Volgorde van kontroles en wat elke resultaat beteken

Werk van bo na onder en stop by die eerste falende ry. Elke resultaat wys na ’n ander eienaar, en geen een word reggemaak deur Android Studio te herinstalleer nie.

Net die laaste twee rye is VPN-vrae in die gewone sin, en net die laaste een gaan oor DNS-inhoud. Die adb-dokumentasie dek die bedienerpoort en die omgewingsveranderlikes wat hier genoem word, genoeg om die vervoerkant eerlik te hou terwyl jy die res toets.