.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 మద్దతు యొక్క నిర్వచనం కాదు.

కొన్ని అమలులు ప్రారంభ తనిఖీ తర్వాత ప్రామాణీకరణ టోకెన్‌లను జారీ చేస్తాయి, తద్వారా పునఃకనెక్షన్‌లు మళ్లీ అడగవు. అది దాని స్వంత చెల్లుబాటు విండో మరియు రద్దు కథతో కూడిన డిజైన్ నిర్ణయం, మీరు వారసత్వంగా పొందే డిఫాల్ట్ కాదు.

తర్వాత ప్రవేశ విధానాన్ని ప్రజలు నిజంగా ఉపయోగించే క్లయింట్‌తో పరీక్షించండి. సరైన పాస్‌వర్డ్, సర్టిఫికెట్ మరియు ప్రస్తుత కోడ్ ఉన్న నమోదైన వినియోగదారు కనెక్ట్ కావాలి. తప్పు కోడ్, నమోదు లేని వినియోగదారు మరియు నిషేధించబడిన ఖాతా ప్రతి ఒక్కటి విఫలం కావాలి, మరియు కారణం సర్వర్ లాగ్‌లో కనిపించాలి. ఆ తిరస్కరణలను చూసే వరకు, మీ వద్ద అభ్యర్థన ఉంది, విధానం కాదు.