TCP மீட்டமைப்பு உங்கள் VPN தடுக்கப்படுகிறது என்பதை நிரூபிக்காது

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

மீட்டமைப்பு ஒரு பொதி, தீர்ப்பல்ல

TCP மீட்டமைப்புச் செயலாக்கத்தை வரையறுக்கிறது: RST கொடியுள்ள பகுதி இணைப்பை உடனடியாக முடிக்கிறது. பெறுநர் பேச்சுவார்த்தை செய்யாது, மீண்டும் முயற்சிக்காது, ஏன் என்று கேட்காது. அது மீட்டமைப்பைத் தெரிவித்துவிட்டு முன்னேறும்.

கிளையண்டுக்குத் தெரிந்தது அவ்வளவே. RST சேவையகத்திலிருந்து, ப்ராக்ஸியிலிருந்து, ஃபயர்வாலிலிருந்து அல்லது நிலையை இழந்த சுமை சமநிலைப்படுத்தியிலிருந்து வந்திருக்கலாம்.

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

எந்த இணைப்பு மீட்டமைக்கப்பட்டது என்பதை உறுதிப்படுத்துங்கள்

முதலில் செயலில் உள்ள சுயவிவரம் உண்மையில் TCP-ஐப் பயன்படுத்துகிறதா என்று பாருங்கள். UDP சுரங்கப்பாதையில் மீட்டமைப்புக்கு அர்த்தமில்லை, HTTP ப்ராக்ஸியின் பதிவு VPN-ஐ விட வேறு TCP பகுதியைப் பற்றியதாக இருக்கலாம்.

இலக்கு, துறைமுகம், முயற்சியின் நேரம் மற்றும் கிளையண்ட் அடைந்த நிலையைப் பதிவு செய்யுங்கள்.

நிலைதான் மிகவும் பயனுள்ள புலம். TLS கைக்குலுக்கலின் போது ஏற்படும் மீட்டமைப்பு ஒரு குழு சந்தேகத்திற்குரியவர்களைக் காட்டுகிறது; அங்கீகாரத்திற்குப் பின் ஏற்படும் மீட்டமைப்பு மற்றொன்றைக் காட்டுகிறது. நிலை இல்லாமல் ஒவ்வொரு கோட்பாடும் பொருந்தும்.

பாதையின் இரு முனைகளையும் ஒப்பிடுங்கள்

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

முடிந்தால் கிளையண்டிலும் சேவையகத்திலும் பிடியுங்கள். கிளையண்டில் தெரிந்து சேவையகத்தில் தெரியாத மீட்டமைப்பு சேவையகத்தில் தோன்றவில்லை.

இரு திசைகளிலும் RST பகுதிகளைக் கவனியுங்கள்:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

கட்டுப்படுத்தப்பட்ட ஒப்பீட்டால் சுருக்குங்கள்

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

இது இன்னும் ஒரு குறிப்பிட்ட இடைநிலைச் சாதனத்தை அடையாளம் காட்டவில்லை. எல்லையை ஒரு வழித்தடத்திற்குச் சுருக்குகிறது, அது பயனுள்ளதும் நேர்மையானதுமான முடிவு.

“இந்தப் பாதை தோல்வியடைகிறது” என்பதற்கும் “இந்தப் பெயரிடப்பட்ட செயலி அதை ஏற்படுத்தியது” என்பதற்கும் இடையிலான வேறுபாட்டைக் காப்பாற்றுங்கள். முதலாவது சோதிக்கக்கூடியது; இரண்டாவது பொதுவாக ஒரு கிளையண்டிலிருந்து இல்லை.

நம்பிக்கை அமைப்புகளை மாற்றாமல் திருத்தத்தைச் சரிபாருங்கள்

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

அடையாளம் காணப்பட்ட கூறை அதன் உரிமையாளர் மூலம் சரிசெய்து, பின்னர் அதே சுயவிவரத்தையும் அதே கவனிப்பையும் மீண்டும் செய்யுங்கள்:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

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