Android emulators un resursdatora VPN: DNS momentuzņēmums un NAT

Kad emulators nevar sasniegt būvēšanas serveri, ko resursdatora pārlūks atver bez problēmām, noderīgais jautājums nav par to, vai VPN strādā. Jautājums ir, kura no diviem mehānismiem trūkst viesim. Virtuālā ierīce darbojas ar savu tīkla steku aiz emulatora NAT, un tās resolveru saraksts ir sāknēšanas brīdī paņemta kopija, tāpēc vēlāk paceltais tunelis maina resursdatora ceļu, bet nemaina to, ko jautā viesis. Šo divu slāņu izpratne izskaidro gandrīz visas šīs problēmas variācijas.

Viesis ir atsevišķa steks aiz fiksēta NAT

QEMU user-mode tīkls novieto viesi uz 10.0.2.15 ar vārteju 10.0.2.2 un DNS pakalpojumu no 10.0.2.3 līdz 10.0.2.6. Izejošā viesa plūsma netiek pārsūtīta ar resursdatora kodolu; tā tiek pārvērsta resursdatora puses ligzdās, pa vienai katram viesa savienojumam, un šīs ligzdas iziet no resursdatora adrešu telpas. Tāpēc viesa savienojums manto resursdatora maršrutēšanas lēmumu tapšanas brīdī, un tāpēc viesa maršrutu tabulā nav ieraksta, kas nosauc jūsu tuneli.

Tas pats mehānisms dod viesim noderīgu izeju. 10.0.2.2 ir resursdatora loopback saskarnes aizstājvārds, tāpēc pakalpojums, kas klausās 127.0.0.1 uz klēpjdatora, ir sasniedzams no viesa šajā adresē. Viss, ko klients atklāj tikai uz loopback, ir sasniedzams šādā veidā, un tas ir pamats tālāk aprakstītajai starpniekservera konfigurācijai.

Ko viesis nevar, ir novērot resursdatora tīklu tā, it kā tas būtu tā namespace. Nav bridge, nav kopīgas maršrutu tabulas un nav mantota resolvera; ir tikai NAT pakalpojums, kas pieņem tā paketes, un momentuzņēmums, ko palaidējs uzņēma, startējot virtuālo ierīci.

DNS ir momentuzņēmums, nevis dzīvs skats

Startējot emulators nolasa resursdatora resolveru sarakstu un dod viesim līdz četriem serveriem, kas atklāti adresēs no 10.0.2.3 līdz 10.0.2.6. Ja tunelis tajā brīdī bija izslēgts, momentuzņēmums satur to publisko resolveri, ko izmantoja klēpjdators, un viesis turpina to jautāt visu savu mūžu. Publiskie vārdi tiek atrisināti, iekšējie vārdi neizdodas, un visi simptomi norāda uz VPN, lai gan īstā novecojusī vērtība ir resolveru saraksts, kas fiksēts dažas minūtes pirms tuneļa pacelšanas.

Tāpēc secības labojums nav folklora. Vispirms pievienojiet tuneli, pēc tam restartējiet emulatoru, un dodiet priekšroku aukstai sāknēšanai, nevis momentuzņēmuma atjaunošanai, jo quick-boot attēls var atgriezties ar iepriekš saglabāto resolvera un maršrutu stāvokli. Ja jums jāredz, ko viesis pašlaik izmanto, jautājiet ierīcei, nevis resursdatoram:

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

Emulators startējot pieņem arī skaidru resolveri, kas ir noderīgi, ja precīzi zināt, kurš serveris viesim jāizmanto, un bīstami, ja šis serveris ir publisks:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Publiskam resolverim nav iekšējās zonas kopijas, tāpēc viena piespraušana pārvērš secības problēmu pastāvīgā kļūmē. Ja profils piespiež privāto DNS, ļaujiet tunelim to nodrošināt un auksti sāknējiet viesi, nevis iekodējiet adresi.

Maršrutēšana seko resursdatoram savienojuma brīdī

Tā kā viesa savienojumi kļūst par resursdatora ligzdām, maršrutēšanas lēmums tiek pieņemts, kad ligzda tiek izveidota. Tunelis pacelts pirms pieprasījuma nozīmē, ka pieprasījums iziet caur tuneli, ievērojot profila maršrutus. Split-tunnel profils, kas pārvadā tikai atlasītos prefiksus, labprāt atstās jūsu privāto apakštīklu ārpusē, tāpēc resursdatora sasniedzamība ir hipotēze par viesi, nevis rezultāts. Esošie viesa savienojumi saglabā ceļu, ar kuru tie tika izveidoti, tāpēc klientam atkārtoti pievienojoties, ne vienmēr tiek salabota emulatorā iestrēgusi lejupielāde.

Pārbaude pieder resursdatora saskarnei, nevis viesa statistikai:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Ja viesa pieprasījums parādās tuneļa saskarnē, maršrutēšana strādā un problēma ir virs tās. Ja tas parādās fiziskajā saskarnē, profils neaptver šo prefiksu, un nekāda viesa puses pārkonfigurēšana to nemainīs.

Kad klients piedāvā tikai loopback starpniekserveri

Daži komerciālie klienti vispār neveido sistēmas tuneli. Tie atklāj HTTP vai SOCKS klausītāju uz 127.0.0.1 un sagaida, ka lietotnes to izmantos. Viesis neredz šo ligzdu tieši, bet emulatoram var pateikt to izmantot, vai nu ar paplašinātajām vadīklām (Settings, tad Proxy, manuālais režīms, host 127.0.0.1 un klients izdrukātais ports), vai startējot:

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

Nokopējiet portu no klienta loga; uzminēts ports neizdodas klusi un izskatās kā salauzts tunelis. Paturiet prātā, ko tas aptver: HTTP starpniekservera iestatījumu ievēro lietotnes, kas saprot starpniekserveri, un neapstrādātas ligzdas to pilnībā ignorē. Ja darba slodze ir native binary, kas pats atver savienojumus, starpniekservera ceļš nav līdzvērtīgs tunelim, un salīdzinājums jāveic skaidri.

Pierādiet rezultātu viesa iekšienē

Atdaliet atrisināšanu no maršrutēšanas ar diviem testiem tajā pašā sesijā. Vārds, kas neizdodas, kamēr skaitliskā adrese atbild, ir DNS momentuzņēmuma problēma, un risinājums ir secība vai skaidrs resolveris. Ja neizdodas abi, tas norāda uz maršrutēšanu vai politiku, un nākamā pārbaude ir, vai lietotne darbojas darba profilā ar saviem tīkla ierobežojumiem.

Visbeidzot, ziniet, uz kura viesa jūs testējat. Ļoti veci emulatora attēli tika izlaisti bez tun atbalsta, kas nepieciešams viesa puses VPN klientam, tāpēc tur neviens profils nekad nevarēja strādāt; pašreizējie attēli to ietver. Klients, kas neizdodas pašreizējā attēlā, ir klienta vai profila problēma, un resursdatora tuneļa pārbūve rezultātu nemainīs.