Android ఎమ్యులేటర్ మరియు హోస్ట్ VPN: DNS స్నాప్షాట్ మరియు NAT

హోస్ట్ బ్రౌజర్లో సాఫీగా తెరుచుకునే build సర్వర్కు ఎమ్యులేటర్ చేరుకోలేనప్పుడు, ఉపయోగకరమైన ప్రశ్న VPN పనిచేస్తుందా అనేది కాదు. ప్రశ్న ఏమిటంటే గెస్ట్కు రెండు మెకానిజమ్లలో ఏది లేదు అని. వర్చువల్ పరికరం ఎమ్యులేటర్ NAT వెనుక తన సొంత నెట్వర్క్ స్టాక్ను నడుపుతుంది, మరియు దాని resolver జాబితా boot సమయంలో తీసుకున్న కాపీ, కాబట్టి తర్వాత వచ్చే టన్నెల్ హోస్ట్ మార్గాన్ని మారుస్తుంది కానీ గెస్ట్ అడిగేదాన్ని మార్చదు. ఈ రెండు పొరలను అర్థం చేసుకోవడం ఈ సమస్యలోని దాదాపు అన్ని రకాలను వివరిస్తుంది.

గెస్ట్ స్థిర NAT వెనుక ఉన్న ప్రత్యేక స్టాక్

QEMU యొక్క user-mode నెట్వర్కింగ్ గెస్ట్ను 10.0.2.15లో, గేట్వేను 10.0.2.2లో, DNS సేవను 10.0.2.3 నుండి 10.0.2.6 వరకు ఉంచుతుంది. గెస్ట్ యొక్క బయటకు వెళ్లే ట్రాఫిక్ను హోస్ట్ కర్నెల్ ఫార్వార్డ్ చేయదు; అది హోస్ట్ వైపు సాకెట్లుగా మారుతుంది, ప్రతి గెస్ట్ కనెక్షన్కు ఒకటి, మరియు ఆ సాకెట్లు హోస్ట్ చిరునామా ప్రదేశం నుండి బయటకు వెళ్తాయి. అందుకే గెస్ట్ కనెక్షన్ సృష్టించబడిన క్షణంలో హోస్ట్ రౌటింగ్ నిర్ణయాన్ని వారసత్వంగా పొందుతుంది, అందుకే గెస్ట్ రూట్ పట్టికలో మీ టన్నెల్ను పేర్కొనే ఎంట్రీ లేదు.

అదే మెకానిజం గెస్ట్కు ఉపయోగకరమైన బయటకు వెళ్లే మార్గాన్ని ఇస్తుంది. 10.0.2.2 హోస్ట్ loopback ఇంటర్ఫేస్ యొక్క మారుపేరు, కాబట్టి ల్యాప్టాప్లో 127.0.0.1లో వినిపిస్తున్న సేవను ఆ చిరునామాలో గెస్ట్ నుండి చేరుకోవచ్చు. క్లయింట్ loopbackలో మాత్రమే బహిర్గతం చేసేది ఏదైనా ఈ మార్గంలో చేరుకోవచ్చు, మరియు ఇదే క్రింద వివరించిన ప్రాక్సీ అమరికకు ఆధారం.

గెస్ట్ చేయలేనిది హోస్ట్ నెట్వర్క్ను తన namespace లాగా గమనించడం. బ్రిడ్జ్ లేదు, పంచుకున్న రూట్ పట్టిక లేదు, వారసత్వ resolver లేదు; దాని ప్యాకెట్లను స్వీకరించే NAT సేవ మరియు వర్చువల్ పరికరం ప్రారంభమైనప్పుడు లాంచర్ తీసుకున్న స్నాప్షాట్ మాత్రమే.

DNS ఒక స్నాప్షాట్, సజీవ దృశ్యం కాదు

ప్రారంభంలో ఎమ్యులేటర్ హోస్ట్ resolver జాబితాను చదివి గెస్ట్కు నాలుగు సర్వర్ల వరకు ఇస్తుంది, అవి 10.0.2.3 నుండి 10.0.2.6 చిరునామాలలో బహిర్గతమవుతాయి. ఆ సమయంలో టన్నెల్ కింద ఉంటే, స్నాప్షాట్లో ల్యాప్టాప్ ఉపయోగించిన పబ్లిక్ resolver ఉంటుంది, గెస్ట్ తన జీవితాంతం దానినే అడుగుతుంది. పబ్లిక్ పేర్లు పరిష్కారమవుతాయి, అంతర్గత పేర్లు విఫలమవుతాయి, అన్ని లక్షణాలు VPN వైపు చూపుతాయి, కానీ నిజమైన పాత విలువ టన్నెల్ పైకి రాకముందు కొన్ని నిమిషాల ముందు సంగ్రహించిన resolver జాబితా.

కాబట్టి క్రమాన్ని సరిచేయడం జానపదం కాదు. మొదట టన్నెల్ను కనెక్ట్ చేయండి, తర్వాత ఎమ్యులేటర్ను పునఃప్రారంభించండి, మరియు స్నాప్షాట్ పునరుద్ధరణ కంటే కోల్డ్ bootకు ప్రాధాన్యం ఇవ్వండి, ఎందుకంటే క్విక్-బూట్ ఇమేజ్ ముందుగా సేవ్ చేసిన resolver మరియు రూట్ స్థితితో తిరిగి రావచ్చు. గెస్ట్ ఇప్పుడు ఏమి ఉపయోగిస్తుందో చూడాలంటే హోస్ట్ను కాదు, పరికరాన్ని అడగండి:

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

ఎమ్యులేటర్ ప్రారంభంలో స్పష్టమైన resolverనూ అంగీకరిస్తుంది, గెస్ట్ ఏ సర్వర్ను ఉపయోగించాలో ఖచ్చితంగా తెలిస్తే ఇది ఉపయోగకరం, ఆ సర్వర్ పబ్లిక్ అయితే ప్రమాదకరం:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

పబ్లిక్ resolverకు అంతర్గత జోన్ కాపీ ఉండదు, కాబట్టి ఒకదాన్ని పిన్ చేయడం క్రమ సమస్యను శాశ్వత వైఫల్యంగా మారుస్తుంది. ప్రొఫైల్ ప్రైవేట్ DNSను పుష్ చేస్తే, టన్నెల్ దానిని అందించనివ్వండి మరియు చిరునామాను హార్డ్-కోడ్ చేయడం బదులు గెస్ట్ను కోల్డ్ boot చేయండి.

కనెక్షన్ సమయంలో రౌటింగ్ హోస్ట్ను అనుసరిస్తుంది

గెస్ట్ కనెక్షన్లు హోస్ట్ సాకెట్లు అవుతాయి కాబట్టి, సాకెట్ సృష్టించబడినప్పుడు రౌటింగ్ నిర్ణయం తీసుకోబడుతుంది. అభ్యర్థనకు ముందు టన్నెల్ పైన ఉంటే అభ్యర్థన ప్రొఫైల్ రూట్లకు లోబడి టన్నెల్ ద్వారా బయటకు వెళ్తుంది. ఎంచుకున్న ప్రిఫిక్స్లను మాత్రమే మోసే split-tunnel ప్రొఫైల్ మీ ప్రైవేట్ సబ్నెట్ను సంతోషంగా బయట వదిలేస్తుంది, కాబట్టి హోస్ట్ చేరుకోగలగడం గెస్ట్ గురించిన ఊహ, ఫలితం కాదు. ఉన్న గెస్ట్ కనెక్షన్లు ఏర్పడిన మార్గాన్నే కలిగి ఉంటాయి, అందుకే తిరిగి కనెక్ట్ అయ్యే క్లయింట్ ఎమ్యులేటర్లో ఇరుక్కున్న డౌన్లోడ్ను ఎప్పుడూ సరిచేయదు.

ధృవీకరణ హోస్ట్ ఇంటర్ఫేస్లో, గెస్ట్ గణాంకాలలో కాదు:

sudo tcpdump -ni tun0 'host 203.0.113.10'

గెస్ట్ అభ్యర్థన టన్నెల్ ఇంటర్ఫేస్లో కనిపిస్తే రౌటింగ్ పనిచేస్తోంది, సమస్య దానికి పైన ఉంది. అది భౌతిక ఇంటర్ఫేస్లో కనిపిస్తే ప్రొఫైల్ ఆ ప్రిఫిక్స్ను కవర్ చేయదు, గెస్ట్ వైపు ఏ పునఃకాన్ఫిగరేషన్ అయినా దాన్ని మార్చదు.

క్లయింట్ loopback ప్రాక్సీ మాత్రమే అందించినప్పుడు

కొన్ని వాణిజ్య క్లయింట్లు సిస్టమ్ టన్నెల్ను అసలు సృష్టించవు. అవి 127.0.0.1లో HTTP లేదా SOCKS శ్రోతను బహిర్గతం చేసి యాప్లు దాన్ని ఉపయోగిస్తాయని ఆశిస్తాయి. గెస్ట్ ఆ సాకెట్ను నేరుగా చూడలేదు, కానీ ఎమ్యులేటర్కు దాన్ని ఉపయోగించమని చెప్పవచ్చు, గానీ విస్తరించిన నియంత్రణల ద్వారా (Settings, తర్వాత Proxy, మాన్యువల్ మోడ్, హోస్ట్ 127.0.0.1 మరియు క్లయింట్ ముద్రించే పోర్ట్) లేదా ప్రారంభంలో:

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

క్లయింట్ విండో నుండి పోర్ట్ను కాపీ చేయండి; ఊహించిన పోర్ట్ నిశ్శబ్దంగా విఫలమై విరిగిన టన్నెల్లా కనిపిస్తుంది. ఇది ఏమి కవర్ చేస్తుందో గుర్తుంచుకోండి: HTTP ప్రాక్సీ సెట్టింగ్ను ప్రాక్సీ తెలిసిన యాప్లు గౌరవిస్తాయి, ముడి సాకెట్లు దాన్ని పూర్తిగా నిర్లక్ష్యం చేస్తాయి. పని సొంత కనెక్షన్లను తెరిచే native binary అయితే, ప్రాక్సీ మార్గం టన్నెల్కు సమానం కాదు మరియు పోలిక స్పష్టంగా చేయాలి.

ఫలితాన్ని గెస్ట్ లోపలి నుండి నిరూపించండి

ఒకే సెషన్లో రెండు పరీక్షలతో పరిష్కారాన్ని రౌటింగ్ నుండి వేరు చేయండి. సంఖ్యా చిరునామా సమాధానమిస్తుండగా పేరు విఫలమవడం DNS స్నాప్షాట్ సమస్య, పరిష్కారం క్రమం లేదా స్పష్టమైన resolver. రెండూ విఫలమైతే అది రౌటింగ్ లేదా విధానాన్ని సూచిస్తుంది, తదుపరి తనిఖీ యాప్ తన సొంత నెట్వర్క్ పరిమితులతో work profile లోపల నడుస్తుందా అనేది.

చివరగా, మీరు ఏ గెస్ట్పై పరీక్షిస్తున్నారో తెలుసుకోండి. చాలా పాత ఎమ్యులేటర్ ఇమేజ్లు గెస్ట్ వైపు VPN క్లయింట్కు అవసరమైన tun మద్దతు లేకుండా పంపబడ్డాయి, కాబట్టి అక్కడ ఏ ప్రొఫైల్ పనిచేయలేదు; ప్రస్తుత ఇమేజ్లలో అది ఉంది. ప్రస్తుత ఇమేజ్పై విఫలమయ్యే క్లయింట్ క్లయింట్ లేదా ప్రొఫైల్ సమస్య, హోస్ట్ టన్నెల్ను తిరిగి నిర్మించడం ఫలితాన్ని మార్చదు.