FortiGate Azure રીકી: peer SA પ્રસ્તાવ સ્થાનિક નીતિ સાથે મેળ ખાતો નથી

ટનલ ઉપર આવી, ટ્રાફિક વહ્યો, અને પછી લોગ કહે છે peer SA proposal not match local policy. મોટાભાગના લોકો તે લીટીને બે રૂપરેખાંકનો કદી મેળ ખાધા નહોતા તેના પુરાવા તરીકે વાંચે છે. સામાન્ય રીતે તેનો અર્થ વધુ સાંકડો હોય છે: તેઓ પ્રથમ CHILD SA માટે મેળ ખાધા અને પ્રથમ નવીકરણ વખતે મેળ ખાવાનું બંધ કર્યું, કારણ કે પ્રથમ સંગઠનને કદી એ વિનિમયની જરૂર પડી નહોતી જે પછીના કરે છે. તે ભેદ જ નક્કી કરે છે કે તમે ક્યાં જુઓ.

પ્રથમ CHILD SA વારસો મેળવે છે, પછીના વાટાઘાટ કરે છે

IKEv2 માં પ્રારંભિક CHILD SA IKE_AUTH દરમિયાન બને છે, અને તેની કી IKE SA ના કી સામગ્રીમાંથી લેવાય છે. તે ક્ષણે અલગ Diffie-Hellman વિનિમય હોતો નથી, તેથી એક peer સ્વીકારી ન શકે તેવો PFS જૂથ હજુ પરીક્ષણમાં આવતો નથી. ટનલ સ્વસ્થ દેખાય છે કારણ કે જે આવશ્યકતામાં તમે પછી નિષ્ફળ જશો તેનું કદી પરીક્ષણ થયું નથી.

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

તેથી “ગઈકાલે તે કામ કરતું હતું” તમને પ્રસ્તાવ વિશે કંઈ કહેતું નથી. તે કહે છે કે પ્રારંભિક વિનિમય સફળ થયો, જે તમે પહેલેથી જાણતા હતા.

નિષ્ફળ વિનિમય વાંચો, પ્રથમ ping નહીં

કંઈપણ બદલતા પહેલાં બંને છેડેથી સફળ IKE પ્રમાણીકરણ, પ્રારંભિક CHILD SA અને નિષ્ફળ બદલી એકત્ર કરો. પછી ક્રિયાને ચોક્કસ નામ આપો: IKE SA રીકી, IKE પુનઃપ્રમાણીકરણ અને CHILD SA રીકી ત્રણ અલગ ઘટનાઓ છે, અને “તબક્કો 2” સામાન્ય વાતચીતમાં તેમને બધાને આવરી લે છે.

નીચેના ક્ષેત્રોની સરખામણી નિષ્ફળ ગયેલા જોડાણ માટે કરો, સામાન્ય રીતે ટનલ માટે નહીં.

FortiGate પર, તે ટનલ માટે તબક્કા-2 પ્રસ્તાવ, PFS સેટિંગ અને સ્વીકૃત DH જૂથો ખોલો. પહેલાં સ્થપાયેલા જોડાણમાંથી અનુમાન કરવાને બદલે લોડ થયેલા મૂલ્યો વાંચો. GUI પૃષ્ઠનો સ્ક્રીનશોટ ચાલુ રૂપરેખાંકન કરતાં નબળો પુરાવો છે, કારણ કે અપગ્રેડ પછી બંને અલગ પડી શકે છે. તમે બદલેલો વિભાગ નિકાસ કરો અને તેને ટિકિટ સાથે રાખો.

Azure ની ડિફોલ્ટ નીતિ હજુ પણ નીતિ છે

જોડાણ સાથે કોઈ કસ્ટમ નીતિ જોડાયેલી ન હોવાનો અર્થ એ નથી કે Azure કોઈ પણ લાગુ કરતું નથી. જોડાણ ગેટવેના ડિફોલ્ટ પ્રસ્તાવ-સમૂહ પર પાછું જાય છે, જે તમારું FortiGate ઓફર કરે તેના કરતાં વિશાળ કે સાંકડું હોઈ શકે. જો બંને સમૂહો IKE માટે ઓવરલેપ થાય પણ PFS સાથે ESP માટે નહીં, તો તમને બરાબર આ જ નિષ્ફળતાનો નમૂનો મળે છે.

આ ફક્ત-વાંચન દૃશ્ય ખરેખર જોડાયેલી નીતિ દર્શાવે છે, રહસ્યો ખુલ્લાં કર્યા વિના:

Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPolicies

તમારા વાસ્તવિક સંસાધન નામો વાપરો. જ્યારે સ્પષ્ટ નીતિની જરૂર હોય, ત્યારે તેને જોડાણ સંસાધન પર સેટ કરો. તે સમગ્ર ગેટવેનું સ્વિચ નથી, અને તે જ ગેટવે પરની અન્ય ટનલોને ચૂપચાપ લાગુ પડતું નથી.

પોર્ટલમાં, તે જોડાણનું Configuration પૃષ્ઠ એ છે જ્યાં કસ્ટમ IPsec/IKE નીતિ જાય છે. Microsoft ની કસ્ટમ-નીતિ માર્ગદર્શિકા સમર્થિત પરિમાણો અને SKU આવશ્યકતાઓની યાદી આપે છે. Azure દરેક જોડાણ માટે એક સંપૂર્ણ સંયોજન લે છે, તેથી તમે IKE ક્ષેત્રો અને IPsec ક્ષેત્રો સાથે મળીને નિર્દિષ્ટ કરો છો, એક વખતે એક નહીં.

PFS એ આવશ્યકતા છે, ફેરવવાનું સ્વિચ નહીં

જો તમારી સુરક્ષા આધારરેખા PFS માંગે છે, તો ઉકેલ એ જૂથ છે જે બંને બાજુએ બંને peer સ્વીકારે, જે મેળ ખાતી નીતિ દ્વારા વ્યક્ત થાય છે. ભૂલ અદૃશ્ય કરવા PFS બંધ કરવું એ સુરક્ષા ગુણધર્મ બદલે છે જે તમે જાળવવા માંગતા હતા, અને તે સામાન્ય રીતે પછી બીજી અસંગતિ તરીકે પાછું આવે છે.

Azure-વિશિષ્ટ એક જાળ: જ્યારે તમે ESP માટે GCM પસંદ કરો, ત્યારે એન્ક્રિપ્શન અને અખંડતાની પસંદગીઓએ એ જ GCM અલ્ગોરિધમ અને એ જ કી લંબાઈનું નામ આપવું પડે. GCM સાઈફરને અલગ અખંડતા અલ્ગોરિધમ સાથે મિશ્ર કરવાથી એવું સંયોજન બને છે જે સેવા નકારે છે, અને નીતિ ધ્યાનથી ન વાંચો ત્યાં સુધી તે peer અસંગતિ જેવું લાગે છે.

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

નિષ્ફળ ગયેલા વિનિમયની ચકાસણી કરો

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

બે ભ્રામક સંકેતોનું નામ આપવા યોગ્ય છે. SA આયુષ્ય સ્થાનિક વિશિષ્ટતાઓ છે, તેથી અસમાન મૂલ્યો સામાન્ય છે અને તેમને બદલવાથી ફક્ત સમસ્યા ક્યારે દેખાય તે ખસે છે. DPD નક્કી કરે છે કે peer જીવંત છે કે નહીં; તેની સમયમર્યાદા વધારવાથી ESP કે PFS પસંદગીઓ સુસંગત થતી નથી.

ફેરફાર પછી વાટાઘાટિત પરિણામ અને આગલી ઘટના નોંધો. જો જોડાણ હવે IKE પ્રમાણીકરણ પૂર્ણ થાય તે પહેલાં નિષ્ફળ જાય, તો તમે હમણાં સંપાદિત કરેલા IKE સેટિંગ્સ જોઈ રહ્યા છો, મૂળ CHILD-નવીકરણ નિષ્ફળતા નહીં.