Windows માં IKEv2 કસ્ટમ નીતિ: તેને અલગ પગલા તરીકે લાગુ કરો

પ્રોવિઝનિંગ પેકેજ IKEv2 કનેક્શન બનાવે છે, અને તેમાંથી બનતી પ્રોફાઇલ તમે ધારેલા સ્યુટ સિવાયના કંઈક પર વાટાઘાટ કરે છે. પેકેજે પોતાનું કામ કર્યું; તેમાં તમે ધારેલા કામ માટે ક્યારેય કોઈ ફીલ્ડ જ નહોતું. ક્રિપ્ટો સ્યુટને અલગ અને ચકાસી શકાય તેવા પ્રોવિઝનિંગ પગલા તરીકે ગણો.

નીચેની પાંચ બાબતો ક્રમમાં કરો અને સ્વીકૃતિના પરિણામો અલગ રાખો.

સમાન નામો પાછળ બે પ્રકારની નીતિ

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

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

સંપૂર્ણ નીતિ બનાવો, બે અલ્ગોરિધમ નામો નહીં

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

$policy = @{
    ConnectionName = 'Corp IKEv2'
    AllUserConnection = $true
    EncryptionMethod = 'AES256'
    IntegrityCheckMethod = 'SHA384'
    CipherTransformConstants = 'AES256'
    AuthenticationTransformConstants = 'SHA384128'
    DHGroup = 'Group19'
    PfsGroup = 'PFS2048'
    Force = $true
}
Set-VpnConnectionIPsecConfiguration @policy

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

પહેલા બનાવો, પછી લાગુ કરો — એક જ વ્યાપમાં

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

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

દસ્તાવેજીકૃત Configuration Designer ફીલ્ડ એક VPN સેટિંગનું વર્ણન કરે છે અને દરેક મૂળ IPsec નિયંત્રણને જાહેર કરતાં નથી. જો જરૂરિયાત સંચાલિત ડિલિવરી હોય, તો VPNv2 ગોઠવણી સેવા પ્રદાતા પાસે આ જ હેતુ માટે ક્રિપ્ટોગ્રાફી સ્યુટ વિભાગ છે.

નીતિ માટે એક જ માલિક નિયુક્ત કરો

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

બે માલિકો અસહમત હોય ત્યારે તે માલિક વગરના સમાન છે. પ્રોફાઇલના ફેરફાર રેકોર્ડમાં માલિકનું નામ લખો. આગળનું અપડેટ તે રેકોર્ડ શું કહે છે તે અનુસરશે.

પેકેજ નહીં, વાટાઘાટ કરેલું પરિણામ ચકાસો

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

Get-VpnConnection -Name 'Corp IKEv2' -AllUserConnection | Format-List
Get-ChildItem 'C:\ProgramData\Microsoft\Network\Connections\Pbk' | Select-Object Name, LastWriteTime

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