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

இரண்டு தலைமுறைகள், இரண்டு இணைப்பு வரிசைகள்

2.8 வரை நடைமுறையில் உள்ள பழைய வடிவமைப்பில், இறக்குமதி செய்யப்பட்ட கோப்பு ஒரு போலி சுயவிவரம். OpenVPN Connect அதை HTTPS வழியாக Access Server இன் வலை API முன் அங்கீகரிப்பதற்குப் பயன்படுத்துகிறது, தற்காலிக பயனர் பூட்டப்பட்ட சுயவிவரத்தையும் அமர்வு டோக்கனையும் பெற்று, அதன் பின்னரே VPN ஐ நிறுவுகிறது. இரண்டு போக்குவரத்துகள் வரிசையாக இயங்குகின்றன, முதலாவது சாதாரண வலைக் கோரிக்கை.

2.9 உடன் அறிமுகப்படுத்தப்பட்ட வடிவம் அந்த இணைப்புக்கான தொடக்கத்தைச் செய்யாது. இது இணக்கமான OpenVPN வாடிக்கையாளர்கள் பயன்படுத்தக்கூடிய சொந்த சுயவிவரம், OpenVPN Connect மட்டுமல்ல. அதைப் பதிவிறக்குவது அல்லது URL வழியாக இறக்குமதி செய்வது இன்னும் HTTPS ஐ உள்ளடக்கலாம் — அது வெளியீட்டு படி, ஒவ்வொரு இணைப்புக்கும் தற்காலிக சுயவிவரத்தைப் பெறுவது அல்ல.

Older server-locked (≤2.8)Newer server-locked (2.9+)
Before the tunnelWeb API call with credentialsNothing; the profile is already local
Client requirementOpenVPN ConnectAny compatible client
What a TLS web proxy can breakThe bootstrap, before any VPN attemptDownload only, not the connection
Expected HTTP log on connectA request from the clientOften nothing at all

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

உங்கள் கிளையைத் தேர்ந்தெடுக்கும் மூன்று நிபந்தனைகள்

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

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

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

உருவாக்கம் பழையதாக இருக்கும்போது: தொடக்கம் முதலில் தோல்வியடைகிறது

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

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

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

உருவாக்கம் புதியதாக இருக்கும்போது: அதற்குப் பதிலாக கட்டுப்பாட்டு சேனலைப் படியுங்கள்

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

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

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

குறுகியதாக இருக்கும் தீர்வுகள்

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

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

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

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

தொடர்புடைய கட்டுரைகள்