શા માટે નેટિવ Windows IKEv2 માં PSK ફીલ્ડ જ નથી

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

પ્રોટોકોલ ક્ષમતા એ ક્લાયન્ટ સમર્થન નથી

IKEv2 સ્પેસિફિકેશનમાં શેર કરેલી કી સાથેની પ્રમાણીકરણ શામેલ છે, તેથી ગેટવેને તે માટે કાયદેસર રીતે ગોઠવી શકાય. નેટિવ Windows રિમોટ-એક્સેસ પ્રોફાઇલ તેના બદલે પ્રમાણપત્ર અને EAP ગોઠવણોનું દસ્તાવેજીકરણ કરે છે, અને પ્રોટોકોલ ક્ષમતા એવું ફીલ્ડ, પરિમાણ કે રજિસ્ટ્રી મૂલ્ય બનાવતી નથી જે ક્લાયન્ટ પાસે ક્યારેય ન હતું.

લોકો સામાન્ય રીતે VPN જોડાણ ઉમેરવા માટે PowerShell સંદર્ભ પર પહોંચે છે, અને ત્યાં L2TP ગોઠવણ માટે L2tpPsk દર્શાવેલ છે. એ પરિમાણ L2TP નું છે અને સામાન્ય IKEv2 રહસ્ય નથી. અલ્ગોરિધમ-પસંદગીની સેટિંગ્સ રક્ષણ પરિમાણો પસંદ કરે છે, જે ત્રીજી, અસંબંધિત વસ્તુ છે. Windows Server ની રાઉટિંગ ભૂમિકા પણ એ જ ઑબ્જેક્ટ નથી. સર્વર ઇન્ટરફેસમાં એવા કન્ફિગરેશન નિયંત્રણો હોઈ શકે જે ડેસ્કટોપ ક્લાયન્ટ પ્રોફાઇલમાં નથી, અને સર્વર સેટિંગને વર્કસ્ટેશન પ્રોફાઇલમાં કૉપિ કરવાથી એ ક્ષમતા પુનઃઉત્પન્ન થતી નથી.

પ્રમાણપત્ર, EAP કે L2TP પૈકી પસંદ કરો

જો ગેટવે ઓપરેટર પ્રમાણપત્ર પ્રમાણીકરણ સ્વીકારે, તો તે સામાન્ય રીતે સૌથી સ્વચ્છ લક્ષ્ય છે: ક્લાયન્ટ પ્રમાણપત્ર રજૂ કરે છે, ગેટવે વિશ્વસનીય ઇશ્યુઅર સામે તેની ચકાસણી કરે છે, અને પ્રોફાઇલમાં કોઈ શેર કરેલું રહસ્ય રહેતું નથી જે કોઈ કૉપિ કરે. તેને નોંધણી, વિશ્વસનીય શૃંખલા અને પ્રમાણપત્રને અધિકૃતતા નિર્ણય સાથે જોડતી ગેટવે ગોઠવણ જોઈએ.

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

ગેટવે શું સ્વીકારશે તે તપાસો

ઓપરેટરને પૂછો કે રિમોટ-એક્સેસ સેવા આજે કઈ પ્રમાણીકરણ પદ્ધતિઓ આપે છે, એ નહીં કે ઉત્પાદન સામાન્ય રીતે કઈને સમર્થન આપે છે. ફક્ત PSK માટે ગોઠવેલી IKEv2 સેવા ક્લાયન્ટ પસંદ કરે તેથી પ્રમાણપત્ર સ્વીકારશે નહીં.

Get-VpnConnection -Name "Corp IKEv2" | Format-List AuthenticationMethod, TunnelType, EncryptionLevel, ServerValidation
Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, NotAfter

પ્રોફાઇલની પ્રમાણીકરણ પદ્ધતિ અને પ્રમાણપત્ર સંગ્રહ સાથે વાંચો. પાછળ વાપરી શકાય એવું પ્રમાણપત્ર ન હોય તેવી EAP પર ગોઠવેલી પ્રોફાઇલ એવી રીતે નિષ્ફળ જાય છે જે સર્વર સમસ્યા જેવી લાગે.

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

નિર્ણય અને રહસ્યો નોંધો

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

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