VPN இல்லாமல் Git நிற்கிறதா? OpenSSH IPQoS மூலம் பாக்கெட்டுகளைக் குறிக்கிறது
OpenSSH இயல்பாகவே தன் பாக்கெட்டுகளை QoS மதிப்பால் குறிக்கிறது. பாதை அந்தக் குறியை வீசும் இடத்தில், சுரங்கப்பாதை பாக்கெட்டுகள் செல்லும் பாதையை மாற்றும் வரை push நிற்கிறது.
அலுவலகத்திலிருந்து எடுத்த குளோன் வேலை செய்கிறது, தொலைபேசி ஹாட்ஸ்பாட் வழியாக அதே குளோன் வேலை செய்கிறது, ஆனால் ஹோட்டல் வலையமைப்பிலிருந்து அதே குளோன் VPN இயக்கப்படும் வரை தொங்குகிறது. SSH கைக்குலுக்கல் முடிந்து முதல் உண்மையான பரிமாற்றத்தில் அமர்வு அமைதியாகிறது. வாடிக்கையாளர் உள்ளமைவில் சேர்க்கப்படும் ஒரு வரி git மற்றும் ssh இரண்டையும் சேர்த்து குணப்படுத்துகிறது. ஒரு வாடிக்கையாளர் அமைப்பு பல கருவிகளை ஒரே நேரத்தில் சரிசெய்யும்போது, குறைபாடு வாடிக்கையாளர் அனுப்புவதில் உள்ளது, அது அனுப்பும் இணைப்பில் அல்ல.
அறிகுறியை பாதை வேறுபாடாகப் படியுங்கள்
ஒரு சிக்கலைக் குணப்படுத்தும் சுரங்கப்பாதை அரிதாகவே பழுதுநீக்கம். அது பாதை, கடத்தி மற்றும் இடைநிலை சாதனங்களை மாற்றுகிறது, மடிக்கணினி அதே பாக்கெட்டுகளை உருவாக்கிக்கொண்டே இருக்கிறது. ஒரு பாதை தலைப்பை தவறாகக் கையாண்டு மற்றொன்று அதை மாற்றமின்றி கடத்தினால், வேறுபாடு இடைநிலை சாதனத்தின் கொள்கையில் உள்ளது, வாடிக்கையாளரில் அல்ல. இங்கே சுரங்கப்பாதை சாட்சி, தீர்வு அல்ல.
அமர்வு இறக்கும் புள்ளி இதை மேலும் குறுக்குகிறது. பெயர் தேடலிலோ விசை பரிமாற்றத்திலோ தோல்வியடையும் எதுவும் இப்படித் தெரிவதில்லை. அங்கீகரித்து, பேனரை அச்சிட்டு, பின்னர் முதல் பெரிய எழுத்தில் உறைந்து நிற்கும் அமர்வு, பாதை, பெயர்கள் மற்றும் சான்றுகள் அனைத்தும் வேலை செய்கின்றன என்பதை ஏற்கனவே நிரூபித்துள்ளது.
வாடிக்கையாளர் ஒவ்வொரு SSH சாக்கெட்டிலும் QoS பைட்டைப் பதிக்கிறது
7.8 முதல் ஒவ்வொரு OpenSSH இணைப்பும் ரவுட்டர்கள் போக்குவரத்துக்கு முன்னுரிமை அளிக்கப் பயன்படுத்தக்கூடிய மதிப்பை IP தலைப்பில் கொண்டு செல்கிறது. முனைய அமர்வுகளுக்கு ஒரு மதிப்பும் பெரிய நகல்களுக்கு மற்றொன்றும் கிடைக்கின்றன, தட்டச்சு செய்யும் மனிதர் கோப்புப் பரிமாற்றத்தை விட சிறந்த நடத்தைக்குத் தகுதியானவர் என்ற கோட்பாட்டின் அடிப்படையில். பெரும்பாலான வலையமைப்புகள் இந்தக் குறிப்பை முழுமையாகப் புறக்கணிக்கின்றன, அதனால்தான் பல ஆண்டுகளாக இது கவனிக்கப்படாமல் போகிறது. சில Wi-Fi இயக்கிகள், மொபைல் ஆபரேட்டர்கள் மற்றும் VPN செறிவூட்டிகள் அதன்படி செயல்படுகின்றன, அவற்றில் சில மோசமாகச் செயல்படுகின்றன.
அந்த மதிப்பு ஓட்டத்தின் நடுவில் மீண்டும் எழுதப்படும்போது அல்லது வீசப்படும்போது, இணைப்பு தோல்வியடையாது, அது முன்னேறுவதை நிறுத்துகிறது. மறுசெலுத்தல்கள் அதிகரிக்கின்றன, சாளரம் சரிகிறது, எதுவும் பிழை தராததால் பயன்பாடு எதையும் தெரிவிக்கவில்லை. அந்த மௌனமே மக்கள் அறிகுறியை தோல்வி என்று அல்லாமல் தொங்குதல் என்று விவரிக்கக் காரணம்.
முதலில் ssh -V மூலம் வாடிக்கையாளர் பதிப்பை உறுதிப்படுத்துங்கள். 7.8 அல்லது அதற்கு மேற்பட்ட எந்தப் பதிப்பும் இந்த நடத்தையை இயல்பாகக் கொண்டுள்ளது.
இதை MTU மற்றும் DNS இலிருந்து பிரிக்கும் மூன்று கட்டளைகள்
எந்த உள்ளமைவு கோப்பையும் திருத்தும் முன் இரண்டு ஒத்த காரணங்களை விலக்க வேண்டும். MTU குறைபாடு சிறிய பரிமாற்றங்களைக் கடக்கவிட்டு முதல் பெரிய பாக்கெட்டில் உறைகிறது, ஆனால் பெயர் குறைபாடு ஒருபோதும் அமர்வை உருவாக்குவதில்லை.
ssh -o IPQoS=none -v [email protected]
ssh -G [email protected] | grep -i ipqos
sudo tcpdump -ni any -vv "tcp port 22"
முதல் கட்டளை குறியை அணைத்த நிலையில் தோல்வியடையும் செயலை மீண்டும் செய்கிறது, அதன் வெற்றிகரமான ஓட்டம் கிடைக்கக்கூடிய மிக வலுவான ஒற்றைச் சான்று. இரண்டாவது, வாடிக்கையாளர் அந்த இலக்கில் உண்மையில் பயன்படுத்தப்போகும் உள்ளமைவை அச்சிடுகிறது, இது மறந்துபோன கோப்பில் உள்ள பழைய உள்ளீட்டைப் பிடிக்கிறது. மூன்றாவது, பரிமாற்றம் சிக்கித் தவிக்கும்போது இரு திசைகளிலும் TOS பைட்டைக் காட்டுகிறது, சுவாரஸ்யமான வடிவம் என்பது உடைந்த பாதையில் மதிப்பு இருப்பதும் வேலை செய்யும் பாதையில் அது இல்லாததும் ஆகும்.
பிடிப்பை சேவையகத்தில் அல்ல, மடிக்கணினியில் செய்யுங்கள், ஏனெனில் மதிப்பை அமைப்பது அனுப்புபவர், இரு திசைகளும் அதை மாற்றலாம். வேலை செய்யும் பாதையையும் தோல்வியடையும் பாதையையும் ஒரே பிடிப்பில் ஒப்பிடுங்கள், ஊகமின்றி வேறுபாடு தெரியும்.
விதிவிலக்கை ஒரு கோப்பில் வையுங்கள், ஒரு நேரத்தில் ஒரு ஹோஸ்ட்
விதிவிலக்கு அது பொருந்தும் ஹோஸ்ட்டின் அருகில் இருக்க வேண்டும், அது ஏன் உள்ளது என்று கூறும் குறிப்புடன்.
Host gitlab.example.internal
IPQoS none
# direct route rewrites the marking; the tunnel route passes it
மதிப்பை விட எல்லை முக்கியம். வைல்ட்கார்டு உள்ளீடு நடத்தையை எல்லா இடங்களிலும் அணைக்கிறது, நல்ல நடத்தை உள்ள வலையமைப்புகளில் உதவும் குறிப்பை வீசுகிறது, அது எப்போது தோன்றியது என்று யாரும் சொல்ல முடியாதபடி செய்கிறது. ஒவ்வொரு ஹோஸ்ட்டுக்கான உள்ளீடு படிக்கக்கூடியது, மீளக்கூடியது, வலையமைப்பு சரிசெய்யப்பட்ட பிறகு அழிப்பது மிக எளிது. தனிப்பட்ட தீர்வுக்கு பயனர் கோப்பையும், முழு குழுவுக்கும் அதே விதிவிலக்கு தேவைப்படும்போது நிர்வகிக்கப்படும் கோப்பையும் பயன்படுத்துங்கள்.
விதிவிலக்கு எதை மறைக்கவில்லை என்பதைத் தெளிவாகச் சொல்லுங்கள். இது SSH க்கு பொருந்தும், எனவே HTTPS தொலைச் சேமிப்பு, தொகுப்பு கண்ணாடி மற்றும் உலாவி அனைத்தும் அதற்கு வெளியே உள்ளன, அவற்றில் ஏதேனும் தோல்வியடைந்தால் அதற்கு சொந்த சான்று தேவை. பாஸ்டியன் வழியாகச் செல்லும் சங்கிலியில் ஒவ்வொரு தாவலும் வாடிக்கையாளர் உள்ளமைவைப் பயன்படுத்துகிறது, சிக்கும் தாவலே வரம்பிடத் தகுந்தது.
வலையமைப்பு உரிமையாளருடன் வட்டத்தை மூடுங்கள்
கண்டுபிடிப்பை நான்கு உண்மைகளாக ஒப்படையுங்கள்: வாடிக்கையாளர் பதிப்பு, சோதித்த பாதை, பயன்படுத்தப்படும் VPN வாடிக்கையாளர், எந்தத் திசை குறியை எடுத்துச் சென்றது. இந்த நான்கும் வலையமைப்பு உரிமையாளருக்கு நடத்தையை மீண்டும் உருவாக்கி அது வேண்டுமென்றே செய்யப்பட்டதா என முடிவெடுக்க போதுமானது.
விதிவிலக்கு தொங்குதலைக் குணப்படுத்தவில்லை என்றால், அதை அகற்றுங்கள். தோல்வியடைந்த சோதனையிலிருந்து தப்பிய தீர்வு புராணக்கதையாக மாறும், அடுத்த நபர் அது எதுவும் செய்யவில்லை என நிரூபிக்க ஒரு மணி நேரம் செலவிடுவார். அது தொங்குதலைக் குணப்படுத்தினால், அந்தப் பாதை அதைக் கடக்கும் ஒவ்வொரு மற்ற கருவிக்கும் இன்னும் தவறானது, பழுதுநீக்கம் இடைநிலை சாதனத்தை இயக்குபவருக்கு உரியது.
வாடிக்கையாளரில் உள்ள மாற்றம் காலாவதி தேதியுடன் கூடிய தற்காலிக தீர்வு. அந்தத் தேதியைக் குறிப்பில் எழுதுங்கள்.