Cloudflare ப்ராக்ஸி ஒரு பெயரில் OpenVPN-ஐ ஏன் எடுத்துச் செல்ல முடியாது
ப்ராக்ஸி செய்யப்பட்ட பதிவு HTTP மற்றும் HTTPS-ஐ கையாள்கிறது. பெயர்களைப் பிரிக்கவும், இரண்டு கேட்பவர்களை வைத்திருங்கள், ஒவ்வொரு இணைப்புக்கும் அதன் எதிர் தரப்பு உண்மையில் நம்பும் சான்றிதழைக் கொடுங்கள்.
ஒரு இயந்திரம் வலைத்தளத்தையும் OpenVPN சேவையகத்தையும் இயக்குகிறது, மேலும் ஒரு ஹோஸ்ட் பெயரை அதை நோக்கிக் காட்டி ஆரஞ்சு மேகத்தைப் போக்குவரத்தைச் சரிசெய்ய விடுவது சோதனை. ப்ராக்ஸி HTTP மற்றும் HTTPS-ஐச் சரிசெய்கிறது. அது OpenVPN அமர்வைச் சரிசெய்யாது, அந்த அமர்வு எந்த போர்ட்டைப் பயன்படுத்தினாலும். இரண்டு பெயர்கள், ஒன்று நேரடி மற்றும் ஒன்று ப்ராக்ஸி வழியாக, எதையும் செலவாக்காது மேலும் குழப்பத்தின் முழு வகுப்பையும் நீக்குகிறது.
இரண்டு பெயர்கள், இரண்டு போக்குவரத்துகள்
வலைத்தளத்திற்கு ப்ராக்ஸி செய்யப்பட்ட பதிவைக் கொடுங்கள், அதன் HTTP மற்றும் HTTPS போக்குவரத்து Cloudflare வழியாகச் செல்லும். VPN-க்கு DNS மட்டும் பதிவைக் கொடுங்கள், அது நேரடியாக பொது VPN நுழைவுக்குத் தீர்க்கப்படும், மேலும் வாடிக்கையாளர் அதற்கு அமைக்கப்பட்ட UDP அல்லது TCP போர்ட்டைப் பயன்படுத்தட்டும்.
இரண்டு பெயர்களும் ஒரே மூல இயந்திரத்தை அடையலாம். வேறுபாடு வாடிக்கையாளருக்கும் அந்த இயந்திரத்திற்கும் இடையே நடப்பதில் உள்ளது, அந்த வேறுபாடே பிரிப்பின் நோக்கம்.
Cloudflare-இன் பிணைய போர்ட் குறிப்பு சாதாரண வலை ப்ராக்ஸி எந்த போர்ட்டுகளை ஏற்கிறது என்பதைப் பட்டியலிடுகிறது. அந்தப் பட்டியல் அந்தப் போர்ட்டுகளில் HTTP மற்றும் HTTPS பற்றியது, ஒரே எண்ணைப் பங்கிடும் தன்னிச்சையான நெறிமுறைகள் பற்றியது அல்ல.
போர்ட் என்பது நெறிமுறை அல்ல
OpenVPN-ஐ TCP 443-க்கு நகர்த்துவது அதை HTTPS ஆக்காது. ப்ராக்ஸி இன்னும் இணைப்பின் தொடக்கத்தில் HTTP கோரிக்கையை எதிர்பார்க்கிறது, OpenVPN வாடிக்கையாளர் அதற்குப் பதிலாக இரும நிர்வாகச் செய்தியை அனுப்புகிறது. இணைப்பு பிணையத் தடையாகத் தோன்றும் வகையில் தோல்வியடைகிறது, ஏனெனில் பயனுள்ள எதுவும் பதிவை அடையவில்லை.
தேவை உண்மையில் VPN தரவுப் பாதையில் Cloudflare தயாரிப்பை வைப்பதாக இருந்தால், உங்களுக்குத் தேவையான நெறிமுறைக்கான ஆதரவை ஆவணப்படுத்தும் ஒன்றை மதிப்பிடுங்கள். ஆரஞ்சு மேகம் பொதுவான TCP அல்லது UDP சுரங்கம் என்று கருத வேண்டாம், ஏனெனில் அது குறிப்பிட்ட பணியுடன் கூடிய வலைப் போக்குவரத்துக்கான தலைகீழ் ப்ராக்ஸி.
DNS மட்டும் பதிவே வேலை செய்யும் சலிப்பான பதில், முதலில் அதை நோக்கியே கை நீட்ட வேண்டும்.
ஒரு இயந்திரத்திற்கு இன்னும் இரண்டு கேட்பவர்கள் தேவை
தனித்த பெயர்கள் இரண்டு செயல்முறைகள் ஒரே நேரத்தில் ஒரே முகவரி, போர்ட் மற்றும் போக்குவரத்தைப் பிணைக்க அனுமதிக்காது. வலை சேவையகம் ஏற்கனவே எல்லா முகவரிகளிலும் TCP 443-ஐ வைத்திருந்தால், OpenVPN நிகழ்வு வேண்டுமென்றே செய்யப்பட்ட ஏற்பாடு இல்லாமல் அதையும் எடுக்க முடியாது.
VPN கேட்பவரை வேறு போர்ட்டில், அல்லது வேறு முகவரியில் பிணைக்கவும், அல்லது முன்னே ஆவணப்படுத்தப்பட்ட மல்டிபிளெக்சரை வைத்து அதனுடன் வரும் இயக்கச் செலவை ஏற்றுக்கொள்ளுங்கள். அந்தத் தேர்வுகள் ஒவ்வொன்றும் ஃபயர்வால் விதிகளில் தெரிய வேண்டும், ஏனெனில் யாரும் ஆவணப்படுத்தாத கேட்பவரே சம்பவத்தின் போது தவறவிடப்படுகிறார். தேர்ந்தெடுத்த பிணைப்பை சுரங்கத்தை விவரிக்கும் அதே ரன்புக்கில் எழுதுங்கள். அப்போது அடுத்த நபர் இரவு இரண்டு மணிக்கு அதை மீண்டும் கண்டுபிடிக்க வேண்டியிருக்காது.
சான்றிதழ்கள் அவை பாதுகாக்கும் இணைப்பைப் பின்தொடர்கின்றன
உலாவியின் Cloudflare-க்கான TLS இணைப்பும் Cloudflare-இன் உங்கள் மூலத்திற்கான இணைப்பும் இரண்டு தனித்த சான்றிதழ்களுடன் இரண்டு தனித்த உறவுகள். உலாவி விளிம்புச் சான்றிதழைப் பார்க்கிறது. மூலம் தன் சான்றிதழை Cloudflare-க்கு வழங்குகிறது, Cloudflare Origin CA சான்றிதழ் சரியாக அந்த இரண்டாவது உறவுக்கே உரியது.
அந்த மூலச் சான்றிதழை Cloudflare Full (strict) பயன்முறையில் நம்புகிறது, அது பொதுவாக நம்பகமான உலாவி சான்றிதழ் அல்ல. யாரேனும் DNS மட்டும் ஹோஸ்ட் பெயருக்கு நேரடியாகச் சென்று எச்சரிக்கையைப் பெற்றால், அது மாறிய நம்பிக்கைப் பாதையின் எதிர்பார்க்கப்பட்ட விளைவு, குறியாக்கம் நின்றதற்கான சான்று அல்ல.
எனவே நேரடியாகப் பார்வையிடப்படும் வலைத்தளத்திற்கு அதன் உலாவிகள் நம்பும் சான்றிதழ்ச் சங்கிலி தேவை. அது மூலத்தைப் பார்வையிடவே முடியாது என்று கருதப்படும் ப்ராக்ஸி செய்யப்பட்ட தளத்துடன் சேர்ந்து இருக்கலாம்.
OpenVPN தன் சேவையக அடையாளத்தையும் வாடிக்கையாளர் அங்கீகாரத்தையும் தன் சான்றிதழ் அதிகாரம் மற்றும் தன் கட்டுப்பாட்டு சேனல் பாதுகாப்புடன் எடுத்துச் செல்கிறது. வலைத்தளத்தின் பூட்டு அவற்றில் எதையும் தராது, மேலும் இரண்டு வழங்கல் செயல்முறைகளும் தனித்திருக்க வேண்டும்.
வெளிப்பாடு பெயரைப் பின்தொடர்கிறது
DNS மட்டும் VPN பதிவு அது சுட்டும் முகவரியை வெளியிடுகிறது. அந்த முகவரி வலை மூலமாகவும் இருந்தால், மூலம் மறைக்கப்படவில்லை, மற்ற பெயர் ப்ராக்ஸி என்பதால் அதை மறைக்கப்பட்டதாக விவரிப்பது யாரேனும் ஸ்கேன் செய்யும் வரை நீடிக்கும் தவறு.
எந்த வலைக் கோரிக்கைகள் மூலத்தை நேரடியாக அடையலாம் என்பதை முடிவு செய்து அதை மூலத்தில் நடைமுறைப்படுத்துங்கள், பின்னர் VPN கேட்பவரை அதன் சொந்த நிபந்தனைகளில் அனுமதிக்கவும். நிர்வாகப் பக்கங்கள், சுயவிவரப் பதிவிறக்கங்கள் மற்றும் தரவுக் கேட்பவர் ஆகியவை ஒரு தொகுப்பு மூன்றையும் வழங்கினாலும் மூன்று வெவ்வேறு வெளிப்பாட்டுத் தேவைகளைக் கொண்டிருக்கலாம்.
உருவாக்கப்பட்ட இணைப்புகளைப் பொது வலைப் பெயரிலும் HTTPS திட்டத்திலும் வைத்திருங்கள், வாடிக்கையாளர் சுயவிவரங்களை VPN பெயரில் உண்மையான நெறிமுறை மற்றும் போர்ட்டுடன் வைத்திருங்கள். சாதாரண செயல்பாட்டில் எந்தச் சேவையும் மற்றொன்றின் ப்ராக்ஸி அமைப்பை மாற்றுவதைச் சார்ந்திருக்கக் கூடாது.
வேலையின் வரிசை: தளத்திற்கு ப்ராக்ஸி செய்யப்பட்ட பெயர், VPN-க்கு DNS மட்டும் பெயர், தனித்த கேட்பவர்கள், ஒவ்வொரு உறவுக்கும் சான்றிதழ், பின்னர் ஒவ்வொரு பெயரும் அது செல்ல வேண்டிய சேவையை மட்டுமே அடைகிறது என்பதை நிரூபிக்கும் ஒரு சோதனை.