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

எதையும் இயக்கும் முன் தாண்டல்களை வரைபடமாக்குங்கள்

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

HopOwnerWhat it decides
Application requestThe appDestination, resolver, address family
Capture servicePhone VpnService appWhich traffic enters the relay at all
ADB relayHost processForwarding phone flows to host sockets
Host egressHost routing and VPNExit address and host policy

ஒரு நேரத்தில் ஒரு VPN சேவை வாடிக்கையாளர் மட்டுமே தொலைபேசியின் பிடிப்புப் பாத்திரத்தை வைத்திருக்க முடியும், எனவே இரண்டாவது சாதாரண VPN செயலி ரிலே மீது அடுக்காகாது. VPN கணினிக்குச் சொந்தமானது என்றால், பிடிப்புச் சேவை அந்தக் கணினிக்கான அணுகு இணைப்பு, தொலை சுரங்கப்பாதை ஏற்கனவே முடிவைப் பாதுகாக்கிறது என்பதற்கான சான்று அல்ல.

தொலைபேசியைத் தொடும் முன் ரிலேவைத் தயாராக்குங்கள்

Gnirehtet இந்தக் கட்டமைப்பின் ஆவணப்படுத்தப்பட்ட எடுத்துக்காட்டு: தொலைபேசியில் root இல்லாத VPN சேவை வாடிக்கையாளர் மற்றும் ஹோஸ்ட்டில் ADB வழியாக எடுத்துச் செல்லப்படும் ரிலே, IPv4 மீது TCP மற்றும் UDP-ஐ ஆதரிக்கிறது. இதன் களஞ்சியம் திட்டம் இனி தீவிரமாகப் பராமரிக்கப்படவில்லை என்றும் கூறுகிறது, எனவே இதை மேற்கோள் வடிவமைப்பாகவும் ஆய்வகத்திற்கான வேலை செய்யும் கருவியாகவும் கருதுங்கள், நிர்வகிக்கப்படும் குழுவில் தரமாக்கக்கூடிய ஆதரவுப் பொருளாக அல்ல.

adb devices
adb shell getprop ro.build.version.release
gnirehtet run

முதலில் adb devices இயக்கவும். ஹோஸ்ட்டின் பிழைத்திருத்த விசையை ஏற்காத தொலைபேசி அனுமதியற்றதாக அறிவிக்கப்படும், சாதனத்தில் உள்ள கோரிக்கை ஏற்கப்படும் வரை ரிலே இணைக்காது. gnirehtet run வாடிக்கையாளரை நிறுவி, ரிலேவைத் தொடங்கி, பிடிப்பை இயக்குகிறது; படிகளைப் பிரிக்கும் பதிப்பில் அதற்குப் பதிலாக ஆவணப்படுத்தப்பட்ட install, relay மற்றும் start துணைக் கட்டளைகளைப் பயன்படுத்துங்கள்.

ADB அணுகல் சாதனக் கட்டுப்பாட்டு உறவு, வலையமைப்பு அமைப்பு அல்ல. நீங்கள் கட்டுப்படுத்தும் கணினிக்கு மட்டும் அனுமதி அளியுங்கள், பணி முடிந்ததும் அந்த அனுமதியைத் திரும்பப் பெறத் திட்டமிடுங்கள்.

ஹோஸ்ட் VPN-ஐ மீண்டும் பாதைக்குக் கொண்டு வாருங்கள்

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

ip route get 1.1.1.1
curl -4 https://ifconfig.me
sudo ss -tnp | grep -i relay

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

ரிலே வழியாகச் செல்லும் போக்குவரத்திற்கு DNS ஹோஸ்ட்டில் தீர்க்கப்படுகிறது, எனவே எந்த சேவையகம் பெயர்களைக் காண்கிறது என்பதை ஹோஸ்ட்டின் தீர்வி முடிவு செய்கிறது. தொலைபேசியில் தனியார் DNS அமைப்பு ரிலேவைக் கடக்காது, தொலைபேசிப் பக்கத்தின் தீர்வி சோதனை ஹோஸ்ட்டின் தேடல்களை விவரிக்காது.

ஒவ்வொரு தாண்டலையும் தனித்தனியாகச் சரிபார்க்கவும்

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

adb shell dumpsys connectivity | grep -i -A3 vpn
adb logcat -s GnirehtetRelay:V Gnirehtet:V

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

ஹோஸ்ட்டில் வேலை செய்யும் உலாவி ஹோஸ்ட் உலாவியின் பாதையை நிரூபிக்கிறது, ரிலே செயல்முறையின் பாதையை அல்ல. ஒவ்வொன்றும் தெரிவிக்கும் முகவரிகளை ஒப்பிடுங்கள், தனியார் ஆதாரத்தையும் பொது பக்கத்தையும் சோதியுங்கள், ஏனெனில் தனியார்-மட்டும் சுரங்கப்பாதை ஒன்றை வழிப்படுத்த முடியும் மற்றதை அல்ல.

பிரித்தெடுத்து தோல்வி நடத்தையைத் தேர்ந்தெடுங்கள்

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

gnirehtet stop
gnirehtet uninstall
adb kill-server

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

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

தொடர்புடைய கட்டுரைகள்