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 உள்ளமைக்கப்பட்டால், peer-கள் புதிய சாவிப் பரிமாற்றத்தை செய்கின்றன, இரு தரப்பும் ஏற்கும் குழு மற்றும் புதிய தொடர்புக்கான 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-புதுப்பித்தல் தோல்வியை அல்ல.