Android VPN: VpnService விவரிப்பு மற்றும் root tun சாதனம்

இரண்டு பாதைகள் Android ஆப்பின் முன் ஒரு IP இடைமுகத்தை வைக்க முடியும், இரண்டும் மிக வேறுபட்ட உரிமையாளர்களைக் கொண்ட ஒரே வகை கோப்பு விவரிப்பில் முடிகின்றன. ஒன்று VpnService மற்றும் அதன் builder வழியாகச் செல்கிறது, மற்றொன்று root shell மற்றும் /dev/net/tun வழியாக. அந்த விவரிப்பில் ஒவ்வொரு படிப்பும் வெளிச்செல்லும் பாக்கெட், ஒவ்வொரு எழுத்தும் உள்வரும் பாக்கெட். பாதைகளைப் பிரிப்பது கொள்கை யாரிடம் உள்ளது, OS மேம்படுத்தலை யார் தாங்குகிறார், மற்றும் ரூட்டிங் அட்டவணையில் எவ்வளவை நீங்கள் தொடலாம் என்பதே.

அது மறுக்கும் குறிப்பிட்ட விஷயத்தை உங்களால் பெயரிட முடியாவிட்டால் மட்டுமே தளத்தின் பாதையை எடுத்துக் கொள்ளுங்கள். அந்த மறுப்பு பொதுவாக TAP, உங்கள் சொந்த ஆப் தொகுப்புக்கு வெளியே பிடிப்பு, அல்லது கட்டமைப்பு ஒருபோதும் வெளிப்படுத்தாத ரூட்டிங் விதி.

தளத்தின் பாதையில் நீங்கள் கட்டளைகளுக்குப் பதிலாக நோக்கத்தை அறிவிக்கிறீர்கள். குறைந்தது ஒரு முகவரி, தேவையான ரூட்டுகள், DNS சேவையகங்கள் மற்றும் விருப்ப ஆப் பட்டியலை வழங்குகிறீர்கள், பின்னர் Android இன் கணினி சேவை தன் சொந்த அடையாளத்தில் சிறப்புரிமை பெற்ற அமைப்பைச் செய்கிறது. இடைமுகத்தின் பெயரை நீங்கள் முன்கூட்டியே அறிய மாட்டீர்கள், அதை உருவாக்கும் ioctl ஐ ஒருபோதும் வெளியிட மாட்டீர்கள், அதுவே முக்கிய விஷயம்.

IP இடைமுகம் பெற இரண்டு வழிகள்

root பாதை பழைய செய்முறை. நீங்கள் /dev/net/tun திறக்கிறீர்கள், IFF_TUN உடன் TUNSETIFF அழைக்கிறீர்கள், ip link மூலம் இடைமுகத்தை மேலே ஏற்றுகிறீர்கள், முகவரிகள் மற்றும் ரூட்டுகளை கையால் சேர்க்கிறீர்கள். ஒவ்வொரு படியையும் நீங்களே சரியாகச் செய்ய வேண்டும், கட்டமைப்பு அமைதியாகக் கையாள்ந்திருக்கும் படிகளும் உட்பட. ஒரு ரூட் தவறினால் பயனருக்கு இறந்த சேவையகம் போன்ற அதே அறிக்கை வருகிறது.

பிழைத்திருத்தம் அமைப்பைப் போலவே வேறுபடுகிறது. root பாதையில் இடைமுகம் உள்ளது அல்லது உங்கள் ioctl நேரடியாகப் படிக்கக்கூடிய பிழையைத் திருப்பியுள்ளது. தளத்தின் பாதையில் establish() வெற்றிபெற்ற பிறகே இடைமுகம் உள்ளது, எனவே தோல்வி சாதன முனையை விட விதிவிலக்கு அல்லது null விவரிப்பாக வருகிறது, அதை நீங்கள் கீறிப் பார்க்கலாம்.

establish() உண்மையில் என்ன திருப்பித் தருகிறது

Builder.establish() க்கு மூன்று முடிவுகள் உள்ளன, அவற்றுக்கு மூன்று வெவ்வேறு பதில்கள் தேவை. விவரிப்பு என்பது இடைமுகம் அமைக்கப்பட்டு பயன்பாட்டுக்கு உங்களுடையது, null என்பது கோரிக்கை கடக்கவில்லை, மற்றும் எறியப்பட்ட விதிவிலக்கு என்பது கணினி சேவை அதை நிராகரித்தது. null மற்றும் வெற்றியை ஒரே boolean ஆக இணைப்பது பாக்கெட்டை ஒருபோதும் சுமக்காத இயங்கும் சுரங்கப்பாதையை ஆப் அறிவிக்கும் மிகவும் பொதுவான வழி. Builder குறிப்பு முகவரித் தேவையைக் கூறுகிறது, சேவையகத்தைக் குறை சொல்வதற்கு முன் அதைப் படிப்பது மதிப்புள்ளது.

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

Binder ஒரு படி, JNI மற்றொரு அச்சு

builder கோரிக்கை Binder வழியாக கணினிக்குள் நுழைகிறது, அதற்குக் கீழே எங்கோ தளம் சாதனத்தை அமைக்க native குறியீட்டை அழைக்கிறது. இவை ஒரே அழைப்பில் அடுக்கப்பட்ட இரண்டு வெவ்வேறு வழிமுறைகள். Binder உங்கள் ஆப் மற்றும் கணினி சேவைக்கு இடையேயான செயலிடைத் தொடர்பு, JNI ஒரு செயல்முறைக்குள் Java இலிருந்து native க்குச் செல்லும் பாலம். Android 9 AOSP மரத்தைப் படிப்பது அடுக்கை நேரடியாகத் தோற்றமளிக்கும், உள் வகுப்புப் பெயர்களும் கோப்புப் பாதைகளும் வெளியீடுகளுக்கு இடையே நகரும் என்பதை நினைவில் கொள்ள வேண்டும்.

மாறாதது நீங்கள் நம்பக்கூடிய ஒப்பந்தம்: builder, அது திருப்பித் தரும் விவரிப்பு, மற்றும் அதைச் சுற்றியுள்ள சேவை வாழ்க்கைச் சுழற்சி. ஒரு இடைமுகத்தைப் பெற எந்த ஆப்பும் உள் சேவை பரிவர்த்தனையை அழைக்கவோ சாதன முனையை மீண்டும் உருவாக்கவோ கூடாது. உங்கள் குறியீடு AOSP வகுப்புப் பெயரைச் சார்ந்திருந்தால், நீங்கள் சோதிக்காத வெளியீட்டில் அது உடையும்.

TUN IP ஐச் சுமக்கிறது, TAP Ethernet

TUN ஒரு IP இடைமுகம். TAP ஒரு Ethernet இடைமுகம், அந்த வேறுபாடே பாலம் சாத்தியமா என்பதைத் தீர்மானிக்கிறது. TUN சாதனத்திற்கு MAC முகவரியோ அனுப்ப வேண்டிய Ethernet தலைப்போ இல்லை, எனவே TUN வாடிக்கையாளர் ரூட்டுகள் எப்படி எழுதப்பட்டாலும் அடுக்கு 2 பாலத்தில் சேர முடியாது.

VpnService உங்களுக்கு IP வகையைத் தருகிறது, அதுவே ஆப் நிலை VPN க்குத் தேவையானது மற்றும் மூல Ethernet அடுக்கு இல்லாமல் ஆதரிக்கக்கூடியது. உங்கள் வடிவமைப்புக்கு பாலம் தேவைப்பட்டால், தளத்தின் பாதை உங்களை அங்கு கொண்டு செல்லாது, கர்னல் மற்றும் சாதன அனுமதிகள் ஒத்துழைத்தால் மட்டுமே root பாதை அதைச் செய்யும்.

root பாதை இன்னும் வெற்றி பெறும் இடம்

மூன்று வேலைகள் மக்களை தளத்தின் பாதையிலிருந்து தள்ளுகின்றன. அடுக்கு 2 பாலத்திற்கு TAP தேவை. உங்கள் VPN வரம்புக்கு வெளியே உள்ள ஆப்களின் போக்குவரத்தைப் பிடிக்க கட்டமைப்பு தராத தெரிவுநிலை தேவை. builder ஒருபோதும் வெளிப்படுத்தாத கொள்கை ரூட்டிங், உதாரணமாக ஒரு இலக்குக்கு தனி அட்டவணை, நீங்களே நிறுவும் விதிகளைக் கோருகிறது.

செலவுகள் பின்னர் வருகின்றன: திறக்கப்பட்ட bootloader அல்லது root செய்யப்பட்ட பிம்பம், உங்கள் கால்களுக்குக் கீழே நகரும் SELinux கொள்கை, மற்றும் OTA க்குப் பிறகு சரியாக நடந்துகொள்வதை நிறுத்தும் சாதனம். root செய்யப்பட்ட செய்முறையை சாதாரண ஆப் விநியோகத்தின் மூலம் அனுப்பவும் முடியாது, எனவே பெரும்பாலான குழுக்கள் அதை தயாரிப்புக்குப் பதிலாக உள் கண்டறியும் பாதையாக வைத்திருக்கின்றன.

இரண்டிற்கும் இடையே தேர்வு

உங்களிடம் உள்ள குறியீட்டிலிருந்து அல்ல, உங்களுக்குத் தேவையான இடைமுகத்திலிருந்து தொடங்குங்கள். பதில் ஆப்-வரம்புடைய ரூட்டுகளைக் கொண்ட TUN சாதனம் எனில், தளத்தின் பாதை குறுகியது மற்றும் மேம்படுத்தல்களைத் தாங்கும். பதிலில் Ethernet சட்டகங்கள், பிற ஆப்களின் பிடிப்பு, அல்லது builder நிராகரிக்கும் ரூட்டிங் விதிகள் இருந்தால், நீங்கள் root பிரதேசத்தில் இருக்கிறீர்கள், அதை இயக்கச் செலவாக பட்ஜெட் செய்ய வேண்டும்.

பெரும்பாலான விவாதங்களை முடிவுக்குக் கொண்டுவரும் ஒரு சரிபார்ப்பு: முதலில் தளத்தின் பாதையை உருவாக்குங்கள், establish() இன் முடிவை தொலை அமர்வின் நிலையிலிருந்து தனியாகப் பதிவு செய்யுங்கள், ஒவ்வொரு திசையிலும் ஒரு பாக்கெட்டை உறுதி செய்யுங்கள். அதன் பிறகே இல்லாத திறன் ஆதரவு பெற்ற பாதையை விடுவதை நியாயப்படுத்துகிறதா என்று முடிவு செய்யுங்கள்.