શા માટે .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 ટેકાની વ્યાખ્યા નથી.

કેટલાક ડિપ્લોયમેન્ટ પ્રારંભિક ચકાસણી પછી પ્રમાણીકરણ ટોકન આપે છે જેથી ફરી કનેક્શન ફરી ન પૂછે. તે પોતાની માન્યતા વિન્ડો અને રદ કરવાની વાર્તા ધરાવતો રચના નિર્ણય છે, તમે વારસામાં મળતું ડિફોલ્ટ નહીં.

પછી પ્રવેશ નીતિને લોકો ખરેખર વાપરતા ક્લાયન્ટ સાથે ચકાસો. સાચા પાસવર્ડ, પ્રમાણપત્ર અને વર્તમાન કોડ સાથેના નોંધાયેલા વપરાશકર્તાને કનેક્ટ થવું જોઈએ. ખોટો કોડ, નોંધણી વગરનો વપરાશકર્તા અને પ્રતિબંધિત ખાતું — દરેકે નિષ્ફળ થવું જોઈએ, અને કારણ સર્વર લોગમાં દેખાવું જોઈએ. જ્યાં સુધી તમે એ નકાર જોયા નથી, ત્યાં સુધી તમારી પાસે વિનંતી છે, નીતિ નહીં.