VPN வழியாக பாத் MTU கண்டறிதல்: அளவு மற்றும் ICMP இடைவெளி

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

பாத் MTU உண்மையில் எதை அளக்கிறது

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

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

சுரங்கப்பாதை பயன்படுத்தக்கூடிய பாக்கெட்டை ஏன் சுருக்குகிறது

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

நடைமுறை விளைவு கைக்குலுக்கலில் பொருந்தும் ஆனால் பேலோடில் பொருந்தாத அளவு. TLS ClientHello அல்லது DNS வினவல் சுருங்கிய பாதையைத் தொடாமல் கடக்கும் அளவுக்கு சிறியது, பெருமளவு பரிமாற்றம் அப்படி இல்லை. எனவே அறிகுறிகள் குறிப்பிட்ட ஹோஸ்ட்களைச் சுற்றி அல்ல, குறிப்பிட்ட செயல்பாடுகளைச் சுற்றி குவிகின்றன.

பின்னூட்டம் வந்தால் மட்டுமே கண்டறிதல் வேலை செய்கிறது

IPv4 கண்டறிதல் don't-fragment பிட்டை நம்பியுள்ளது: பாக்கெட்டை முன்னால் அனுப்ப முடியாத ரவுட்டர் அடுத்த ஹாப்பின் MTU-உடன் ICMP fragmentation-needed-ஐ திருப்புகிறது, அனுப்புநர் தன் மதிப்பீட்டைக் குறைக்கிறார். IPv6 அதற்கு பதிலாக Packet Too Big செய்திகளைப் பயன்படுத்துகிறது, ஏனெனில் ரவுட்டர்கள் போக்குவரத்தின் போது துண்டாக்குவதில்லை. இரண்டு முறைகளும் செய்தி அனுப்புநருக்கு திரும்பும் வழியைக் கண்டுபிடிக்கும் என்று கருதுகின்றன, சுரங்கப்பாதை வழியாகவும் திரும்பும் பாதையில் எந்த ஃபயர்வாலையும் கடந்தும். அந்த அனுமானம் தோல்வியடையும் போது, பாதை தாங்க முடியாத அளவை அனுப்புநர் திரும்பத் திரும்ப முயற்சிக்கிறார்.

echo request மற்றும் echo reply-ஐ அனுமதிக்கும் ஃபயர்வால் அந்த பிழை வகைகளையும் அனுமதித்திருக்க வேண்டியதில்லை. ICMP ஒரு குடும்பம், மேலும் இங்கு முக்கியமான உறுப்பினர்கள் பிழைகள், எக்கோ ஜோடி அல்ல. சுரங்கப்பாதையின் இரு முனைகளிலும் அவற்றுக்கிடையிலான பாதையிலும் கட்டுப்பாட்டு டிராஃபிக் கொள்கையைச் சரிபார்க்கவும், எல்லா இடங்களிலும் ஒவ்வொரு ICMP வகையையும் அனுமதிப்பதற்குப் பதிலாக தளத்தின் ஆதரவு வழிகாட்டலைப் பின்பற்றவும்.

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

எண்ணை ஊகிப்பதற்குப் பதிலாக பாதையைச் சோதிக்கவும்

இலக்கு, அணுகல் வலையமைப்பு மற்றும் சுரங்கப்பாதையை நிலையாக வைத்து, பாக்கெட் அளவை மட்டும் மாற்றவும். MTU குறிப்புடன் தோல்வியடையும் don't-fragment சோதனை அடுத்த ஹாப்பின் வரம்பை உங்களுக்குத் தருகிறது; ஒரு அளவு கடக்கும் வரை மீண்டும் செய்யவும், அளவு மற்றும் முகவரி குடும்பம் இரண்டையும் பதிவு செய்யவும்.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

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

RFC 4821-ல் விவரிக்கப்பட்ட PLPMTUD மேல்நோக்கிச் சோதித்து, வழங்கப்பட்ட பிழைகளை நம்புவதற்குப் பதிலாக போக்குவரத்து உறுதிப்படுத்தல்களைப் பயன்படுத்துகிறது. ICMP-ஐ வடிகட்டும் பாதைகளில் இது உதவுகிறது, ஆனால் ஆதரவு ஸ்டாக் மற்றும் பயன்பாட்டைப் பொறுத்து மாறுபடும். TCP ஓட்டம் தானாகவே மீளலாம், நிலையான டேட்டாகிராம் அளவு கொண்ட UDP பயன்பாடு தோல்வியடைந்து கொண்டே இருக்கும்.

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

பாதையை அறிந்த பிறகு சுரங்கப்பாதை MTU-ஐக் குறைப்பது கண்டறிதலும் சட்டபூர்வமான சரிசெய்தலும் ஆகும். எந்தப் பாதையும் எந்தப் பின்னூட்ட முறையும் ஈடுபட்டன என்பதை அறிவதற்கு இது மாற்றல்ல, ஏனெனில் மொபைல் இணைப்புக்கு ட்யூன் செய்யப்பட்ட மதிப்பு ஃபைபர் இணைப்பில் தேவையற்ற அளவு சிறியதாக இருக்கும். தேர்ந்தெடுத்த அளவு, அதை நியாயப்படுத்திய சோதனை மற்றும் ரோல்பேக் படிநிலையைப் பதிவு செய்யவும்.

IPv4 முறை RFC 1191-ல், IPv6 பாக்கெட்டாக்க வழிகாட்டல் RFC 8201-ல் விவரிக்கப்பட்டுள்ளது; இரண்டையும் குறிப்பிடுவது அடுத்த பொறியாளர் அனுமானத்தை மீண்டும் பெறாமல் தடுக்கிறது. நீங்கள் தேர்ந்தெடுத்த அளவில் பரிமாற்றம் இன்னும் நின்றால், எண்ணைக் குறைப்பதை நிறுத்திவிட்டு அடுத்த அடுக்கைப் பாருங்கள். ஒவ்வொரு அளவிலும் தோல்வியடையும் பாதை MTU சிக்கல் அல்ல.