IKEv1, XAuth અને OTP સાથે: દરેક પ્રોમ્પ્ટ શું માગે છે

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

બીજો ક્લાયન્ટ ઇન્સ્ટોલ કરતાં કે ક્રેડેન્શિયલ રીસેટ કરતાં પહેલાં દરેક પ્રોમ્પ્ટને જે સ્તર તેને માગે છે તેની સાથે મેળવો.

ત્રણ રહસ્યો, ત્રણ માલિકો

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

ત્રણ કોલમ લખો: માલિક, આયુષ્ય અને દરેક જે ભૂલ સંદેશ આપે છે. એ જ કોષ્ટક નિદાન સાધન છે, ક્લાયન્ટના ક્ષેત્રના નામ નહીં.

PSK: સહભાગી, વ્યક્તિ નહીં

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

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

XAuth: જૂનો વપરાશકર્તા વિનિમય

XAuth IKEv1 ના સહભાગી પ્રમાણીકરણ ઉપર વપરાશકર્તા પ્રમાણીકરણ વિનિમય ઉમેરે છે, અને કયો બેકએન્ડ તેને ચકાસશે તે ગેટવે નક્કી કરે છે. તે બેકએન્ડના આધારે વિનિમય ડિરેક્ટરી પાસવર્ડ, RADIUS ક્રેડેન્શિયલ કે ટોકન જવાબ સ્વીકારી શકે છે. XAuth શબ્દ ક્રેડેન્શિયલનો પ્રકાર નહીં, વિનિમયનું વહન નામ આપે છે.

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

OTP: બેકએન્ડ જે માગે

કેટલીક તૈનાતીઓ પાસવર્ડ પછી અલગ એક-વખતનો કોડ માગે છે, અને બીજી દસ્તાવેજીકૃત વિભાજક સાથે સંયુક્ત ઇનપુટ ફોર્મેટ વ્યાખ્યાયિત કરે છે. બંને અસ્તિત્વમાં છે, અને તમારી સામેની પ્રોફાઇલ નક્કી કરે છે કે કયું. બીજી જગ્યાએ કામ કર્યું તેથી જોડાણ શોધી કાઢવું નોંધણી ટોકન બાળવાનો સૌથી સામાન્ય રસ્તો છે. ગેટવેનું પોતાનું દસ્તાવેજીકરણ જ એકમાત્ર સ્રોત છે જે આ નક્કી કરે છે.

દસ્તાવેજીકૃત ફોર્મેટનો ઉપયોગ એવા ક્લાયન્ટ સાથે કરો જે ગેટવે આપે છે તે વિનિમય પૂર્ણ કરી શકે.

ક્લાયન્ટની સીમા ક્યાં ડંખે છે

Fortinet દસ્તાવેજ કરે છે કે FortiClient 7.4.4 અને પછીના સંસ્કરણો IPsec VPN માટે IKEv1 ને હવે સમર્થન આપતા નથી, જે સાર્વત્રિક દૂરીકરણ નહીં પણ ઉત્પાદન અને સંસ્કરણની સીમા છે, જેમ FortiClient સુસંગતતા નોંધ નોંધે છે. અન્ય ક્લાયન્ટ પણ અદલાબદલી યોગ્ય નથી: OpenConnect અને openfortivpn ચોક્કસ ગેટવે પ્રોટોકોલ બોલે છે, મનસ્વી IKEv1 પ્રોફાઇલ નહીં. ઇન્સ્ટોલ કરેલા ક્લાયન્ટનું IKE સંસ્કરણ, PSK મોડ, XAuth સમર્થન અને ક્રિયાપ્રતિક્રિયા મોડ અલગ અલગ તપાસો. જુદી રીતે જોડાતો ક્લાયન્ટ મૂળ જરૂરિયાત સાબિત કરતો નથી.

IKEv1 અપ્રચલિત છે, તેથી અસમર્થિત જૂના ક્લાયન્ટ પર નવી તૈનાતી ટૂંકા ગાળાનો ઉકેલ છે. ગેટવે માલિક પાસે સમર્થિત સ્થળાંતર માર્ગ માગો, જેમાં બીજું પરિબળ ત્યાં કેવી રીતે સંભાળાશે તેનો સમાવેશ થાય.

પરિબળ બંધ કર્યા વિના નિદાન

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

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