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

சுயவிவரம் கொள்கை அல்ல

Community OpenVPN 2.6 கட்டாய வாடிக்கையாளர் சான்றிதழ்களுடன் வருகிறது, ஏனெனில் verify-client-cert இயல்பாக require ஆகும். அதை none ஆக அமைப்பதே சான்றிதழின் கோரிக்கையை நிறுத்தி, வாடிக்கையாளர் அங்கீகாரத்தை சேவையகம் ஏற்கனவே இயக்கும் பயனர்பெயர் மற்றும் கடவுச்சொல் ஏற்பாட்டிற்கு ஒப்படைக்கிறது. பழைய வழிகாட்டிகள் அதே கருத்தின் பழைய எழுத்துப்பிழையான client-cert-not-required ஐ நோக்கிச் செல்கின்றன, எனவே உங்கள் நிறுவப்பட்ட பதிப்பு ஆவணப்படுத்தும் உத்தரவைப் பயன்படுத்துங்கள். எப்படியிருந்தாலும் மாற்றம் சேவையகத்தில் நிகழ்கிறது, எந்த வாடிக்கையாளர் சுயவிவரமும் அதைச் செய்ய முடியாது.

கீழே உள்ள பகுதி சேவையகப் பக்கத்தின் முழு மாற்றம், தனியாக அது செயல்படும் அங்கீகார உள்ளமைவு அல்ல. verify-client-cert none சான்றிதழ் தேவையை நீக்குகிறது, அதேசமயம் username-as-common-name கணக்கின் பெயரை பின்னர் வரும் அழைப்புகளும் ஒவ்வொரு வாடிக்கையாளரின் கோப்புகளும் காணும் அடையாளமாக மாற்றுகிறது. எந்த வரியும் கடவுச்சொல்லைச் சரிபார்க்கவில்லை, எனவே சரிபார்ப்பான் இன்னும் இருக்க வேண்டும்.

verify-client-cert none
username-as-common-name

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

சேவையகத்தை இன்னும் எது சரிபார்க்கிறது

வாடிக்கையாளர் சான்றிதழை விட்டுவிடுவது TLS ஐ விட்டுவிடுவது அல்ல. சேவையகம் தன் சான்றிதழையும் விசையையும் வைத்திருக்கிறது, வாடிக்கையாளர் CA நம்பிக்கையையும், மோசடியாளருடன் பேசுவதைத் தடுக்கும் புரவலன் பெயர்ச் சரிபார்ப்புகளையும் வைத்திருக்கிறார். வாடிக்கையாளரிடம் இனி சான்றிதழ் இல்லை என்பதால் remote-cert-tls server அல்லது CA தொகுப்பை நீக்குவது பொதுவானதும் தீவிரமானதுமான தவறான வாசிப்பு, 2.6 குறிப்பு இரு திசைகளும் சுயாதீனமானவை என்பதை வெளிப்படையாகக் கூறுகிறது. ஒன்று சேவையகத்தை வாடிக்கையாளருக்கு நிரூபிக்கிறது; மற்றொன்று வாடிக்கையாளரை சேவையகத்திற்கு நிரூபிக்கிறது.

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

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

சரிபார்ப்பான் என்ன செய்ய வேண்டும்

சான்றிதழ்த் தேவை நீக்கப்பட்ட பிறகு எல்லாம் சரிபார்ப்பானைச் சார்ந்துள்ளது: ஒரு செருகி, அல்லது auth-user-pass-verify ஆல் இயக்கப்படும் ஸ்கிரிப்ட். அது தவறான சான்றுகளை நிராகரிக்க வேண்டும், முடக்கப்பட்ட அல்லது தகுதியற்ற கணக்குகளை நிராகரிக்க வேண்டும், அதன் பின்தளத்தை அடைய முடியாதபோது மூடிய நிலையில் தோல்வியடைய வேண்டும். username-as-common-name பெரும்பாலும் பக்கத்தில் செயல்படுத்தப்படுகிறது, அது பின்னர் வரும் அழைப்புகளும் ஒவ்வொரு வாடிக்கையாளரின் உள்ளமைவு கோப்புகளும் காணும் அடையாளத்தை மாற்றுகிறது. அது கடவுச்சொல்லைச் சரிபார்க்காது, தகுதியற்ற கணக்கை தகுதியுடையதாக்காது. அவை தனித்தனி வேலைகள், அவற்றைக் கலப்பதே ஒரு இடம்பெயர்வு அதன் மகிழ்ச்சியான பாதைச் சோதனையில் தேர்ச்சி பெற்று அதன் முதல் உண்மையான சம்பவத்தில் தோல்வியடையும் வழி.

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

கொள்கை, சுயவிவரம், மேப்பிங் ஆகியவற்றை ஒன்றாக மாற்றுங்கள்

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

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

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

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