RouterOS OpenVPN અને NPS: auth નહીં, user-auth-method સેટ કરો

RouterOS માં auth ટનલનું ડાયજેસ્ટ પસંદ કરે છે, જ્યારે user-auth-method નક્કી કરે છે કે RADIUS વિનંતી કેવી રીતે તપાસવી. બીજાને NPS નીતિ સાથે મેળવો.

RouterOS OpenVPN લોગિન સાથે NPS સુધી પહોંચી શકે છે અને તેમ છતાં નકારી શકાય છે, અને સામાન્ય કારણ બે સેટિંગ્સ છે જેમના નામ બંને પ્રમાણીકરણ જેવા સંભળાય છે. એક ટનલ માટે ક્રિપ્ટોગ્રાફિક ડાયજેસ્ટ પસંદ કરે છે; બીજું નક્કી કરે છે કે વપરાશકર્તાની ઓળખપત્રો RADIUS ને કેવી રીતે રજૂ થાય. ડાયજેસ્ટ બદલવાથી PAP વિનંતી ક્યારેય MS-CHAPv2 નહીં બને, સેવા ગમે તેટલી વાર ફરી શરૂ થાય. નીચેની ચેકલિસ્ટ બંનેને અલગ કરે છે અને પછી એક નિષ્ફળ લોગિનને તેનું મૂલ્યાંકન કરનાર NPS નીતિ દ્વારા અનુસરે છે.

પગલું 1: કોઈપણ બદલતા પહેલાં બંને સેટિંગ્સ વાંચો

ટનલ સમાપ્ત કરતા રાઉટર પર અસરકારક OpenVPN સર્વર રૂપરેખાંકન છાપો, બેકઅપ અથવા નકલ કરેલી ફોરમ પોસ્ટમાંથી નહીં. તમને જે બે ફીલ્ડ જોઈએ છે તે સામાન્ય રીતે એક જ મેનુમાં હોય છે અને વિકલ્પો હોય તેમ વાંચાય છે. તેઓ વિકલ્પો નથી: એક ડેટા ચેનલ વિશે છે, બીજું ઓળખપત્રોની આપલે વિશે.

/interface ovpn-server server print
/interface ovpn-server server export

auth ફીલ્ડ sha1 અને sha256 જેવા ડાયજેસ્ટની સૂચિ આપે છે અને ટનલ પેકેટનું પ્રમાણીકરણ કરતા HMAC ને નિયંત્રિત કરે છે. user-auth-method ફીલ્ડ pap અથવા mschap2 પસંદ કરે છે અને રાઉટર વપરાશકર્તાની ઓળખપત્રો RADIUS ને કેવી રીતે રજૂ કરે તે નક્કી કરે છે. ડાયજેસ્ટ ફેરફાર બીજા વર્તનને બદલી શકતું નથી, તેથી પહેલામાંના દરેક ગોઠવણ પછી પણ એ જ અસ્વીકૃતિ ટકી રહે છે.

જો તમારી આવૃત્તિ user-auth-method બિલકુલ આપતી ન હોય તો અહીં થોભો. જૂની RouterOS બિલ્ડ તેને OpenVPN સર્વર પર ઓફર ન કરી શકે, અને સુધારો નવીની બનેલી આદેશમાં નહીં, પરંતુ તમે ટેકો આપી શકો તેવી આવૃત્તિમાં હોવો જોઈએ.

પગલું 2: જે નીતિએ લોગિન ખરેખર નકાર્યું તે શોધો

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

Get-WinEvent -LogName Security -MaxEvents 200 |
  Where-Object { $_.Id -in 6272,6273 } |
  Format-List TimeCreated,Id,Message

ઘટનામાં ત્રણ વસ્તુઓ વાંચો: મેળ ખાતી નીતિનું નામ, પ્રમાણીકરણ પદ્ધતિ અને કારણ કોડ. MS-CHAPv2 જરૂરી હોય તેવી નીતિ પાસવર્ડ સાચો હોય તો પણ PAP વિનંતી નકારે છે, અને ડોમેન ખાતું જરૂરી હોય તેવી નીતિ સ્થાનિક ખાતું નકારે છે. RADIUS ક્લાયંટ એન્ટ્રી પણ રાઉટરના સ્રોત સરનામા સાથે મેળ ખાવી જોઈએ, નહીં તો કોઈપણ નીતિ તપાસ્યા પહેલાં વિનંતી કાઢી નાખવામાં આવે છે. આમાંથી કંઈ પણ OpenVPN લોગમાં દેખાતું નથી.

જો વિનંતી ક્યારેય NPS સુધી પહોંચતી ન હોય તો અહીં થોભો. તે શેર કરેલ ગુપ્ત, ક્લાયંટ સરનામું અથવા UDP 1812 ની સમસ્યા છે, અને પ્રમાણીકરણ પદ્ધતિઓ બદલવાથી તે ઠીક થશે નહીં.

પગલું 3: બંને બાજુએ એક પદ્ધતિ બદલો

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

/interface ovpn-server server set user-auth-method=mschap2
/interface ovpn-server server print
/log print where topics~"radius"

ભૂલ અદૃશ્ય થાય તે માટે NPS પર દરેક નબળી પદ્ધતિ સક્ષમ કરશો નહીં. બેકએન્ડ પાસે એવી સામગ્રી હોવી જોઈએ જે પસંદ કરેલી પદ્ધતિ ચકાસી શકે: MS-CHAPv2 ને પાસવર્ડ અથવા ડોમેનની ઍક્સેસ જોઈએ છે, અને નીતિ તે સામગ્રી શોધી શકતી નથી. નીતિને પહોળી કરવાથી એ પણ પહોળું થાય છે કે હુમલાખોર સમાન ખાતા સામે શું પ્રયાસ કરી શકે. પદ્ધતિ, નીતિનું નામ અને ફેરફાર સંદર્ભ એકસાથે નોંધો, જેથી આગલી વ્યક્તિ અનુમાનને બદલે નિર્ણય વારસામાં મેળવે.

ટનલની પ્રમાણપત્ર માન્યતા બરાબર પહેલા જેવી જ રાખો. ઓળખપત્ર પદ્ધતિ સર્વરની ઓળખનો વિકલ્પ નથી, અને પરીક્ષણ પાસ કરાવવા TLS તપાસ નીચી કરવાથી એક સમસ્યાના બદલે વધુ ખરાબ સમસ્યા આવે છે.

પગલું 4: ત્રણ લોગિન અને એક પરવાનગી ચકાસો

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

/log print where topics~"ovpn"
/radius monitor 0

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

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

સંબંધિત લેખો