Emulatori Android dhe VPN në host: pamja DNS dhe NAT

Kur emulatori nuk arrin dot një server ndërtimi që shfletuesi në host e hap pa problem, pyetja e dobishme nuk është nëse VPN-ja funksionon. Pyetja është cili prej dy mekanizmave i mungon mysafirit. Pajisja virtuale ekzekuton stakun e vet të rrjetit pas NAT-it të emulatorit, dhe lista e saj e rezoluesve është një kopje e marrë në nisje, kështu që një tunel që vjen më vonë ndryshon rrugën e hostit pa ndryshuar atë që pyet mysafiri. Kuptimi i këtyre dy shtresave shpjegon pothuajse çdo variant të këtij problemi.

Mysafiri është një stak i veçantë pas një NAT-i fiks

Rrjeti i QEMU në modalitetin e përdoruesit e vendos mysafirin në 10.0.2.15 me portë në 10.0.2.2, dhe shërbimin DNS në 10.0.2.3 deri në 10.0.2.6. Trafiku dalës i mysafirit nuk përcillet nga kerneli i hostit; ai përkthehet në socket-e në anën e hostit, një për çdo lidhje të mysafirit, dhe ato socket-e dalin nga hapësira e adresave e hostit. Kjo është arsyeja pse një lidhje e mysafirit trashëgon vendimin e rrugëtimit të hostit në momentin kur krijohet, dhe pse mysafiri nuk ka asnjë zë në tabelën e rrugëve që përmend tunelin tuaj.

I njëjti mekanizëm i jep mysafirit një dalje të dobishme. 10.0.2.2 është një pseudonim i ndërfaqes loopback të hostit, kështu që një shërbim që dëgjon në 127.0.0.1 në laptop arrihet nga mysafiri në atë adresë. Çdo gjë që klienti ekspozon vetëm në loopback arrihet në këtë mënyrë, dhe kjo është baza e konfigurimit të proxy-t të përshkruar më poshtë.

Ajo që mysafiri nuk mund të bëjë është të vëzhgojë rrjetin e hostit sikur të ishte namespace i tij. Nuk ka urë, nuk ka tabelë të përbashkët rrugësh dhe nuk ka rezolues të trashëguar; ka vetëm shërbimin NAT që i pranon paketat e tij dhe pamjen që nisi launcher-i kur pajisja virtuale u startua.

DNS është një pamje, jo një vështrim i gjallë

Në nisje emulatori lexon listën e rezoluesve të hostit dhe i jep mysafirit deri në katër serverë, të ekspozuar në adresat 10.0.2.3 deri në 10.0.2.6. Nëse tuneli ishte i ulur në atë moment, pamja përmban atë rezolues publik që përdorte laptop-i, dhe mysafiri vazhdon ta pyesë gjithë jetën. Emrat publikë zgjidhen, emrat e brendshëm dështojnë, dhe të gjitha simptomat tregojnë nga VPN-ja ndërsa vlera vërtet e vjetruar është një listë rezoluesish e kapur disa minuta përpara se tuneli të ngrihej.

Rregullimi i rendit nuk është pra folklor. Lidhni së pari tunelin, pastaj rinisni emulatorin, dhe parapëlqeni një nisje të ftohtë ndaj rikthimit të një pamjeje, sepse një imazh quick-boot mund të kthehet me gjendjen e rezoluesve dhe të rrugëve të ruajtur më parë. Nëse doni të shihni çfarë përdor mysafiri tani, pyesni pajisjen, jo hostin:

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

Emulatori pranon gjithashtu një rezolues të qartë në nisje, që është i dobishëm kur e dini saktësisht cilin server duhet të përdorë mysafiri dhe i rrezikshëm kur ai server është publik:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Një rezolues publik nuk ka kopje të një zone të brendshme, kështu që fiksimi i njërit e kthen një problem rendi në një dështim të përhershëm. Nëse profili shtyn DNS privat, lëreni tunelin ta sigurojë atë dhe bëni nisje të ftohtë të mysafirit në vend që të kodoni fort një adresë.

Rrugëtimi ndjek hostin në momentin e lidhjes

Meqenëse lidhjet e mysafirit bëhen socket-e të hostit, vendimi i rrugëtimit merret kur krijohet socket-i. Tuneli i ngritur përpara kërkesës do të thotë që kërkesa del përmes tunelit, në varësi të rrugëve të profilit. Një profil split-tunnel që mban vetëm prefikse të zgjedhura do ta lërë me kënaqësi nënrrjetin tuaj privat jashtë, kështu që arritshmëria e hostit është një hipotezë për mysafirin, jo një rezultat. Lidhjet ekzistuese të mysafirit mbajnë rrugën me të cilën u krijuan, prandaj një klient që rilidhet nuk e rregullon gjithmonë një shkarkim të ngecur brenda emulatorit.

Verifikimi i takon ndërfaqes së hostit, jo statistikave të mysafirit:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Nëse kërkesa e mysafirit shfaqet në ndërfaqen e tunelit, rrugëtimi po funksionon dhe problemi është mbi të. Nëse shfaqet në ndërfaqen fizike, profili nuk e mbulon atë prefiks, dhe asnjë rikonfigurim nga ana e mysafirit nuk do ta ndryshojë.

Kur klienti ofron vetëm një proxy loopback

Disa klientë komercialë nuk krijojnë fare tunel sistemi. Ata ekspozojnë një dëgjues HTTP ose SOCKS në 127.0.0.1 dhe presin që aplikacionet ta përdorin. Mysafiri nuk e sheh drejtpërdrejt atë socket, por emulatorit mund t'i thuhet ta përdorë, ose përmes kontrolleve të zgjeruara (Settings, pastaj Proxy, modaliteti manual, host 127.0.0.1 dhe porta që shtyp klienti) ose në nisje:

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

Kopjoni portën nga dritarja e klientit; një portë e hamendësuar dështon në heshtje dhe duket si tunel i thyer. Mbani mend çfarë mbulon kjo: konfigurimi i proxy-t HTTP respektohet nga aplikacionet që njohin proxy-n, dhe socket-et e papërpunuara e injorojnë plotësisht. Nëse ngarkesa është një binar native që hap lidhjet e veta, rruga përmes proxy-t nuk është e barabartë me një tunel dhe krahasimi duhet bërë në mënyrë të qartë.

Provoni rezultatin nga brenda mysafirit

Ndani zgjidhjen nga rrugëtimi me dy teste në të njëjtën sesion. Një emër që dështon ndërsa adresa numerike përgjigjet është problem i pamjes DNS, dhe zgjidhja është rendi ose një rezolues i qartë. Nëse dështojnë të dyja, kjo tregon rrugëtim ose politikë, dhe kontrolli tjetër është nëse aplikacioni xhiron brenda një profili pune me kufizimet e veta të rrjetit.

Më në fund, dijeni në cilin mysafir po testoni. Imazhet shumë të vjetra të emulatorit dileshin pa mbështetjen tun që i duhet një klienti VPN në anën e mysafirit, kështu që asnjë profil nuk mund të funksiononte atje; imazhet aktuale e përfshijnë. Një klient që dështon në një imazh aktual është problem i klientit ose i profilit, dhe rindërtimi i tunelit të hostit nuk do ta ndryshojë rezultatin.