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

ஒரு சுற்று, இரண்டு சுயாதீன தோல்விப் புள்ளிகள்

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

வாசிப்புகள் சிந்திக்க எளிய பாதி. எதையும் திருப்பித் தராத வாசிப்பு ஒன்று ஒருபோதும் வராத போக்குவரத்துக்குக் காத்திருக்கிறது அல்லது peer அனுப்புவதை நிறுத்தியதால் காத்திருக்கிறது.

தடைபட்ட வாசிப்பு ஓட்டக் கட்டுப்பாட்டு கருத்து வேறுபாடு

TUN சாதனத்தை வாசிப்பது தொகுப்பு கிடைக்கும் வரை தடுக்கிறது. அது வடிவமைக்கப்பட்ட நடத்தை, அதனால் read உள்ளே நிற்கும் இழை செயலற்ற இணைப்பில் சாதாரணமாகத் தெரிகிறது. உங்கள் சொந்த TCP அடுக்கு உள்ளூர் செயலியிலிருந்து தரவை ஏற்றுக்கொள்வதைத் தொடரும்போது, தொலை peer மேலும் அனுப்ப போதுமான சாளரத்தை ஒருபோதும் அறிவிக்காதபோது அது தொங்கல் ஆகிறது. Peer நீங்கள் அறிவித்த சாளரத்தை நிரப்பி, ACK மற்றும் சாளரப் புதுப்பிப்புக்குக் காத்திருந்து, நிற்கிறது. அப்போது உங்கள் வாசிப்பானுக்குத் திருப்பித் தர எதுவும் இல்லை, செயலி திறந்த ஆனால் அமைதியான இணைப்பைக் காண்கிறது.

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

Peer இன் அனுப்பல் வரிசையையும் அது கடைசியாகக் கண்ட சாளரத்தையும் சரிபார்க்கவும். உங்கள் சாளரம் பூஜ்ஜியமாக இருப்பதால் peer தரவை வைத்திருந்தால், சரிசெய்தல் உங்கள் ACK பாதையில் உள்ளது, TUN வாசிப்பில் அல்ல.

ENOBUFS அளவுப் பிரச்சினை, இடையகப் பற்றாக்குறை அல்ல

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

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

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

நிகழ்வுகளைப் பிரிக்கும் மூன்று அளவீடுகள்

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

What you seeWhere to look
Reader parked, peer send queue empty, last advertised window zeroWindow updates in your ACK path
Write fails on one length and succeeds on a smaller oneMSS clamp and tunnel MTU
Both directions look fine, app still sees no dataProtected socket and routing loop

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

இரண்டு பாதைகளும் சார்ந்திருக்கும் குழாய்களைச் சரிசெய்யுங்கள்

இடைமுகம் சரியாகக் கட்டப்படும் வரை எந்த அறிகுறியையும் துரத்துவது மதிப்பற்றது. முக்கியமான builder அழைப்புகள் முகவரி, பாதை, MTU மற்றும் ஒப்புதல், அந்த வரிசையில்:

Builder()
  .addAddress(10.8.0.2, 32)
  .addRoute(0.0.0.0, 0)
  .setMtu(1400)
  .establish()

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

ஒப்புதலைத் தவிர்க்க முடியாது. prepare null திருப்பித் தராமல் தொடங்கிய சேவைக்கு இடைமுகம் கிடைக்காது, establish வீசுவதற்குப் பதிலாக null திருப்பித் தருகிறது, எனவே சுற்றைத் தொடங்கும் முன் விவரிப்பியைச் சரிபார்க்கவும். VpnService குறிப்பு மாதிரியை நகலெடுப்பதற்குப் பதிலாக builder ஒப்பந்தத்தை உறுதிப்படுத்தும் இடம்.

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

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

பின்னர் சாதனத்தை மறுதொடக்கம் செய்து ஒரு முறை மீண்டும் செய்யுங்கள், ஏனெனில் முதல் பிணைய மாற்றம் வரை மட்டும் செயல்படும் VpnService ஓட்டக் கட்டுப்பாட்டின் அல்ல, வழிமாற்றலின் பிரச்சினை.

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