Windows અને FortiGate પર IKEv2: લોકો જે ત્રણ સેટિંગ્સ ભેગા કરે છે
IKE કી એક્સચેન્જ, CHILD SA સંરક્ષણ અને પીઅર પ્રમાણીકરણ ત્રણ અલગ પંક્તિઓ છે. બે સંવાદોમાં ગ્રુપ નંબર મળી જવાથી તે ભેગા થતા નથી.
Windows ક્લાયન્ટ અને FortiGate ગેટવે વચ્ચેનો IKEv2 કરાર સતત નિષ્ફળ જાય છે, અને ન મળતા નંબરની શોધ વધુ લાંબી નંબરની યાદી બનાવે છે. યાદી ત્યારે જ સંભાળી શકાય તેવી બને છે જ્યારે તેને ત્રણ એવી પંક્તિઓમાં વિભાજિત કરવામાં આવે જે સ્વતંત્ર રીતે નિષ્ફળ જાય: IKE ને સુરક્ષિત કરતું કી એક્સચેન્જ, CHILD SA પર લાગુ થતું સંરક્ષણ, અને જે પ્રમાણીકરણ સાબિત કરે છે કે દરેક પક્ષ કોણ છે. ગ્રુપ નંબર તે પંક્તિઓમાંથી બેમાં દેખાય છે અને અલગ અર્થ ધરાવે છે.
સ્વતંત્ર રીતે નિષ્ફળ જતી ત્રણ પંક્તિઓ
પ્રથમ પંક્તિ IKE ની અંદરનું કી એક્સચેન્જ છે, જે વાટાઘાટને સુરક્ષિત કરતી કી બનાવે છે. બીજી CHILD SA માટેની દરખાસ્ત છે, જે ટનલ વહન કરતા ટ્રાફિકને સુરક્ષિત કરે છે. ત્રીજી પ્રમાણીકરણ છે, જે નક્કી કરે છે કે દરેક પક્ષ શું રજૂ કરે છે અને બીજો પક્ષ તેને કેવી રીતે માન્ય કરે છે.
નિષ્ફળતાઓ અલગ અલગ જગ્યાએ પડે છે. એક્સચેન્જની નિષ્ફળતા કોઈ ટનલ અસ્તિત્વમાં આવે તે પહેલાં જ વાટાઘાટો રોકે છે. CHILD SA ની નિષ્ફળતા પ્રમાણીકરણ સફળ થયા પછી થાય છે, ક્યારેક ફક્ત કી રિન્યુઅલ વખતે. પ્રમાણીકરણની નિષ્ફળતા લોગમાં એક્સચેન્જની નિષ્ફળતા જેવી લાગી શકે છે, જો તમે ફક્ત પ્રથમ ભૂલ વાંચો.
પંક્તિઓને અલગ કરવું એ હિસાબકિતાબ નથી. તે બદલે છે કે કઈ સેટિંગ બદલવા યોગ્ય છે, અને તે આ આખા ક્ષેત્રનું સૌથી ખર્ચાળ પગલું અટકાવે છે, એટલે કે દરખાસ્તની અસંગતિ સુધારવા માટે કામ કરતા પ્રમાણપત્રો ફરી બનાવવા. એક પંક્તિ બદલાવાથી બીજી બેને તેની સાથે બદલવાની ફરજ પડવી જોઈએ નહીં. એ સ્વતંત્રતા જ તેમને અલગ લખવાનો આખો હેતુ છે.
Windows ના બે ફીલ્ડ શું નિયંત્રિત કરે છે
Windows બે ફીલ્ડ અલગ રાખે છે: DHGroup પોતે IKE એક્સચેન્જ ગોઠવે છે, જ્યારે PfsGroup ટનલની અંદરના ટ્રાફિકને સુરક્ષિત કરતી IPsec નીતિ ગોઠવે છે. તે અલગ તબક્કાઓના છે. Windows ના IKE ફીલ્ડની FortiGate ના તબક્કા 2 ના મૂલ્ય સાથે સરખામણી ખોટી જોડી ચકાસે છે, અને નંબર મળી શકે છે જ્યારે અંતર્ગત એક્સચેન્જ હજી નિષ્ફળ જાય છે.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAબીજો અને ત્રીજો આદેશ ખરેખર અસ્તિત્વમાં હોય તેવા સિક્યોરિટી એસોસિએશન જણાવે છે, અને તે ક્લાયન્ટ તમને આપી શકે તેવા જવાબની સૌથી નજીકની વસ્તુ છે. મુખ્ય મોડ એસોસિએશન હોય પણ ઝડપી મોડ એસોસિએશન ન હોય તે CHILD SA ની સમસ્યા છે, અને તે પ્રમાણપત્રની સમસ્યા નહીં, પરંતુ તબક્કા 2 ની અસંગતિની નિશાની છે.
એક પ્રયાસમાં શું સૂચવાયું અને શું પસંદ થયું તે નોંધો. જે દરખાસ્તની યાદીમાં સ્વીકાર્ય દરખાસ્ત હોય પણ પસંદ કરેલી દરખાસ્ત ગેટવેની નીતિ સાથે ન મળે, તે ગોઠવણીનો મતભેદ છે, ઇન્ટરઓપરેબિલિટીનો રહસ્ય નહીં.
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
અંડાકાર વક્રનું ગ્રુપ તમારી સહીની કી પસંદ કરતું નથી
આ ક્ષેત્રનું સૌથી ચીલાચાલુ ખોટું અનુમાન એ છે કે અંડાકાર વક્રનું DH ગ્રુપ પસંદ કરવા માટે અંડાકાર વક્રનું પ્રમાણપત્ર જરૂરી છે. DH ગ્રુપ કી એક્સચેન્જની સામગ્રી પૂરી પાડે છે; સહીનો અલ્ગોરિધમ પ્રમાણીકરણ ઢાંચો વાટાઘાટ કરે છે, અને IKEv2 માં આ બે અલગ નિર્ણયો છે.
RFC 7427 ફક્ત એટલા માટે અસ્તિત્વમાં છે કે તે નિર્ણયો પહેલાં એકબીજામાં ગૂંથાયેલા હતા, અને તે નક્કી કરે છે કે કી એક્સચેન્જથી સ્વતંત્ર રીતે સહીના અલ્ગોરિધમ કેવી રીતે જાહેર થાય અને પસંદ થાય. ગેટવે એક જ સમયે વક્ર ગ્રુપ અને સહી યોજનાઓની પસંદગી બંનેને ટેકો આપી શકે છે.
તેથી જ્યારે ગ્રુપ બદલ્યા પછી વાટાઘાટ નિષ્ફળ જાય, ત્યારે પ્રમાણપત્રની કીનો પ્રકાર જોતા પહેલાં પ્રમાણીકરણની પદ્ધતિ જુઓ. પ્રમાણપત્ર બદલવું એ ધીમી અને જોખમી ક્રિયા છે જે ભાગ્યે જ જવાબ હોય છે, અને તેને પહેલા કરવાથી કયા ફેરફારે ખરેખર મદદ કરી તે જાણવાની તમારી ક્ષમતા નષ્ટ થાય છે. પ્રમાણપત્ર સ્ટોરને સ્પર્શતા પહેલાં પ્રમાણીકરણની પંક્તિ વાંચો.
બંનેને કરારપત્રની અલગ પંક્તિઓમાં રાખો અને ભૂલ પ્રલોભક રહેવાનું બંધ કરશે. એક પંક્તિ ગ્રુપની યાદી આપે છે, બીજી સહી યોજનાઓ અને ઓળખની, અને બંમાંથી કોઈ એક બીજા વિશે પુરાવો નથી.
દરેક ખાનગી કીને તેના ખરા માલિક પાસે રાખો
પોતાનું પ્રમાણપત્ર રજૂ કરતા ગેટવેને તેની સાથે મળતી ખાનગી કીની જરૂર હોય છે. શૃંખલા માન્ય કરતા પીઅરને CA પ્રમાણપત્રની જરૂર હોય છે, અને ખાસ કરીને CA ની સહીની કીની જરૂર હોતી નથી. આ ત્રણ ઘટકોને ભેગા ભેગા કરવાના કારણે જ લોકો પ્રમાણપત્રને બીજી શ્રેણીમાં દેખાડવા માટે VPN ઉપકરણમાં CA ની ખાનગી કી આયાત કરે છે.
FortiOS માં ભૂમિકાઓ અલગ છે: તેની કી સાથેનું સ્થાનિક પ્રમાણપત્ર, પીઅરને ઓળખવા માટે વપરાતું દૂરસ્થ પ્રમાણપત્ર, અને દૂરસ્થ CA એન્ટ્રી જે તે CA દ્વારા સહી કરાયેલા પ્રમાણપત્રોમાં વિશ્વાસ સ્થાપે છે. ખાનગી કી વિનાની દૂરસ્થ CA એન્ટ્રી અધૂરી નથી; તે તેના હેતુ માટે યોગ્ય છે.
આયાત કરેલી CA સહીની કી તે ઉપકરણ વાંચી શકે તેવા દરેકના અધિકારને વિસ્તારે છે. તે સામાન્ય પીઅર માન્યતાને પણ ઉકેલતી નથી, કારણ કે માન્યતાને જાહેર પ્રમાણપત્ર અને વિશ્વાસનો નિર્ણય જોઈએ, નવા પ્રમાણપત્રો બનાવવાની ક્ષમતા નહીં.
CA ની સહીની કીને ઇશ્યુ કરનારની પોતાની પ્રક્રિયા પાસે રાખો, અને નોંધો કે કયું ઉપકરણ કઈ કી રાખે છે. જ્યારે ઓડિટ પૂછે કે કોણ કોનું નકલી સ્વરૂપ ધારણ કરી શકે, ત્યારે માલિકોનું ટૂંકું કોષ્ટક અલ્ગોરિધમના લાંબા કોષ્ટક કરતાં વધુ કિંમતી છે. કોઈ એવી કી આયાત કરતું નથી જે તે જાણે છે કે ફક્ત ઇન્વેન્ટરી માટે છે. ઘટનાના પહેલાં ઇન્વેન્ટરી લખો, પછી નહીં.