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

கணினி என்ன தருகிறது, என்ன தரவில்லை

establish() tun இடைமுகத்திற்கு ParcelFileDescriptor ஒன்றைத் திருப்பித் தருகிறது. வெளிச்செல்லும் IP பாக்கெட்டுகளை அதில் எழுதி, உங்கள் செயல்முறை அவற்றைப் படித்து, எங்கே போக வேண்டும் என முடிவு செய்து, சாதாரண சாக்கெட் வழியாக அனுப்பும் என்று கணினி எதிர்பார்க்கிறது. கீழே கர்னல் அனுப்புதல் இல்லை, எனவே யாரும் படிக்காதபோது பாக்கெட்டுகள் நிராகரிக்கப்படும், இடைமுகக் கணக்குகள் ஒருபோதும் நகராது.

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

தடுக்கும் படிப்பு சுழற்சி நகர்கிறதா என்பதைத் தீர்மானிக்கிறது

setBlocking(true) விவரிப்பானை தடுக்கும் பயன்முறைக்கு மாற்றுகிறது, API 21 முதல் உள்ளது. பழைய வெளியீடுகளில் தீர்வு, மூல விவரிப்பானில் fcntl மூலம் O_NONBLOCK ஐ அழிக்கும் சிறிய JNI உதவியாளர். பயன்முறை முக்கியம், ஏனெனில் காத்திருக்கும் பாக்கெட் இல்லாத படிப்பு என்ன செய்யலாம் என்பதை அதுவே தீர்மானிக்கிறது.

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

ஒவ்வொரு அழைப்பிலும் இடைமுகத்தின் MTU அளவுள்ள இடையகத்திற்கு ஒரு பாக்கெட்டைப் படியுங்கள், பூஜ்ஜியம் அல்லது எதிர்மறை திரும்பலை வெற்றுப் பாக்கெட்டாக அல்ல, பிழையாகக் கருதுங்கள்.

முதல் அனுப்புதலுக்கு முன் protect(), பிறகு அல்ல

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

வரிசை protect, பிறகு connect அல்லது bind, பிறகு send. connect க்குப் பிறகு protect அழைத்தால் முந்தைய வழி முடிவு அப்படியே இருக்கலாம், எனவே அழைப்பு true தந்தாலும் சாக்கெட் தவறான பாதையைப் பயன்படுத்தும். திருப்பித் தரும் பூலியனைச் சரிபார்த்து, false ஆகும்போது சத்தமாகத் தோல்வியடையுங்கள், வேலை செய்ய முடியாத send இல் நுழைவதற்குப் பதிலாக.

protect() ஐ ஒருபோதும் தொடாத சாக்கெட்டில் sendto வழங்கும் அனுமதிப் பிழை இந்தத் தவறின் வழக்கமான அடையாளம்.

UDP மாதிரி HTTPS ஐச் சுமக்காது

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

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

வழிப் பட்டியலும் செயலி வாரியான வடிகட்டிகளும் நீங்கள் பார்ப்பதைக் கட்டுப்படுத்துகின்றன

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

செயலி வாரியான தேர்வுக்கு அதன் சொந்த குறைந்த வரம்பு உள்ளது: addAllowedApplication மற்றும் addDisallowedApplication க்கு API 21 தேவை, பழைய வெளியீடுகளில் அந்த முறைகள் இல்லை. பாக்கெட்டின் அடிப்படையில் வடிகட்டும் வடிவமைப்பு அங்கு இயங்கவே முடியாது.

மீள்நிறுவல் பழைய விவரிப்பான்களை விட்டுச் செல்கிறது

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

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

வேலை வரிசை: தடுக்கும் பயன்முறை இயக்கத்தில், ஒவ்வொரு படிப்பிற்கும் ஒரு பாக்கெட், தலைப்பு பாகுபடுத்தப்பட்டது, சாக்கெட் பாதுகாக்கப்பட்டது, சுமை அனுப்பப்பட்டது, ஒப்படைப்பில் சுத்தமான மூடல் மற்றும் இலக்கை மூடும் வழிப் பட்டியல்.

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