VPN પ્રમાણીકરણ ક્ષેત્ર: કઈ એકાઉન્ટ નામ જગ્યા જીતે છે?
ક્ષેત્ર લોગિનને એક ઓળખ સિસ્ટમ તરફ મોકલે છે, દેશ તરફ નહીં. નામનું સ્વરૂપ નક્કી કરો, પ્રોક્સી દ્વારા વિનંતી શોધો અને કોણે જવાબ આપ્યો તે નોંધો.
દરેક VPN લોગિન કોઈ એકાઉન્ટ નામ જગ્યામાં પહોંચે છે, અને કઈ તે નક્કી કરનાર પસંદગીકાર ક્ષેત્ર છે. તે દેશ, સર્વરનું સ્થાન કે વિશ્વાસ સ્તર વિશે કંઈ કહેતું નથી. બે સમાન વપરાશકર્તા નામો જુદા જુદા ક્ષેત્રોમાં રહી શકે છે, તેથી સાચો પાસવર્ડ ક્યારેક ખોટું એકાઉન્ટ પ્રમાણિત કરે છે. આ માર્ગદર્શિકા પહેલા ઓળખનું સ્વરૂપ સુધારે છે, પછી વિનંતીને ખરેખર જવાબ આપનાર સિસ્ટમ સુધી શોધે છે.
ક્ષેત્ર શું પસંદ કરે છે
ગેટવે વપરાશકર્તા નામ મેળવે છે અને તેને ક્યાં તપાસવું તે નક્કી કરવું પડે છે. ક્ષેત્ર એ નામનો ભાગ, અથવા તેની બાજુનું લક્ષણ, છે જે ડેટાબેઝ પસંદ કરે છે: ડિરેક્ટરી, RADIUS પૂલ, સ્થાનિક એકાઉન્ટ ફાઇલ. માઇક્રોસોફ્ટનું NPS તેને ક્ષેત્ર નામ કહે છે અને તેની સાથે કનેક્શન વિનંતીઓ મોકલે છે, જ્યારે EAP નેટવર્ક એક્સેસ ઓળખકર્તા RFC 7542 માં @ ચિહ્ન પછી પ્રત્યય તરીકે એ જ વિચાર ધરાવે છે. બંને પસંદગીકાર છે, અને કોઈ પણ નક્કી કરતું નથી કે ઓળખપત્ર સારું છે કે નહીં.
આ વિભાજન બે ખૂબ જુદી નિષ્ફળતાઓ ઉત્પન્ન કરે છે. સાચી રીતે મોકલતું ક્ષેત્ર ખોટા પાસવર્ડ સાથે એક અસ્વીકાર આપે છે, જ્યારે ખોટા ડેટાબેઝ તરફ મોકલતું ક્ષેત્ર સાચો પાસવર્ડ નકારી શકે છે અથવા બીજાનો સ્વીકારી શકે છે. બંને ભૂલો ક્ષેત્રનો ઉલ્લેખ કરતી નથી, તેથી પ્રથમ નિદાન હંમેશા એક જ છે: કઈ સિસ્ટમે જવાબ આપ્યો તે શોધો.
ક્ષેત્રનું વાક્યરચના ડિપ્લોયમેન્ટનું છે. કેટલીક સેવાઓ લક્ષણ સાથે અયોગ્ય નામ માંગે છે, અન્ય user@domain માંગે છે, અને થોડી બેકસ્લેશવાળું સ્વરૂપ અપેક્ષિત કરે છે જે મોટાભાગની માર્ગદર્શિકાઓ કદી ઉલ્લેખ કરતી નથી.
બેકએન્ડ જે સ્વરૂપ અપેક્ષિત કરે તે વાપરો
ટ્યુટોરિયલના પ્રત્યય અજમાવતા પહેલા ઓપરેટરને પૂછો કે કયું સ્વરૂપ લખવું. ડોમેનથી યોગ્ય નામ જ્યારે સાદું નામ અપેક્ષિત કરતા બેકએન્ડ સુધી પહોંચે છે ત્યારે સામાન્ય રીતે પાસવર્ડ તપાસમાં નહીં, શોધમાં નિષ્ફળ જાય છે. બે ડિરેક્ટરીમાં એ જ ટૂંકું નામ એ કેસ છે જ્યાં ગુમ થયેલું ક્ષેત્ર સૌથી વધુ નુકસાન કરે છે.
સંચાલન એકાઉન્ટને પુરાવા તરીકે ન લો. જે વેબ કન્સોલમાંથી સેવા સંભાળો છો તે સ્થાનિક ફાઇલ સામે પ્રમાણિત કરી શકે છે, જ્યારે ટનલ સંપૂર્ણપણે બીજી ડિરેક્ટરી તપાસે છે. વાસ્તવિક વપરાશકર્તા જે ઓળખપત્રો વાપરે તેની સાથે, વાસ્તવિક વપરાશકર્તા જે ઇન્ટરફેસ વાપરે તેમાં પરીક્ષણ કરો. સફળ કન્સોલ લોગિન ગેટવે VPN પ્રમાણીકરણ પર લાગુ કરે તે ક્ષેત્ર વિશે કંઈ કહેતું નથી.
બ્રાઉઝર અને મેઇલ ક્લાયન્ટ ક્યારેક અગાઉની ઓળખ કેશ કરીને ચૂપચાપ ફરી મોકલે છે. જ્યારે નોંધાયેલ વપરાશકર્તા નામ લખેલા નામથી જુદું હોય, ત્યારે તે કેશ પહેલું જોવાનું સ્થળ છે.
પ્રોક્સી દ્વારા વિનંતી શોધો
FreeRADIUS ફ્રન્ટએન્ડ પર, ક્ષેત્રો પ્રોક્સી રૂપરેખાંકનમાં જાહેર થાય છે, અને જાહેર કરેલો પ્રત્યય નક્કી કરે છે કે કયો હોમ સર્વર વિનંતી મેળવે છે. કંઈપણ બદલતા પહેલા તે ફાઇલ વાંચો, કારણ કે કોઈ પણ ક્ષેત્ર સાથે ન મળતી વિનંતી ડિફોલ્ટ રૂપે સ્થાનિક રીતે પ્રક્રિયા થાય છે.
grep -n -A4 '^realm' /etc/freeradius/3.0/proxy.conf
radtest '[email protected]' 'wrong-password' 10.20.30.10 0 testing123
journalctl -u freeradius --since '-10 min' | grep -iE 'realm|stripped'
grep દર્શાવે છે કે કયા પ્રત્યય અસ્તિત્વમાં છે અને દરેક કયા પૂલને લક્ષ્ય બનાવે છે. radtest કૉલ ક્ષેત્ર સાથે નામ અને જાણી જોઈને ખોટો પાસવર્ડ મોકલે છે, તેથી અસ્વીકાર સાબિત કરે છે કે માર્ગ અને ઓળખપત્ર તપાસ બંને ચાલ્યા. તે પ્રયાસ આસપાસની લોગ લાઇનો દર્શાવે છે કે પ્રોક્સી પહેલા નામ કાઢી નાખવામાં આવ્યું હતું કે નહીં અને કયા હોમ સર્વરે તે લીધું. જો લોગ કોઈ ક્ષેત્ર મેળ દર્શાવતું નથી, તો વિનંતી સ્થાનિક સર્વર છોડી જ નહોતી અને સમસ્યા પાસવર્ડ નહીં, પ્રત્યય છે.
એક સમયે એક વસ્તુ બદલો અને પ્રયાસ પુનરાવર્તન કરો, કારણ કે લોગ રૂટિંગને ઓળખપત્ર નિષ્ફળતાથી અલગ કરે છે જ્યારે રન વચ્ચે ઇનપુટ જુદું હોય ત્યારે જ. શેર કરેલ રહસ્ય shell ઇતિહાસની બહાર રાખો જ્યાં સાધન ફાઇલ કે પ્રોમ્પ્ટમાંથી વાંચવાનું સમર્થન કરે છે.
પ્રયાસ લીક કર્યા વિના નોંધો
નિષ્ફળતા એવા સ્વરૂપમાં લખો કે જેના પર સંચાલક કાર્ય કરી શકે: ઇન્ટરફેસ, ઓળખનું સ્વરૂપ, ક્ષેત્ર હાજર હતું કે નહીં, અને ચોક્કસ ગુપ્ત ન હોય તેવી ભૂલ. જીવંત વપરાશકર્તા નામને જાહેર અહેવાલોની બહાર અને ક્ષેત્રને અંદર રાખો. દરેક ઓળખને એ જ પ્લેસહોલ્ડરમાં ઢાંકવાથી તમે જે અસંગતિ શોધી રહ્યા છો તે જ છુપાય છે. સમય ચિહ્ન પણ મહત્વપૂર્ણ છે, કારણ કે ગેટવે, પ્રોક્સી અને ડિરેક્ટરી અલગ લોગ રાખે છે.
પછી વપરાશકર્તાઓ માટે જીતતું સ્વરૂપ દસ્તાવેજ કરો, કારણ કે આગળની વ્યક્તિ જે તેને ખોટું લખશે તે એ જ ટિકિટ ખોલશે. પાસવર્ડ રીસેટ એ વિનંતીને ઠીક કરતું નથી જે ખોટી નામ જગ્યામાં પડવાનું ચાલુ રાખે છે. ક્ષેત્ર એ રૂટિંગ નિર્ણય છે, અને રૂટિંગ નિર્ણયોને સાચું નામ આપીને ઠીક કરવામાં આવે છે.