OpenVPN 443 இல் இன்னும் தடுக்கப்பட்டுள்ளதா? நெட்வொர்க் எதைப் பரிசோதிக்கிறது எனப் பாருங்கள்

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

கைகுலுக்கல் எண்ணை விட அதிகம் காட்டுகிறது

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

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

பாய்வை உறையிடுவது இரண்டு தோல்விப் புள்ளிகளை உருவாக்குகிறது

stunnel போன்ற TLS உறை எதிர்பார்க்கப்பட்ட வடிவத்தை மீட்டெடுக்கிறது: வாடிக்கையாளர் உள்ளூர் கேட்பானுடன் இணைகிறார், உறை சேவையகத்துடன் 443 இல் உண்மையான TLS அமர்வைத் திறக்கிறது, சேவையகத்தில் உள்ள இரண்டாவது உறை மறைகுறியாக்கப்பட்ட பைட்டுகளை VPN டீமானுக்கு அனுப்புகிறது. வெளி அமர்வு இப்போது வேறு எந்த HTTPS இணைப்பையும் போலத் தெரிகிறது. சேவையகத்தின் VPN டீமான் loopback இல் மட்டும் கேட்க வேண்டும், ஏனெனில் உறைக்கு வெளியே எதுவும் அதை அடைய வேண்டியதில்லை.

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

உறைக்குச் செல்லும் பாதையே பொறி

சுரங்கம் மேலே வந்ததும் இயல்புநிலை பாதை அதற்குள் சுட்டுகிறது, வெளி TLS அமர்வுக்கு அது சுமக்கும் சுரங்கத்திற்குள் செல்லாத வழி தேவை. சாதாரண VPN வாடிக்கையாளர் தான் அழைக்கும் முகவரியைப் பாதுகாக்கிறார்; உறைக்கப்பட்ட வாடிக்கையாளர் தன் loopback ஐ அழைக்கிறார், எனவே உறையின் இலக்கு முகவரி அந்தப் பாதுகாப்பிற்கு கண்ணுக்குத் தெரியாது.

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

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

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

எதையும் மாற்றும் முன் நேரத்தைப் படியுங்கள்

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

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

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

ஒரு நேரத்தில் ஒரு மாறியைச் சோதியுங்கள்

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

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