PPPoE இல் OpenVPN: link-mtu, tun-mtu அல்லது mssfix குறைக்கலாமா?

பிங் பதிலளிக்கிறது, DNS தீர்க்கிறது, முழு அளவிலான பிரிவு தேவைப்படும் ஒவ்வொரு பக்கமும் நின்றுவிடுகிறது. தனது சொந்த காப்சுலேஷனைச் சேர்க்கும் இணைப்பில், பாதை அமைதியாக சில டஜன் பைட்டுகள் பட்ஜெட்டை இழக்கிறது, தூய்மையான Ethernet க்காக எழுதப்பட்ட சுயவிவரம் வரி தாங்க முடியாத பொதிகளைத் தொடர்ந்து கேட்கிறது. இணைப்பு மெதுவாக இல்லை; முக்கியமான பொதிகளையே அது தூக்கி எறிகிறது.

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

மூன்று குமிழ்கள், மூன்று வெவ்வேறு அடுக்குகள்

link-mtu வெளிப்புற பட்ஜெட்: மறைக்குறியிடப்பட்ட பேலோடுடன் OpenVPN தலைப்பு, UDP தலைப்பு மற்றும் வெளிப்புற IP தலைப்பு. இது இயந்திரத்திலிருந்து என்ன வெளியேறுகிறது என்பதை விவரிக்கிறது, அதனால்தான் இயற்பியல் பாதை கட்டுப்படுத்தும் எண் இதுவாகும்.

tun-mtu உள் பட்ஜெட்: உங்கள் போக்குவரத்து காணும் இடைமுகம். பாதை தாங்கக்கூடியதை விட சுரங்கப்பாதையின் மேலதிக செலவு அளவு இது பெரியது, மேலும் OpenVPN பொதுவாக அதை நீங்கள் அமைக்க கட்டாயப்படுத்துவதற்குப் பதிலாக அதைப் பெறுகிறது.

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

நீங்கள் link-mtu ஐ வெளிப்படையாக அமைத்தால், உள் MTU ஐப் பெற OpenVPN அதன் சொந்த மேலதிக செலவைக் கழிக்கிறது. அந்த செலவு நிலையான மாறிலி அல்ல; அது சைஃபர் மற்றும் அங்கீகாரத்தைப் பொறுத்தது, அதனால்தான் மன்றத்திலிருந்து நகலெடுக்கப்பட்ட மதிப்பு வேறு சுயவிவரத்தில் தவறாக இருக்கலாம். link-mtu மற்றும் tun-mtu இரண்டையும் அமைப்பது வாடிக்கையாளருக்கு இரண்டு முரணான அறிவுறுத்தல்களைத் தருகிறது.

எந்த எண்ணையும் தேர்ந்தெடுக்கும் முன் பாதையை அளவிடுங்கள்

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

Linux வாடிக்கையாளரில் ping -M do -s 1472 துண்டாக்கலைத் தடை செய்கிறது, பொதி மிகப் பெரியதாக இருந்தால் தோல்வியடைகிறது. அது கடக்கும் வரை பேலோடைக் குறைத்து, பின்னர் பாதையின் MTU ஐப் பெற 28 ஐச் சேர்க்கவும். PPPoE 8 பைட்டுகள் செலவாகும், எனவே DSL இல் 1492 சாதாரணம். DS-Lite மற்றும் சில மொபைல் பாதைகள் 40 அல்லது அதற்கு மேல் செலவாகும், பதில் பொதுவாக பெயரளவு இணைப்பு வேகம் குறிப்பதை விடக் குறைவாக இருக்கும்.

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

முதலில் TCP ஐக் கட்டுப்படுத்துங்கள், பின்னர் சுரங்கப்பாதையைச் சுருக்குங்கள்

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

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

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

சிறிய சோதனைகள் ஏன் தொடர்ந்து வேலை செய்கின்றன

DNS வினவல்கள், ICMP எதிரொலிகள் மற்றும் TCP கைக்குலுக்கல்கள் அனைத்தும் தோல்வியடையும் அளவை விட மிகக் குறைவு. எனவே சுரங்கப்பாதை ஒவ்வொரு விரைவு சோதனையிலும் ஆரோக்கியமாகத் தெரிகிறது, அதே நேரத்தில் TLS கைக்குலுக்கல்களும் HTTP பதில்களும் அமைதியாகத் தோல்வியடைகின்றன. அந்தக் கலவையே, வேலை செய்யும் traceroute மற்றும் முதல் பெரிய பதிலில் நிற்கும் உலாவி, தேட வேண்டிய அடையாளம். புதிய சுயவிவரத்தை நோக்கிச் செல்வதற்கு முன் முழு அளவு சோதனையை நோக்கிச் செல்லுங்கள்.

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

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