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

જૂથ બદલતા પહેલાં નિષ્ફળતા વાંચો

«નીતિ મેળ ભૂલ» એ સારાંશ છે, નિદાન નહીં. તેનો અર્થ છે કે પરસ્પર સ્વીકાર્ય પ્રસ્તાવ મળ્યો નથી, અને તે કયો ઘટક નકારાયો તે વિશે કંઈ કહેતું નથી. તેને તપાસની શરૂઆત તરીકે ગણો, કોઈ ચોક્કસ જૂથ વિશેના પુરાવા તરીકે નહીં.

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

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

બંને યાદીઓ લખી લો. ચાર ટ્રાન્સફોર્મ સ્થાન અને એક જૂથ ટૂંકી યાદી છે, અને તેને લીટી દીઠ સરખાવવામાં કોઈપણ પ્રયોગ કરતાં ઓછો સમય લાગે છે. ચાર સ્થાન યાદ રાખવા સહેલા છે. લોગ ફાઇલ નહીં.

દરેક ટ્રાન્સફોર્મની સરખામણી કરો, એક જાણીતા નામની નહીં

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

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

જૂથના નામ અમલીકરણો વચ્ચે અલગ હોય છે, અને તે મૂંઝવણનો અલગ સ્રોત છે. strongSwan modp2048 અને ecp256 લખે છે, જ્યારે Windows Group14 અને ECP256 જેવા ગણતરી નામો વાપરે છે, તેથી સરખામણી પહેલાં ભાષાંતર કરવું પડે. બંને નામ સાથે બે કોલમની નોંધ રાખો. પછી આગળની અસંગતિ સેકન્ડોમાં વર્ગીકૃત થાય છે.

TransformWindows parameterstrongSwan nameFailure it causes
EncryptionCipherTransformConstantsaes, aes256gcm and similarNo common proposal at all
Integrity or PRFAuthenticationTransformConstantssha256, sha512 and similarProposal rejected after encryption matches
Key-exchange groupDHGroupmodp2048, ecp256Exchange fails during key establishment
Child SA protectionPfsGroupesp proposal groupsTunnel negotiates, data association does not

એક સંપૂર્ણ અને મર્યાદિત નીતિ લાગુ કરો

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

Set-VpnConnectionIPsecConfiguration -ConnectionName "Northwind IKEv2" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup ECP256 -PfsGroup ECP256 -WhatIf

-WhatIf સ્વિચ સ્થાનિક ફેરફારનું પૂર્વદર્શન કરે છે અને કંઈ લાગુ કરતું નથી. તે ઉપયોગી છે અને તેમ છતાં સામાન્ય જાળ પણ છે, કારણ કે પૂર્વદર્શન ફક્ત એ સાબિત કરે છે કે પરિમાણો સ્થાનિક cmdlet માટે વાક્યરચનાની દૃષ્ટિએ સ્વીકાર્ય છે. ગેટવે પરિણામી પ્રસ્તાવ સ્વીકારશે કે નહીં તે વિશે તે કંઈ કહેતું નથી.

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

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

એક્સચેન્જ અને કી-રિન્યુઅલ અલગ રીતે ચકાસો

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

ipsec statusall | grep -A6 "Northwind"
Get-VpnConnection -Name "Northwind IKEv2" | Format-List *

પહેલો આદેશ સ્થાપિત એસોસિએશનો પર સર્વરનું દૃશ્ય બતાવે છે, જેમાં ચાઇલ્ડ SA અને તેનું બાકીનું આયુષ્ય સામેલ છે. બીજો આદેશ બતાવે છે કે ક્લાયન્ટ પ્રોફાઇલમાં હવે શું છે, અને તમે સેટ કરેલી નીતિ જ અમલમાં છે તેની પુષ્ટિ કરવાનો આ જ એકમાત્ર રસ્તો છે.

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

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

ચાર પરિમાણ, જૂથ, કનેક્શનનો અવકાશ અને કી-રિન્યુઅલનું પરિણામ નોંધો. આ ટૂંકી નોંધ છે, અને તે જ માર્ગદર્શિકા અને ટનલ ક્યારે ઉપર આવી તેની વાર્તા વચ્ચેનો તફાવત છે.

સંબંધિત લેખો