PAM નીતિ સાથે OpenVPN લોગિનને એક જૂથ સુધી મર્યાદિત કરો

દરેક ખાતાને સામાન્ય રીતે લોગિન કરવા સક્ષમ રાખો, પરંતુ ફક્ત એક જૂથને VPN વાપરવા દો. PAM બીજા પાસવર્ડ સંગ્રહ વિના તે તફાવત વ્યક્ત કરી શકે છે, અને OpenVPN પ્લગઇનને એવી સેવા તરફ નિર્દેશિત કરી શકાય છે જેમાં ફક્ત તમે ઇચ્છો તે તપાસો હોય. યુક્તિ એ છે કે સિસ્ટમ-વ્યાપી સ્ટેકને આકસ્મિક રીતે વારસામાં ન લેતાં એ સેવા બનાવવી.

અહીંની મુસાફરી પ્લગઇનના સેવા નામથી શરૂ થાય છે, નીતિ બનાવે છે અને પછી ત્રણ મહત્વપૂર્ણ પરિણામો ચકાસે છે: સભ્ય, માન્ય પાસવર્ડ ધરાવતો બહારનો વ્યક્તિ અને ખરાબ ઓળખપત્ર.

અલગ PAM સેવા કેમ

auth-pam પ્લગઇન તેના આર્ગ્યુમેન્ટ તરીકે સેવા નામ લે છે. તે નામ /etc/pam.d હેઠળની ફાઇલ પસંદ કરે છે, અને તે ફાઇલનો સ્ટેક જ VPN લોગિન દરમિયાન ચાલે છે. જો તમે સિસ્ટમ-વ્યાપી લોગિન જે નામ વાપરે છે તે જ નામ આપો, તો તમે તે સ્ટેકના દરેક નિર્ણયને વારસામાં લો છો, જે પછી અસંબંધિત કારણોસર ઉમેરાયા હોય તે પણ.

તેના બદલે સમર્પિત સેવા બનાવો. પહેલેથી જ ઇચ્છિત backend સામે પ્રમાણીકરણ કરતા કાર્યકારી સ્ટેકથી શરૂ કરો, જેમ કે સ્થાનિક પાસવર્ડ ફાઇલ, SSSD અથવા ડિરેક્ટરી સેવા, પછી પાત્રતાનો નિયમ ઉમેરો. ખાલી ફાઇલમાં બે લીટીઓ કોપી કરવી સામાન્ય ભૂલ છે: પાસવર્ડની સમાપ્તિ, ખાતાનું લોક અને અન્ય તપાસો તમે કોપી ન કરેલા સ્ટેકમાં હોઈ શકે છે.

સેવાને અલગ કરવાથી નુકસાનની પહોંચ પણ મર્યાદિત થાય છે. વિભાજિત સ્ટેકમાં ફક્ત-VPN નિયમ બધા માટે SSH અથવા કન્સોલ પ્રવેશ નકારી શકે છે, જે પ્રવેશ ફેરફારને વિક્ષેપમાં ફેરવે છે.

જૂથનો નિયમ લખવો

પાત્રતાની તપાસ ખાતાના તબક્કામાં આવે છે, ઓળખપત્ર ચકાસાયા પછી. account required pam_succeed_if.so user ingroup vpnusers જેવો નિયમ પ્રક્રિયાને ત્યારે જ આગળ વધવા દે છે જ્યારે પ્રમાણીત વપરાશકર્તા તે જૂથનો સભ્ય હોય.

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

ટેવને કારણે use_uid ઉમેરશો નહીં. તેના વિના મોડ્યુલ પ્રમાણીત થતા વપરાશકર્તાનું મૂલ્યાંકન કરે છે; તેની સાથે મોડ્યુલ તે ખાતાનું મૂલ્યાંકન કરે છે જે હેઠળ OpenVPN પ્રક્રિયા ચાલે છે, જે સામાન્ય રીતે root અથવા સેવા ખાતું હોય છે અને તેથી લોગિન કરતી વ્યક્તિ નથી.

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

ક્રમ અને ઓળખની જાળ

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

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

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

સભ્યો, બહારના લોકો અને ખોટા પાસવર્ડ ચકાસવા

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

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

PAM સંપાદિત કરતી વખતે બીજું સત્ર ખુલ્લું રાખો, અને ફેરફાર પછી સામાન્ય SSH લોગિન પણ ચકાસો. સમર્પિત સેવાનો હેતુ એ છે કે સિસ્ટમ લોગિન અસ્પૃષ્ટ રહેવું જોઈએ, અને તે જાણવાનો એકમાત્ર રસ્તો તેને ચકાસવો છે.

કંઈક તૂટે તો કોપીમાંથી અગાઉની સેવા ફાઇલ પુનઃસ્થાપિત કરો. તમે ઇચ્છો તે નિયમ કહેવો સરળ છે: સભ્યપદ ખાતાને VPN પ્રવેશ માટે પાત્ર બનાવે છે, અને અન્ય દરેક જરૂરી તપાસ હજી પણ લાગુ પડે છે.