Android VpnService அனுமதிப் பட்டியல்: அனுமதிக்கப்பட்ட பக்கங்கள் ஏன் இன்னும் தொங்குகின்றன

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

பொருத்திப் பொதுவாகக் குற்றவாளி அல்ல

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

காலி A பதிவு வழக்கமான தவறு. பூஜ்ஜிய பதில்களுடன் NOERROR திருப்பித் தருவது செல்லுபடியாகும் பதில் போலத் தெரிகிறது, எனவே stub தீர்வி அதை ஏற்கிறது, உலாவி மீண்டும் முயல்கிறது, AAAA முயல்கிறது, வேறு தீர்வியை முயல்கிறது, மிகவும் தாமதமாகக் கைவிடுகிறது. வினா பகுதியை மீண்டும் சேர்த்து பரிவர்த்தனை ID நகலெடுத்து வழங்கப்படும் பதில் குறியீடு 3, அதாவது NXDOMAIN, உரையாடலை உடனடியாக முடிக்கிறது. நீங்கள் வேண்டுமென்றே மறுக்கும் ஒவ்வொரு பெயருக்கும் இதைப் பயன்படுத்துங்கள்.

IPv6-க்கும் இயல்புநிலைக்குப் பதிலாக அதே முடிவே தேவை. A-க்கு NXDOMAIN பதிலளித்து AAAA-வை அனுமதித்தால், வாடிக்கையாளர் IPv6 வழியாகத் தடுக்கப்பட்ட பெயரை அடையலாம், வடிகட்டி கசியும். சில செயலாக்கங்கள் தடுக்கப்பட்ட AAAA வினவல்களுக்கு loopback முகவரியுடன் பதிலளிக்கின்றன, இதனால் இணைப்பு மாற்றுக்கு மாறாமல் உடனடியாகத் தோல்வியடையும். ஒரு கொள்கையைத் தேர்ந்தெடுத்து, இரு பதிவு வகைகளுக்கும் பயன்படுத்தி, இரண்டையும் பதிவு செய்யுங்கள்.

எல்லாவற்றையும் பிடிக்கும் வழித்தடம் எல்லாவற்றையும் உடைமையாக்குகிறது

DNS மட்டும் கொண்ட வடிவமைப்பு addRoute("0.0.0.0", 0)-ஐ ஒருபோதும் சேர்ப்பதில்லை, எனவே TUN இடைமுகத்தில் வினவல்கள் மட்டுமே நுழையும், மற்ற அனைத்தும் கீழ் உள்ள வலையமைப்பைப் பயன்படுத்தும். அதுவே பாதுகாப்பான வடிவம், சில அனுமதிப் பட்டியல்கள் Wi-Fi-ல் வேலை செய்வது போலவும் மொபைல் வலையமைப்பில் தோல்வியடைவது போலவும் தோன்றுவதற்கும் இதுவே காரணம்.

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

தீர்வி சாக்கெட் சுரங்கத்தை விட்டு வெளியேற வேண்டும்

அனுப்புதல் அடுத்த பொறி இருக்கும் இடம். இயக்குநர் தீர்விகள் பெரும்பாலும் சுரங்கம் அடைய முடியாத தனியார் முகவரியில் வாழ்கின்றன, எனவே நீங்கள் அனுப்பும் வினவல் எங்கும் செல்லாது, செயலி படிப்பு நேரம் முடிந்ததாகத் தெரிவிக்கும். அனுமதிக்கப்பட்ட வினவல்களை அடையக்கூடியது எனத் தெரிந்த தீர்விக்கு அனுப்பி, அந்தச் சாக்கெட்டை முதலில் VpnService.protect()-க்குக் கொடுங்கள். பாதுகாக்கப்படாத சாக்கெட் வினவலை உங்கள் சொந்த சுரங்கத்திற்குத் திருப்பி அனுப்பும், அங்கு அது மீண்டும் செயலியை அடைந்து நேர வரம்பு வரை சுற்றும்.

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

அளவும் செக்சமும் செய்தியின்றித் தோல்வியடைகின்றன

அமைதியான நீக்கங்கள் அளவிலிருந்தும் வருகின்றன. பெரிய பதில் தொகுப்புடன் கூடிய DNS பதில், அல்லது தாராள விருப்பங்களுடன் கூடிய TCP கைகுலுக்கல், நீங்கள் ஒருபோதும் வெளிப்படையாக அமைக்காத பாதை MTU-வை மீறலாம்; துண்டு மேலே காணாமல் போகும், வாடிக்கையாளர் சிறியதாக மீண்டும் முயலும் அல்லது முயல்வதை நிறுத்தும். இடைமுக MTU-வை 1280-ஆக அமைப்பது பெரும்பாலான மொபைல் பாதைகளைத் தாக்குப்பிடிக்கும் பழமைவாதத் தேர்வு, மேலும் யாரும் அளவிடாத இயல்புநிலையை மரபுரிமையாகப் பெறுவதை விட வெளிப்படையாக இருப்பது சிறந்தது.

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

VpnService உங்களுக்காகச் செய்யாதவை

இவற்றைச் சுற்றி வடிவமைப்பதற்கு முன் இரண்டு வரம்புகளை அறிவது மதிப்புள்ளது. எந்தச் சாதாரண செயலியும் Wi-Fi-க்கு வெளியே கணினி அளவிலான ப்ராக்ஸியையோ PAC கோப்பையோ நிறுவ முடியாது, அந்தப் பகுதி மாறவில்லை. ஒவ்வொரு செயலிக்கான பாதை மாறியுள்ளது: API 29-க்கு முன் VpnService.Builder ப்ராக்ஸியை அறவே கொண்டு செல்ல முடியாது, API 29 முதல் setHttpProxy(ProxyInfo.buildPacProxy(uri)) VPN வலையமைப்புக்கு மதிப்பிடத் தளத்திற்கு PAC ஸ்கிரிப்டை வழங்குகிறது. பழைய API-களை இலக்காகக் கொள்ளும்போதோ PAC மாதிரி விதியை வெளிப்படுத்த முடியாதபோதோ விதிகளை உங்கள் சொந்த குறியீட்டில் மதிப்பிடுங்கள். UDP-ம் இலவசம் அல்ல: உலாவிகள் SOCKS ப்ராக்ஸி வழியாக TCP-வை மட்டுமே அனுப்புகின்றன, பெரும்பாலான SOCKS5 வாடிக்கையாளர்கள் UDP ASSOCIATE-ஐ ஒருபோதும் செயல்படுத்துவதில்லை, எனவே ப்ராக்ஸி அடிப்படையிலான வடிவமைப்பு TCP ஆரோக்கியமாகத் தெரியும்போது UDP-வை நீக்குகிறது அல்லது கசிக்கிறது.

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

இந்த வரிசையில் சரிபார்க்கவும்

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

1. நிறுவப்பட்ட வழித்தடங்களைப் பட்டியலிட்டு, DNS அல்லாத பாக்கெட்டுகள் TUN இடைமுகத்தில் நுழைகின்றனவா என்பதை உறுதிசெய்யுங்கள்.
2. ஒரு தடுக்கப்பட்ட மற்றும் ஒரு அனுமதிக்கப்பட்ட பெயருக்கு வினவல் பெயர், முடிவு மற்றும் பதில் குறியீட்டைப் பதிவு செய்யுங்கள்.
3. தீர்வி சாக்கெட் பாதுகாக்கப்பட்டுள்ளதா, தேர்ந்தெடுத்த தீர்வி சுரங்கத்தின் உள்ளிருந்து பதிலளிக்கிறதா என்பதை உறுதிசெய்யுங்கள்.
4. இடைமுக MTU மற்றும் கையால் உருவாக்கிய ஒரு பதிலின் செக்சத்தை உறுதிசெய்யுங்கள்.
5. அதே பக்கத்தை Wi-Fi மற்றும் மொபைல் வலையமைப்பில் மீண்டும் செய்யுங்கள், ஏனெனில் இயக்குநர் தீர்விகள் மற்றும் பாதை MTU வேறுபடும்.

ஐந்தும் நிலைத்திருந்தும் பக்கம் இன்னும் தொங்கினால், அடுத்த சந்தேகத்திற்குரியவர் அனுப்புநரே: பிடிபட்ட கோரிக்கையைப் பிடிபட்ட பதிலுடன் ஒப்பிட்டு, காணாமல் போன பைட் எண்ணிக்கையையோ அரை மூடிய சாக்கெட்டையோ தேடுங்கள். VpnService.Builder குறிப்பு வழித்தடம், DNS மற்றும் MTU ஒப்பந்தங்களை உள்ளடக்குகிறது, மேலும் protect() builder விருப்பம் அல்ல, தனி VpnService அழைப்பு; இணைக்கப்பட்ட இடைமுகம் முதல் ஒப்பந்தம் நிறைவேறியது என்பதை மட்டுமே குறிக்கிறது.