Android எமுலேட்டர் மற்றும் ஹோஸ்ட் VPN: DNS ஸ்னாப்ஷாட் மற்றும் NAT

ஹோஸ்ட்டின் உலாவியில் நன்றாகத் திறக்கும் build சேவையகத்தை எமுலேட்டர் அடைய முடியாதபோது, பயனுள்ள கேள்வி VPN வேலை செய்கிறதா என்பது அல்ல. கேள்வி என்னவென்றால், கெஸ்ட்டுக்கு இரண்டு பொறிமுறைகளில் எது இல்லை என்பது. மெய்நிகர் சாதனம் எமுலேட்டரின் NAT-க்குப் பின்னால் அதன் சொந்த பிணைய ஸ்டாக்கை இயக்குகிறது, மேலும் அதன் ரிசால்வர் பட்டியல் 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 போலக் கவனிப்பது. பிரிட்ஜ் இல்லை, பகிரப்பட்ட ரூட் அட்டவணை இல்லை, மரபுவழி ரிசால்வர் இல்லை; அதன் பாக்கெட்டுகளை ஏற்கும் NAT சேவையும், மெய்நிகர் சாதனம் தொடங்கியபோது லாஞ்சர் எடுத்த ஸ்னாப்ஷாட்டும் மட்டுமே.

DNS ஒரு ஸ்னாப்ஷாட், நேரடிக் காட்சி அல்ல

தொடக்கத்தில் எமுலேட்டர் ஹோஸ்ட்டின் ரிசால்வர் பட்டியலைப் படித்து கெஸ்ட்டுக்கு நான்கு சேவையகங்கள் வரை தருகிறது, அவை 10.0.2.3 முதல் 10.0.2.6 முகவரிகளில் வெளிப்படுத்தப்படுகின்றன. அந்த நேரத்தில் சுரங்கப்பாதை கீழே இருந்தால், ஸ்னாப்ஷாட்டில் மடிக்கணினி பயன்படுத்திய பொது ரிசால்வர் இருக்கும், கெஸ்ட் தன் வாழ்நாள் முழுவதும் அதையே கேட்கும். பொது பெயர்கள் தீர்க்கப்படும், உள் பெயர்கள் தோல்வியடையும், அனைத்து அறிகுறிகளும் VPN-ஐச் சுட்டும், ஆனால் உண்மையான பழைய மதிப்பு சுரங்கப்பாதை மேலெழுவதற்கு சில நிமிடங்களுக்கு முன் பிடிக்கப்பட்ட ரிசால்வர் பட்டியலே.

எனவே வரிசையைச் சரிசெய்வது நாட்டுப்புறக் கதை அல்ல. முதலில் சுரங்கப்பாதையை இணைக்கவும், பின்னர் எமுலேட்டரை மறுதொடக்கம் செய்யவும், ஸ்னாப்ஷாட் மீட்டெடுப்பதை விட குளிர் boot-ஐ விரும்பவும், ஏனெனில் விரைவு boot படம் முன்பு சேமித்த ரிசால்வர் மற்றும் ரூட் நிலையுடன் திரும்பலாம். கெஸ்ட் இப்போது என்ன பயன்படுத்துகிறது என்பதைப் பார்க்க வேண்டுமானால், ஹோஸ்ட்டையல்ல, சாதனத்தையே கேளுங்கள்:

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

எமுலேட்டர் தொடக்கத்தில் வெளிப்படையான ரிசால்வரையும் ஏற்கிறது, கெஸ்ட் எந்த சேவையகத்தைப் பயன்படுத்த வேண்டும் என்பதைச் சரியாகத் தெரிந்தால் இது பயனுள்ளது, அந்த சேவையகம் பொதுவானதாக இருந்தால் ஆபத்தானது:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

பொது ரிசால்வரிடம் உள் மண்டலத்தின் நகல் இல்லை, எனவே ஒன்றைப் பின் செய்வது வரிசைச் சிக்கலை நிரந்தரத் தோல்வியாக மாற்றுகிறது. ப்ரொஃபைல் தனியார் 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 ஸ்னாப்ஷாட் சிக்கல், தீர்வு வரிசை அல்லது வெளிப்படையான ரிசால்வர். இரண்டும் தோல்வியடைந்தால் அது ரூட்டிங் அல்லது கொள்கையைக் குறிக்கிறது, அடுத்த சரிபார்ப்பு பயன்பாடு தனது சொந்த பிணைய கட்டுப்பாடுகளுடன் work profile-க்குள் இயங்குகிறதா என்பது.

இறுதியாக, எந்த கெஸ்ட்டில் சோதிக்கிறீர்கள் என்பதை அறியுங்கள். மிகப் பழைய எமுலேட்டர் படங்கள் கெஸ்ட் பக்க VPN கிளையண்டுக்குத் தேவையான tun ஆதரவு இல்லாமல் வெளியிடப்பட்டன, எனவே அங்கு எந்தப் ப்ரொஃபைலும் வேலை செய்ய முடியாது; தற்போதைய படங்களில் அது உள்ளது. தற்போதைய படத்தில் தோல்வியடையும் கிளையண்ட் கிளையண்ட் அல்லது ப்ரொஃபைல் சிக்கல், ஹோஸ்ட் சுரங்கப்பாதையை மீண்டும் கட்டுவது முடிவை மாற்றாது.