Linux இல் ஒவ்வொரு வழிக்கும் MTU: மூன்று அளவு கட்டுப்பாடுகள், ஒரு வழி
இடைமுக MTU, வழி MTU மற்றும் MSS வரம்பு வெவ்வேறு அடுக்குகளில் செயல்படுகின்றன. தேடலை வெல்லும் வழிக்கு பட்ஜெட்டை இணைத்து, மாற்றத்தை மீளக்கூடியதாக வைத்திருங்கள்.
Linux கிளையண்டில் மூன்று அமைப்புகளும் «பாக்கெட்டுகளை சிறியதாக்கு» எனக் கேட்கின்றன, அவை வெவ்வேறு அடுக்குகளில் செயல்படுகின்றன. இடைமுக MTU சாதனம் அனுப்பும் ஒவ்வொரு பாக்கெட்டையும் வரம்பிடுகிறது. வழி MTU அந்த வழியைப் பயன்படுத்தும் பாக்கெட்டுகளை வரம்பிடுகிறது, ஒரு VPN இலக்கிற்கு நீங்கள் உண்மையில் விரும்புவது பெரும்பாலும் அதுவே. TCP MSS வரம்பு இரு முனைகளும் பேசுவதை மாற்றுகிறது, UDP க்கு எதுவும் செய்யாது.
ஒரே குமிழ் போலத் தோன்றும் மூன்று கட்டுப்பாடுகள்
தேர்ந்தெடுப்பதற்கு முன் அவற்றை அருகருகே வையுங்கள், ஏனெனில் தவறான வரிசையைத் தேர்ந்தெடுப்பதே வேலை செய்யாத பெரும்பாலான ஆலோசனைகளுக்கு விளக்கம்:
| Control | Scope | What it cannot fix |
|---|---|---|
| Interface MTU | Every packet the device sends | Nothing, but it over-constrains unrelated traffic |
| Route MTU | Packets using that route | A send that the lookup never routes there |
| MSS clamp | TCP handshake on that path | UDP payload sizes and ICMP |
முழு இயந்திரத்திற்கும் Ethernet MTU ஐக் குறைப்பது இந்தத் திருத்தத்தின் முரட்டு வடிவம். இது வேலை செய்கிறது, மேலும் ஹோஸ்ட்டில் உள்ள மற்ற ஒவ்வொரு பயன்பாட்டையும் தண்டிக்கிறது, பாதைகள் சரியாக இருந்தவையும் உட்பட. ஒவ்வொரு வழிக்குமான மதிப்பு அதே நோக்கத்தை பக்கச் செலவின்றி வெளிப்படுத்துகிறது.
ஒப்பீடு ஹோஸ்ட் தானே உருவாக்கும் டிராஃபிக்கிற்கு மட்டுமே செல்லுபடியாகும். மற்றொரு கிளையண்டுக்கு பாக்கெட்டை அனுப்புவது அவரது சொந்த பாதையையும் சுரங்கப்பாதையின் வெளிப்புற பட்ஜெட்டையும் உள்ளடக்குகிறது, இந்த ஹோஸ்ட்டின் வழி மெட்ரிக் அந்த எல்லையைத் தாண்டாது.
தேடலை வெல்லும் வழிக்கு பட்ஜெட்டை இணையுங்கள்
ஒரு எடுத்துக்காட்டு IPv4 வழி பதிவு இப்படித் தோன்றும்:
ip -4 route get 10.60.0.20
ip -4 route add 10.60.0.0/16 dev tun-office src 10.90.0.2 mtu 1380பதிவை ஒட்டுவதற்கான மதிப்பாக அல்ல, நோக்கத்தின் விவரணையாகப் படியுங்கள். முன்னொட்டு, சாதனம் மற்றும் விருப்பமான மூலம் உண்மையான உள்ளமைவுடன் பொருந்த வேண்டும், மேலும் எண் வலைப்பதிவிலிருந்து அல்ல, மூடப்பட்ட பாதை பற்றிய சான்றிலிருந்து வர வேண்டும். வழி MTU உள் IP பாக்கெட்டை வரம்பிடுகிறது, அது 1380 பைட் TCP சுமை அல்லது 1380 பைட் மறையாக்கப்பட்ட வெளிப்புற பாக்கெட் அல்ல.
எதையும் சேர்ப்பதற்கு முன் தேடல் உண்மையில் எங்கு தீர்க்கப்படுகிறது எனப் பாருங்கள். கொள்கை விதிகளைக் கொண்ட ஹோஸ்ட் ஒரு இலக்கை main தவிர வேறு அட்டவணை வழியாக வழிமாற்றலாம், மேலும் main அட்டவணையில் மட்டுமே உள்ள மெட்ரிக் அந்தக் கோரிக்கைக்குத் தெரியாது. ஒப்பிடுங்கள் ip -4 route show table all மற்றும் ip route get பதிலை, விதிகள் பயன்படுத்தும்போது குறி அல்லது பெயர்வெளி சூழலுடன். இரண்டும் பொருந்தவில்லை என்றால், மெட்ரிக் தேவைப்படுவது பதிலளித்த அட்டவணைக்கே, மிகச் சுத்தமாகத் தெரிவதற்கல்ல.
mtu என்பது mtu lock அல்ல
இயல்பாக கர்னல் ICMP பின்னூட்டத்திலிருந்து பாதை MTU ஐ இன்னும் புதுப்பிக்க முடியும், பாதை MTU கண்டறிதல் அதற்கே. lock சேர்ப்பது அதை நிறுத்துகிறது. இது வேறு முடிவு, அதே எண்ணைக் காப்பாற்றும் வலிமையான வழி அல்ல, IPv4 க்கு இது «துண்டிக்க வேண்டாம்» பிட்டின் ஆவணப்படுத்தப்பட்ட கையாளுதலை மாற்றுகிறது.
பாதையை அளந்து, எது வந்தாலும் மதிப்பு நிலையாக இருக்க வேண்டுமெனில் பூட்டுவது நியாயம். நெட்வொர்க் செல்லுபடியான அளவு பின்னூட்டத்தை அனுப்பும்போது இது மோசமான இயல்புநிலை, ஏனெனில் கர்னலால் இனி சரிசெய்ய முடியாது, தோல்வி வேறு அறிகுறிக்கு நகர்கிறது.
பாதையில் எங்காவது ICMP வடிகட்டப்பட்டால், எந்த வழி அமைப்பும் அதைச் சரிசெய்யாது. திருத்தம் வடிகட்டிக்கு உரியது, சிறிய MTU அடுத்த பாதை மாற்றம் வரை உண்மையான குறையை மறைக்கும் தற்காலிக வழி.
சுரங்கப்பாதை மென்பொருள் அதன் சொந்த அளவு குமிழ்களைச் சேர்க்கிறது
OpenVPN- mssfix அதன் ஆவணப்படுத்தப்பட்ட UDP சுரங்கப்பாதை நிலைக்கு TCP பிரிவு அளவைச் சரிசெய்கிறது. இது TCP உரையாடலில் செயல்படுகிறது, எனவே இது இயக்க முறைமையின் வழி MTU வின் மற்றொரு எழுத்துக்கூட்டல் அல்ல, பேச்சுவார்த்தையை புறக்கணிக்கும் UDP சேவைக்கு உதவ முடியாது.
ஒரே மாற்ற சாளரத்தில் வழி MTU, இடைமுக MTU மாற்றம் மற்றும் MSS வரம்பை ஒன்றாக வைக்க வேண்டாம். சிக்கல் மறைந்தால் எது முக்கியம் என்று தெரியாது, வைத்திருப்பவை பல ஆண்டுகள் டிராஃபிக்கை வரம்பிடும், யாரும் நினைவில் வைத்திராத காரணத்துடன்.
அதை மீளக்கூடியதாக்குங்கள், பின்னர் நிரூபியுங்கள்
வழியின் உண்மையான உரிமையாளர் மறு-இணைப்புக்குப் பிறகு மாற்றம் நீடிக்குமா என்பதை முடிவு செய்கிறார். வழியை இயக்கவியலாக நிறுவும் VPN கிளையண்ட் வழக்கமாக உங்கள் மெட்ரிக் இல்லாமல் அதை மீண்டும் கட்டமைக்கும், கைமுறை ip route add பின்னர் ஒரு நாள் கழித்து தோல்வியடைந்த திருத்தம் போலத் தெரிகிறது. மதிப்பை மேலாளரின் உள்ளமைவில் வையுங்கள், தற்காலிக சோதனை தேவைப்பட்டால் முதலில் அசல் வழியைப் பதிவு செய்யுங்கள்.
நின்றுபோன செயல்பாட்டைச் செய்யும் புதிய இணைப்புடன் சோதியுங்கள், பின்னர் நோக்கமான தனிப்பட்ட வழி இன்னும் வெல்கிறது எனவும் தொடர்பற்ற இலக்குகள் மாறவில்லை எனவும் உறுதிப்படுத்துங்கள். சுரங்கப்பாதையை மீண்டும் இணைத்து வழியை மீண்டும் படியுங்கள், ஏனெனில் மறு-இணைப்பில் மறையும் மதிப்பு திருத்தம் அல்ல.
சான்று மாற்றத்தை ஆதரிக்கவில்லை என்றால், மேலெழுதலை அதன் மேலாளர் மூலம் அகற்றி, வழியை நீக்குவதற்குப் பதிலாக அசல் வழி பண்புகளை மீட்டெடுங்கள். பின்னர் எதை அளந்தீர்கள், எந்தப் பாதையில் என்பதை எழுதுங்கள், அடுத்த நபர் உண்மையான மேம்பாட்டை இயக்கத்தில் விடப்பட்ட சோதனையிலிருந்து வேறுபடுத்த முடியும்.