.ovpn கோப்பைத் திருத்துவது சேவையகத்தில் MFA-ஐ ஏன் இயக்க முடியாது

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

கோரிக்கை வாடிக்கையாளர் கேட்டார் என்பதை மட்டுமே நிரூபிக்கிறது, அதற்கு மேல் இல்லை

.ovpn கோப்பு வாடிக்கையாளர் பக்க ஆவணம். அது வாடிக்கையாளரைச் சான்றுகளைக் கோரவோ, அவற்றைத் தற்காலிகச் சேமிப்பில் வைக்கவோ அல்லது அதை நிறுத்தவோ சொல்லலாம். ஆனால் அது பயனரைப் பதிவு செய்யவோ, PAM தொகுதியை நிறுவவோ, அல்லது சேவையகம் இப்போது சரிபார்க்காத இரண்டாவது காரணியைக் கோரச் செய்யவோ முடியாது.

தொலைபேசியில் அங்கீகாரச் செயலியை நிறுவுவதும் அந்த உறவை உருவாக்காது. Google Authenticator PAM திட்டம் OTP சரிபார்ப்பின் ஒரு பகுதியாகும், அது OpenVPN இன் பின்னால் இருக்க முடியும்; இறக்குமதி செய்யப்பட்ட சுயவிவரத்தில் Google கணக்கு உள்நுழைவை ஒட்டுவதற்கான வழி அது அல்ல.

பதிவு என்பது சுயவிவரம் செய்ய முடியாத பகுதி

TOTP-க்கு அங்கீகாரச் செயலிக்கும் அதன் சரிபார்ப்பாளருக்கும் இடையே பகிரப்படும் பதிவுப் பொருள் தேவை. தொலைபேசியில் உள்ள ஆறு இலக்கங்கள் வெளியீடு; அவற்றின் பின்னால் உள்ள விதை ரகசியம், அது ஒரு அடையாளத்திற்கு மட்டுமே சொந்தம்.

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

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

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

PAM அடுக்கைப் படித்து உண்மையில் என்ன தேவை என்பதைப் பாருங்கள்

account required pam_permit.so போன்ற ஒரு வரி கணக்குத் தகுதியைச் செயல்படுத்தாது, காரணியையும் சேர்க்காது. அது அந்த PAM கணக்கு நிர்வாக நிலையை அனுமதிக்கிறது, அது நிலையைப் பற்றிய கூற்று, உங்கள் பயனர்களைப் பற்றியது அல்ல.

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

வாடிக்கையாளரின் ஊடாட்டத்தை சேவையகத்தின் வடிவமைப்புடன் பொருத்துங்கள்

auth-user-pass

அந்த உத்தரவு பயனர்பெயர் மற்றும் கடவுச்சொல் உள்ளீட்டைக் கோருகிறது. அது PAM-ஐ அமைக்கவில்லை, பதிவுப் பதிவை உருவாக்கவில்லை, கடவுச்சொல் புலத்தில் TOTP மதிப்பு உள்ளது என்று சேவையகத்திற்குச் சொல்லவில்லை. சேவையக ஒருங்கிணைப்பும் வாடிக்கையாளரும் பயன்படுத்தல் உண்மையில் ஆதரிக்கும் ஊடாட்டத்தில் உடன்பட வேண்டும்: ஒரு சவால், ஆவணப்படுத்தப்பட்ட ஒருங்கிணைந்த சான்று வடிவம், அல்லது தயாரிப்பு-குறிப்பிட்ட ஓட்டம்.

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

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

மீள்இணைப்பு, டோக்கன்கள் மற்றும் விவகாரத்தைத் தீர்க்கும் சோதனை

முதல் வெற்றிகரமான உள்நுழைவுக்குப் பிறகு என்ன நடக்கும் என்பதைத் திட்டமிடுங்கள். முன்பு ஏற்கப்பட்ட குறியீடு அடுத்த அங்கீகாரத்தில் காலாவதியாகியிருக்கலாம் அல்லது மீள்செலுத்தலாக நிராகரிக்கப்படலாம். auth-nocache சான்றுகளைத் தக்கவைப்பதைக் கட்டுப்படுத்துகிறது, MFA-ஐ நிறுவுவதில்லை, reneg-sec 0 மன்ற இழைகளில் எத்தனை முறை தோன்றினாலும் TOTP ஆதரவின் வரையறை அல்ல.

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

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