HTTP ப்ராக்ஸி வழியாக OpenVPN: முதலில் CONNECT பதிலைப் படியுங்கள்
CONNECT ப்ராக்ஸி பைட்டுகளை அனுப்புகிறது, எனவே இரு முனைகளுக்கும் TCP தேவை. சான்றிதழ்களைக் குற்றம் சாட்டும் முன் 407, 403 மற்றும் 503 படியுங்கள், சேவையக சரிபார்ப்பை இயக்கத்தில் வைத்திருங்கள்.
VPN கிளையண்டை நிறுவன HTTP ப்ராக்ஸிக்கு திருப்புங்கள், முதல் பயனுள்ள உண்மை என்னவென்றால் ப்ராக்ஸி VPN இன் நெறிமுறையைப் பேசுவதில்லை. நீங்கள் குறிப்பிட்ட முகவரிக்கு சாதாரண TCP இணைப்பைத் திறந்து பின்னர் பக்கமாக விலகி, உங்கள் கிளையண்டும் சேவையகமும் அந்த ஸ்ட்ரீம் வழியாக தங்கள் பரிமாற்றத்தைச் செய்கின்றன. கிளையண்டுக்குத் தேவையான அனைத்தும், போக்குவரத்து வகையிலிருந்து சேவையகத்தின் கேட்பான் வரை, அந்த ஏற்பாட்டுடன் பொருந்த வேண்டும். இரண்டு பொருந்தாமைகள் பெரும்பாலான தோல்விகளை விளக்குகின்றன: CONNECT ப்ராக்ஸியை நோக்கிய UDP சுயவிவரம், மற்றும் VPN பிழையாக தவறாகப் புரிந்துகொள்ளப்பட்ட ப்ராக்ஸி பதில்.
ப்ராக்ஸி எதைச் சுமக்கிறது, எதைச் சுமக்கவில்லை
ப்ராக்ஸி ஒரு போக்குவரத்து படி மட்டுமே. அது உங்கள் உலாவி ப்ராக்ஸியாக மாறாது, சுரங்கப்பாதை வழியாக நீங்கள் பார்வையிடும் தளங்களை தற்காலிகச் சேமிப்பில் வைக்காது, யாராவது வேண்டுமென்றே ஆய்வை அமைக்காவிட்டால் உள் போக்குவரத்தைப் பார்க்காது. அது திறக்கும் சுரங்கப்பாதை வடிவமைப்பின்படியே அதற்கு ஒளிபுகாதது.
இதன் பொருள், பொருந்தும் கேட்பான் இல்லாத சேவையகத்தை ப்ராக்ஸி சரிசெய்ய முடியாது. ஒரு இலக்கை அடையும் அனுமதியும் அந்த இலக்கில் கேட்கும் சேவையும் இரண்டு தனித்த உண்மைகள், முதல் ஒன்று மட்டுமே ப்ராக்ஸி நிர்வாகியிடம் உள்ளது.
கடத்தி இரு முனைகளிலும் TCP ஆக இருக்க வேண்டும்
வழக்கமான CONNECT ப்ராக்ஸி ஒரு பைட் ஸ்ட்ரீமை மட்டும் அனுப்புகிறது , எனவே கிளையண்ட் ஸ்ட்ரீம் போக்குவரத்தைப் பயன்படுத்த வேண்டும். அந்த நிலைக்கான கிளையண்ட் துண்டு இப்படித் தெரிகிறது:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128சேவையகப் பக்கம் remote வரியில் குறிப்பிட்ட துறையில் உண்மையான TCP கேட்பான் தேவை. சுயவிவரத்தில் proto udp ஐ proto tcp-client ஆக மாற்றுவது ஸ்ட்ரீமை எதிர்பார்க்கும் கிளையண்டை உருவாக்குகிறது; அது மறுபக்கத்தில் ஸ்ட்ரீமை உருவாக்காது. அதே சேவையகம் அந்தத் துறையில் UDP வழியாகவும் பதிலளித்தால், அது வேறு கேட்பான், அதே கேட்பானின் இரண்டாம் பயன்முறை அல்ல.
தனி TCP நிகழ்வு இருக்கும் இடத்தில், அதன் சுரங்கப்பாதை சாதனம், முகவரிக் கிடங்கு மற்றும் வழித்தடம் அதன் சொந்த வளங்கள். வேலை செய்யும் கட்டமைப்பை நகலெடுத்து போக்குவரத்துச் சொல்லை மாற்றினால் அந்த வளங்கள் மூல நிகழ்வையே சுட்டிக்காட்டும், இது அங்கீகாரம் பெற்று பின்னர் எதையும் வழித்தடம் செய்யாத இணைப்பை உருவாக்குகிறது.
VPN முடிவுக்கு முன் ப்ராக்ஸி பதிலைப் படியுங்கள்
கிளையண்டின் முதல் பரிமாற்றம் இலக்கு புரவலன் மற்றும் துறையைப் பெயரிடும் கோரிக்கை வரி. அந்த வரிக்கான பதில் பைட் ஸ்ட்ரீம் இருக்கிறதா என்பதைச் சொல்கிறது, மேலும் எந்தச் சான்றிதழும் அல்லது அடையாளச் சான்றும் சரிபார்க்கப்படுவதற்கு முன் வருகிறது:
CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194| Proxy reply | What it means | Where to look next |
|---|---|---|
407 Proxy Authentication Required | The proxy wants its own credentials | The client's proxy auth options, not the VPN account |
403 Forbidden | The destination or method is not permitted | The proxy's access policy for that host and port |
503 Service Unavailable | The proxy could not complete the upstream connection | The proxy's own logs and the server's listener |
CONNECT க்கு 200 வகுப்பு பதில் என்றால் ஸ்ட்ரீம் உள்ளது. நுழைவாயில் சான்றிதழ் நம்பகமானதா, பகிரப்பட்ட விசை பொருந்துகிறதா, அல்லது பயனர் கணக்கு செல்லுபடியாகிறதா என்பதை அது சொல்லாது. அந்தச் சரிபார்ப்புகள் பின்னர், ஸ்ட்ரீமுக்குள் நடக்கின்றன, அவை HTTP நிலை வரிக்குப் பதிலாக கிளையண்டின் சொந்தச் செய்திகளுடன் தோல்வியடைகின்றன. கிளையண்ட் பதிவில் முதல் OpenVPN நிகழ்வை ப்ராக்ஸி கைக்குலுக்கலுக்குப் பிறகு பாருங்கள், சாளரம் மூடுவதற்கு முன் இருந்த கடைசி வரியை அல்ல.
ப்ராக்ஸி அடையாளச் சான்றுகளும் VPN அடையாளச் சான்றுகளும் பெரும்பாலும் வெவ்வேறு குழுக்கள் வைத்திருக்கும் வெவ்வேறு அடையாளங்கள். 407 என்பது VPN கணக்கின் தவறான கடவுச்சொல் அல்ல, நிராகரிக்கப்பட்ட சான்றிதழ் ப்ராக்ஸி அனுமதிப் பிரச்சினை அல்ல.
CONNECT எதை வெளிப்படுத்தாது
வெளிப்படையான CONNECT சுரங்கப்பாதை ஒட்டுக்கேட்பு அல்ல. ப்ராக்ஸி பைட்டுகளை அனுப்புகிறது, VPN இன் TLS அமர்வை முடிவுக்குக் கொண்டுவராது, எனவே சேவையகச் சான்றிதழை கிளையண்ட் சரிபார்ப்பது அர்த்தமுள்ளதாகவே இருக்கும், இயக்கத்திலும் இருக்க வேண்டும். ப்ராக்ஸியைக் கடக்க சரிபார்ப்பை நிறுத்துவது உங்கள் பிரச்சினையிலிருந்து வேறுபட்ட பிரச்சினையைத் தீர்க்கிறது.
ஒரு நிறுவனம் வேண்டுமென்றே TLS ஐ முடித்து ஆய்வு செய்யும் தனி ஏற்பாடுகளும் உள்ளன. அவை அவற்றின் சொந்த நம்பிக்கை கட்டமைப்பையும் சொந்தக் கொள்கை முடிவையும் தேவைப்படுத்துகின்றன, சாதாரண http-proxy வரி கேட்பது அவை அல்ல.
TCP உள்ளே TCP இன் செலவு
சுரங்கப்பாதையை TCP மேல் கடத்துவது வெளி ஸ்ட்ரீமை வரிசையாகவும் மறுஅனுப்புதலுடனும் வைத்திருக்கிறது, உள் போக்குவரத்தும் பொதுவாக TCP. இரண்டு மீட்பு முறைகளும் ஒருங்கிணைவதில்லை, எனவே ஒரு இழந்த பிரிவு அந்த வெளி ஸ்ட்ரீமைப் பங்கிடும் அனைத்தையும் மறுஅனுப்பப்படும் வரை நிறுத்தலாம். இது இணக்கத்திற்கான உண்மையான பரிமாற்றம், இலவச மேம்பாடு அல்ல.
பிணையம் வேறு வழி விடாதபோது ப்ராக்ஸி பாதையைப் பயன்படுத்துங்கள், கொள்கை அனுமதிக்கும் இடத்தில் நேரடி UDP பாதையை விரும்புங்கள். எப்படியிருந்தாலும், மாற்றத்திற்குப் பின் அதே ப்ராக்ஸி, இலக்கு மற்றும் சுயவிவரம் அடுத்த கட்டத்தை அடைவதை உறுதிசெய்யுங்கள்; அந்த முகவரியில் பக்கத்தை ஏற்றும் உலாவி வேறு நெறிமுறையைப் பயன்படுத்துகிறது, சுரங்கப்பாதை பற்றி எதையும் நிரூபிக்கவில்லை.