VPN MTU பற்றிய கட்டுக்கதைகள்: உங்கள் பாக்கெட்டுகள் ஏன் சுருங்குகின்றன, இடம் எங்கே போகிறது

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

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

முதல் கட்டுக்கதை: சுரங்கப்பாதையின் MTU பாதையின் MTU

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

பாதை-MTU கண்டுபிடிப்பு இரண்டையும் ஒருங்கிணைக்க உள்ளது, அது பின்னூட்டத்தைப் பொறுத்தது. IPv4-இல், முழு அளவு பாக்கெட்டை அனுப்ப முடியாத ரவுட்டர் ICMP "fragmentation needed" செய்தியை அனுப்ப வேண்டும், அனுப்புநர் தனது மதிப்பீட்டைக் குறைக்கிறார். IPv6-இல் இதற்கு இணையானது Packet Too Big செய்தி, ரவுட்டர்கள் பயணத்தில் துண்டாக்குவதே இல்லை. அந்த பின்னூட்டம் வடிகட்டப்படும்போது, அனுப்புநர் பாதை சுமக்க முடியாத பாக்கெட்டுகளை உருவாக்கிக்கொண்டே இருக்கிறார், ஏன் என்று எதுவும் அவரிடம் சொல்லவில்லை.

இரண்டாவது கட்டுக்கதை: என்கேப்சுலேஷனுக்கு ஒரு தலைப்பு செலவாகிறது

வெளி அடுக்குகளை நேர்மையாக எண்ணுங்கள். வெளி IP தலைப்பு IPv4-இல் 20 பைட் அல்லது IPv6-இல் 40. NAT-ஐக் கடக்க UDP என்கேப்சுலேஷன் 8 சேர்க்கிறது. சுரங்கப்பாதை நெறிமுறை அதன் சொந்த தலைப்பு, துவக்க திசையன் அல்லது நான்ஸ், சைஃபரின் தொகுதி அல்லது சீரமைப்பு எல்லை வரை நிரப்புதல், இறுதிப் பகுதி மற்றும் ஒருமைப்பாடு சரிபார்ப்பு மதிப்பைச் சேர்க்கிறது. நெறிமுறை மற்றும் சைஃபரைப் பொறுத்து, உள் பாக்கெட் தொடங்குவதற்கு முன்பே மொத்தம் பத்துகள் பைட்டுகளில் வசதியாக அடையும்.

பின்னர் உள் பாக்கெட்டின் சொந்த தலைப்புகளுக்கு மீண்டும் கழிக்கவும். சுரங்கப்பாதைக்குள் உள்ள TCP பிரிவு அதன் சொந்த 20 பைட் IP தலைப்பையும் 20 பைட் TCP தலைப்பையும் சுமக்கிறது, TCP-இன் MSS MTU-இலிருந்து வருகிறது, சுரங்கப்பாதையின் பெயரளவு பேலோடிலிருந்து அல்ல. அதனால்தான் ping சிறிய பேலோடுடன் வெற்றிபெற முடியும் ஆனால் கோப்பு பரிமாற்றம் நின்றுபோகிறது: கருவிகள் வெவ்வேறு விஷயங்களைச் சோதிக்கின்றன, அவற்றில் ஒன்று மட்டுமே முழு அளவு TCP பிரிவைப் பயன்படுத்துகிறது.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

முதல் கட்டளை அமைக்கப்பட்ட சுரங்கப்பாதை MTU-ஐத் தெரிவிக்கிறது. இரண்டு ஆய்வுகளும் 1472 பைட் பேலோடை அனுப்புகின்றன, அது IPv4 மற்றும் ICMP தலைப்புகளின் 28 பைட்டுகளுடன் 1500 பைட் பாக்கெட்டாகும், பின்னர் சிறியது. பெரிய ஆய்வு முழுமையாகத் தோல்வியடைந்து சிறியது வெற்றிபெற்றால், உங்களுக்கு அளவைச் சார்ந்த குறைபாடு உள்ளது, பொதுவான வழிமாற்றல் சிக்கல் அல்ல.

மூன்றாவது கட்டுக்கதை: PPPoE இன்னும் உங்களுக்குத் தூய்மையான 1500 தருகிறது

வழக்கமான PPPoE அணுகல் இணைப்பு 1500 பைட் IP பாக்கெட்டைச் சுமக்கவில்லை. PPPoE தலைப்பும் PPP நெறிமுறை புலமும் ஈதர்நெட் சட்டகத்திற்குள் 8 பைட்டுகளை எடுத்துக்கொள்கின்றன, இது IP பாக்கெட்டுக்கு 1492-ஐ விட்டுச் செல்கிறது. இது RFC 2516-இல் விவரிக்கப்பட்ட பாரம்பரிய வரம்பு. அத்தகைய இணைப்பின் மேல் VPN இயக்கினால், சுரங்கப்பாதையின் கூடுதல் செலவு அந்த 1492-இலிருந்து வருகிறது, 1500-இலிருந்து அல்ல.

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

தோல்வி ஏன் தேர்ந்தெடுக்கப்பட்டதாகத் தோன்றுகிறது

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

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

என்ன மாற்ற வேண்டும், எந்த வரிசையில்

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

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