IKEv2 NO_PROPOSAL_CHOSEN: ఏ దశ సూట్ను తిరస్కరించింది?

లాగ్లో NO_PROPOSAL_CHOSEN చూసినప్పుడు ప్రజలు ముందుగా పంచుకున్న కీ వైపు పరిగెత్తుతారు, కీ మార్చిన తర్వాత కూడా లోపం కొనసాగుతుంది. ఇది ఎప్పుడూ ఆధారాల సమస్య కాదు: సహచరుడు ఆ మార్పిడి కోసం ఇచ్చిన ప్రతి ప్రతిపాదనను తిరస్కరించాడు, అది గుర్తింపు గురించి కాదు, అల్గారిథమ్ల గురించిన ప్రకటన. మొదటి ఉపయోగకరమైన ప్రశ్న ఏ అల్గారిథమ్ను సవరించాలి అనేది కాదు, ఏ మార్పిడి తిరస్కరించబడింది అనేది. ఏదైనా పోల్చడానికి ముందు దానికి సమాధానం ఇవ్వండి. తర్వాత ప్రతిపాదిత పూర్తి సూట్ను సహచరుడు అనుమతించే పూర్తి సూట్తో పోల్చండి.

మొదట: ఏ మార్పిడి తిరస్కరించబడింది

IKEv2 రెండు రకాల సంఘాలను చర్చిస్తుంది. IKE SA చర్చను స్వయంగా కాపాడుతుంది, CHILD SA ట్రాఫిక్ను కాపాడుతుంది. ప్రతి దానికి స్వంత ప్రతిపాదన సమూహం ఉంది, ప్రతి ఒక్కటి అదే నోటిఫికేషన్తో విఫలమవుతుంది. ప్రారంభ IKE చర్చల సమయంలో తిరస్కరణ మరియు CHILD చర్చల సమయంలో తిరస్కరణ వేర్వేరు సరిదిద్దుకోవడాలు అవసరం, మరియు లాగ్ సాధారణంగా నోటిఫికేషన్కు ఒకటి లేదా రెండు పంక్తులు పైన మార్పిడిని పేర్కొంటుంది. ఆ రెండు పంక్తులను కలిపి చదవండి, లేకపోతే తప్పు ప్రతిపాదన జాబితాను సవరిస్తారు.

కేవలం నోటిఫికేషన్ మార్పిడిని గుర్తించదు. దాని పైన ఉన్న పంక్తి చర్చిస్తున్న SAని పేర్కొంటుంది, ఆ పేరు తనిఖీ చేయవలసిన ప్రతిపాదన జాబితాను సూచిస్తుంది.

పూర్తి సూట్లను పోల్చండి, వ్యక్తిగత కీవర్డ్లను కాదు

ప్రతిపాదన ఒక కలయిక: ఎన్క్రిప్షన్ అల్గారిథమ్, సమగ్రత లేదా AEAD, కీ-మార్పిడి సమూహం, మరియు ఏదైనా సూడో-రాండమ్ ఫంక్షన్. ఎన్క్రిప్షన్ పేరును మాత్రమే పోల్చడం సాధారణ పొరపాటు, ఎందుకంటే ఇద్దరు సహచరులు AES-256పై అంగీకరించి కూడా SHA-1 మరియు SHA-256 విషయంలో భిన్నాభిప్రాయం కలిగి ఉండవచ్చు. విఫలమైన దశలో ప్రతిపాదిత మరియు అనుమతించిన సూట్లను పక్కపక్కన రాయండి, తర్వాత ఖాళీ ఖండనను వెతకండి.

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

రెండు అమలులు మీరు కాన్ఫిగర్ చేసినదాన్ని మద్దతు ఇస్తున్నాయా అని కూడా తనిఖీ చేయండి. మరొక ప్లాట్ఫారమ్ నుండి కాపీ చేసిన పేరు వాక్యనిర్మాణపరంగా పరిచయంగా కనిపించవచ్చు అయితే ప్లగిన్ లేదా అమలు పూర్తిగా లేదు.

IKE సూట్ మరియు ESP సూట్ వేర్వేరు వస్తువులు

IKE ప్రతిపాదనను సవరించడం తిరస్కరించబడిన CHILD ప్రతిపాదనను సరిచేయదు, దీనికి విరుద్ధంగా కూడా నిజం. strongSwanలో ఇవి వేర్వేరు సెట్టింగ్లు, సుమారు IKE SAకు proposals = aes256-sha256-modp2048 మరియు CHILD SAకు వేరే ESP జాబితా. విఫలమైన మార్పిడికి సరిపోయే జాబితాను మార్చి, తర్వాత సరిదిద్దుకోవడం పని చేసిందని భావించకుండా లాగ్ను మళ్లీ చదవండి.

CHILD SAకు సంబంధిత సెట్టింగ్ ESP ప్రతిపాదన జాబితా, IKE జాబితా కాదు. అందులో IKE పంక్తిని కాపీ చేయడం పార్స్ అయ్యే కానీ తప్పు వస్తువుపై చర్చించే కాన్ఫిగరేషన్ను సృష్టిస్తుంది.

పని చేసే సొరంగం కీ పునరుద్ధరణలో విఫలమవుతుంది

సొరంగం ఒక గంట పని చేసి తర్వాత విఫలమైతే, ప్రారంభ చర్చ సమస్య కాదు. కీ పునరుద్ధరణ ఇతర పరిస్థితులను పరీక్షించవచ్చు: మొదటి మార్పిడి తర్వాత వేరే కీ-మార్పిడి సమూహం, సహచరుల మధ్య జీవితకాల అసమతౌల్యం, లేదా మారిన ప్రతిస్పందన విధానం. రెండు వైపుల నుండి పునరుద్ధరణ టైమ్స్ట్యాంప్ మరియు సంఘ గుర్తింపులను ఉంచండి. ఆ నమూనాకు పునరుద్ధరణలో ప్రతిపాదన పోలిక అవసరం, పొడవైన టైమౌట్ కాదు. టైమౌట్ మార్పు లక్షణాన్ని దాచి అసమతౌల్యాన్ని అక్కడే ఉంచుతుంది.

ipsec statusall ప్రతి సంఘాన్ని మరియు వాస్తవంగా చర్చించిన అల్గారిథమ్లను చూపిస్తుంది. ఆ అవుట్పుట్ ఏ జాబితా ఉపయోగించబడిందో నిర్ధారించడానికి వేగవంతమైన మార్గం, మరియు కాన్ఫిగరేషన్ లోపాన్ని ఎప్పుడూ తిరిగి చర్చించని పాత సొరంగం నుండి వేరు చేస్తుంది.

ipsec statusall | grep -E "IKE:|ESP:"

ఒక ఖండనను ఎంచుకోండి, తర్వాత రెండు దశలను నిర్ధారించండి

నిర్వాహకుడిని ఇద్దరు సహచరులు మద్దతు ఇచ్చే పత్రబద్ధమైన ఆధునిక ఖండనను ఎంచుకోమని మరియు రాయమని అడగండి. అన్ని పాత అల్గారిథమ్లను ప్రారంభించి లేదా గుర్తింపు ధృవీకరణను నిలిపివేసి లోపాన్ని పరిష్కరించవద్దు, ఎందుకంటే రెండూ తిరస్కరణ నుండి రావు. మార్పు తర్వాత కొత్త కనెక్షన్ను ఏర్పాటు చేసి, తర్వాత కీ పునరుద్ధరణను బలవంతం చేయండి. మొదటి కనెక్షన్ మాత్రమే పునరుద్ధరణ మార్గం పని చేస్తుందని నిరూపించదు.

ఆమోదించిన కలయికను ఫర్మ్వేర్ సంస్కరణలతో ఉంచండి. తదుపరి లోపం ట్రాఫిక్ ఎంపికదారులకు సంబంధించినదైతే, దానిని విడిగా పరిగణించండి, ఎందుకంటే క్రిప్టోగ్రాఫీపై ఒప్పందం సొరంగం ఏ సబ్నెట్లను కాపాడుతుందో గురించి ఏమీ చెప్పదు. strongSwan యొక్క ప్రతిపాదన పత్రం రెండు జాబితాల వాక్యనిర్మాణాన్ని కవర్ చేస్తుంది.