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

ஒவ்வொரு குடும்பமும் என்ன செய்கிறது

அட்டவணை நான்கு வரிகளில் உள்ள பொறிமுறை, ஒரு வரி பெரும்பாலான குழப்பத்தை விளக்குகிறது.

BehaviourIPv4IPv6
Router fragments an oversized packetAllowed while DF is clearNever
Signal returned to the senderICMP Fragmentation NeededICMPv6 Packet Too Big
Size that must always work68 bytes1280 bytes
Fragmentation possibleRouters or sourceSource only

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

சுரங்கப்பாதை பாதையை அமைதியாகக் குறுக்குகிறது

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

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

அறிகுறி ஏன் தேங்கிவிட்டதாகத் தோன்றுகிறது

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

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

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

எல்லையை அளந்து, பின்னர் அடுக்கைச் சரிசெய்யுங்கள்

ஊகிக்காமல் சரிபார்க்கவும்: IPv4 இல் don't-fragment கொடியையும் IPv6 இல் நிலையான பேலோடு அளவுகளையும் பயன்படுத்தி, பதில்கள் எங்கு நிற்கின்றன என்பதைப் பதிவு செய்யுங்கள். ping -M do -s 1472 மற்றும் ping -6 -s 1400 சிக்கலின் வடிவத்தைத் தீர்மானிக்க போதுமானவை, மேலும் tracepath வழியில் கண்டறியப்பட்ட பாதை MTU ஐ அறிவிக்கிறது.

பின்னர் அந்த எண்ணைக் கொண்ட அடுக்கைச் சரிசெய்யுங்கள்: சுரங்கப்பாதை இடைமுகத்தின் MTU, TCP க்கான MSS இறுக்கம், அல்லது பாதையே. IPv6 விதிக்கான குறிப்பு RFC 8200, அது தடுக்கும் சம்பவத்தை விடச் சிறிய வாசிப்பு.

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

அளவு எல்லையை சான்றாகக் கருதுங்கள்

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

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

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