Android-hermir og VPN hýsilsins: DNS-snapshot og NAT útskýrð

Þegar hermirinn nær ekki byggingarþjóninum sem vafrinn á hýsilnum opnar eðlilega, er gagnlega spurningin ekki hvort VPN virki. Spurningin er hvorja tveggja aðferða gestinninn vantar. Sýndartækið keyrir sitt eigið netlag á bak við NAT hermisins, og listi þess yfir leysendur er afrit sem tekið var við ræsingu, svo tunnill sem kemur upp síðar breytir leið hýsilsins án þess að breyta því sem gesturinn spyr um. Skilningur á þessum tveimur lögum skýrir næstum hvert afbrigði þessa vandamáls.

Gesturinn er aðskilið lag á bak við fast NAT

Notendahamur QEMU setur gestinn á 10.0.2.15 með gátt á 10.0.2.2, og DNS-þjónustuna á 10.0.2.3 til 10.0.2.6. Útgönguumferð gestanna er ekki framsend af kjarna hýsilsins; henni er umbreytt í sambönd á hýsilnum, eitt fyrir hverja tengingu gestanna, og þau sambönd fara út úr vistfangi hýsilsins. Þess vegna erfir tenging gestanna leiðarákvörðun hýsilsins á þeirri stundu sem hún verður til, og þess vegna er engin færsla í leiðatöflu gestanna sem nefnir tunnilinn þinn.

Sama aðferð gefur gestinum gagnlega undankomu. 10.0.2.2 er samheiti fyrir lykkjubak hýsilsins, svo þjónusta sem hlustar á 127.0.0.1 á fartölvunni er aðgengileg frá gestinum á því vistfangi. Allt sem biðlarinn birtir eingöngu á loopback er aðgengilegt þannig, og það er grundvöllur milliliðsuppsetningarinnar sem lýst er hér fyrir neðan.

Það sem gesturinn getur ekki gert er að skoða net hýsilsins eins og hann sé nafnrými á því. Það er engin brú, engin sameiginleg leiðatafla og enginn arftekinn leysir, aðeins NAT-þjónustan sem tekur við pakkum hans og snapshotið sem ræsirinn tók þegar sýndartækið byrjaði.

DNS er snapshot, ekki lifandi mynd

Við ræsingu les hermirinn lista hýsilsins yfir leysendur og gefur gestinum allt að fjóra þjóna, birt á vistföngunum 10.0.2.3 til 10.0.2.6. Ef tunnillinn var niðri á þeirri stundu inniheldur snapshotið hvaða opinberan leysi sem fartölvan notaði, og gesturinn heldur áfram að spyrja hann alla ævi sína. Opinber nöfn leysast, innri nöfn mistakast, og öll einkenni benda á VPN þegar raunverulega gamla gildið er listi leysenda sem tekinn var nokkrum mínútum áður en tunnillinn kom upp.

Röðunarleiðréttingin er því ekki þjóðsaga. Tengdu tunnilinn fyrst, endurræstu svo hermirinn, og veldu kalt ræsingu fram yfir endurheimt snapshot, því quick-boot mynd getur komið til baka með leysi- og leiðastöðuna sem hún geymdi fyrr. Ef þú þarft að sjá hvað gesturinn notar núna, spurðu tækið en ekki hýsilinn:

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

Hermirinn tekur líka við skýrum leysi við ræsingu, sem er gagnlegt þegar þú veist nákvæmlega hvaða þjón gesturinn á að nota og hættulegt þegar sá þjón er opinber:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Opinber leysir hefur ekkert afrit af innra svæði, svo að festa einn snýr röðunarvandamáli í varanlega bilun. Ef sniðið ýtir einkarefslu DNS skaltu leyfa tunnilnum að útvega hana og kalt-ræsa gestinn í stað þess að harðkóða vistfang.

Leiðsögn fylgir hýsilnum við tengingu

Þar sem tengingar gestanna verða að samböndum hýsilsins er leiðarákvörðunin tekin þegar sambandið verður til. Tunnill uppi fyrir beiðnina þýðir að beiðnin fer út um tunnilinn, háð leiðum sniðsins. Split-tunnel snið sem ber aðeins valda forskeyti mun fúslega skilja einkanetið þitt eftir úti, svo að náanleiki hýsilsins er tilgáta um gestinn, ekki niðurstaða. Núverandi tengingar gestanna halda þeirri leið sem þær voru búnar til með, sem er ástæðan fyrir því að biðlari sem tengist aftur lagar ekki alltaf fasta niðurhal inni í herminum.

Sannprófunin á heima á viðmóti hýsilsins, ekki í tölfræði gestanna:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Ef beiðni gestanna birtist á tunnilviðmótinu virkar leiðsögnin og vandamálið er ofar henni. Ef hún birtist á líkamlega viðmótinu nær sniðið ekki yfir það forskeyti, og engin uppsetning á gestinum breytir því.

Þegar biðlarinn býður aðeins loopback-millilið

Sumir verslunarlegir biðlarar búa ekki til kerfistunnil yfirleitt. Þeir birta HTTP- eða SOCKS-hlustun á 127.0.0.1 og ætlast til að forrit noti hana. Gesturinn sér það samband ekki beint, en hægt er að segja herminum að nota það, annað hvort í gegnum extended controls (Settings, svo Proxy, manual mode, host 127.0.0.1 og gáttin sem biðlarinn prentar) eða við ræsingu:

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

Afritaðu gáttina úr glugga biðlarans; giskaða gáttin mistekst hljóðlaust og lítur út eins og brotinn tunnill. Hafðu í huga hvað þetta nær yfir: HTTP-milliliðsstilling er virt af forritum sem þekkja milliliði, og hrá sambönd hunsa hana algjörlega. Ef vinnuálagið er innfædd tvíund sem opnar sín eigin sambönd er milliliðsleiðin ekki jafngild tunnilnum og bera verður saman sérstaklega.

Sannaðu niðurstöðuna inni frá gestinum

Aðgreindu leysingu frá leiðsögn með tveimur prófum í sama lotu. Nafn sem mistekst á meðan tölulega vistfangið svarar er vandamál DNS-snapshots, og lausnin er röðun eða skýr leysir. Ef bæði mistakast bendir það á leiðsögn eða stefnu, og næsta athugun er hvort forritið keyri inni í vinnusniði með eigin nettakmörkunum.

Að lokum skaltu vita hvaða gest þú prófar á. Mjög gamlar hermirmyndir voru sendar án tun-stuðnings sem biðlari VPN á gestinum þarf, svo ekkert snið gat nokkurn tíma virkað þar; núverandi myndir hafa hann. Biðlari sem mistekst á núverandi mynd er vandamál biðlarans eða sniðsins, og að endurbyggja tunnil hýsilsins breytir engu um niðurstöðuna.