வெப் மட்டும் கொண்ட நெட்வொர்க்கில் VPN தடுக்கப்பட்டதா? அடுக்குகளில் வேலை செய்யுங்கள்

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

எந்த அடுக்கு இணைப்பை நிராகரிக்கிறது என்பதை நிரூபியுங்கள்

VPN கிளையண்டில் தொடங்க வேண்டாம். அதே ஹோஸ்ட்டுக்கு எளிய HTTPS கோரிக்கையில் தொடங்கி நேரக் கட்டங்களைப் படியுங்கள், ஏனெனில் தோல்வியடையும் கட்டம் எந்த சாதனம் பொறுப்பு என்பதைச் சொல்கிறது:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

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

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

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

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

ப்ராக்ஸி அறிந்த கிளையண்ட் முதல் பாக்கெட்டை மாற்றுகிறது, கொள்கையை அல்ல

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

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

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

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

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

போர்ட் 443 அணுகக்கூடியது, அனுமதிக்கப்பட்டதல்ல

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

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

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

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

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

இயந்திரத்தை விட்டு உண்மையில் என்ன வெளியேறியது என்பதைச் சரிபாருங்கள்

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

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

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

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

பின்னடைவு, மற்றும் வைத்திருக்கத் தகுந்த குறிப்பு

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

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

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

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