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-పునరుద్ధరణ వైఫల్యాన్ని కాదు.