IPsec ప్రతిపాదనలో ఏమి ఉంటుంది? IKE మరియు ESP ఫీల్డ్‌లు
ప్రతిపాదన అంటే ఒక పూర్తి ఆఫర్, అల్గారిథమ్‌ల సంచి కాదు. ఏ ఫీల్డ్‌లు IKE కి, ఏవి ESP కి చెందుతాయో, మరియు ఒక అసమతౌల్యం ఎందుకు మొత్తం సెట్‌ను తిరస్కరిస్తుందో చూడండి.
IKE ప్రారంభమవుతుంది, రెండు వైపులా AES ప్రకటిస్తాయి, అయినా టన్నెల్ NO_PROPOSAL_CHOSEN తో విఫలమవుతుంది. లాగ్ ప్రతిపాదన పేరును చెబుతుంది కానీ సరిపోలని ఫీల్డ్‌ను చెప్పదు. ప్రతిపాదన ఒక పూర్తి ఆఫర్, మరియు ఒక అననుకూల ఫీల్డ్ ఆ వరుసను మాత్రమే కాక మొత్తం కలయికను చెల్లదని చేస్తుంది. దీన్ని స్వతంత్ర అల్గారిథమ్ ఎంపికల సంచిగా చదవడమే అసమతౌల్యం అదృశ్యంగా ఉండటానికి సాధారణ కారణం.
వేర్వేరు ప్రతిపాదన జాబితాలతో రెండు చర్చలు
IKEv2 రెండు భద్రతా సంఘాలను నిర్మిస్తుంది. మొదటిది నియంత్రణ మార్పిడిని స్వయంగా కాపాడే IKE SA, రెండవది మీ ట్రాఫిక్‌ను ESP ద్వారా తీసుకెళ్లే CHILD SA. ప్రతిదానికి దాని స్వంత ప్రతిపాదన జాబితా ఉంటుంది, మరియు ఒక వైపు ఒకదాన్ని అంగీకరించి మరొకదాన్ని తిరస్కరించవచ్చు.
ఈ విభజన సాధారణ గందరగోళాన్ని వివరిస్తుంది: పనిచేసే IKE SA నియంత్రణ ఛానెల్ అల్గారిథమ్‌లు సరిపోలాయని మాత్రమే నిరూపిస్తుంది. CHILD ప్రతిపాదన విఫలమైతే, మొదటి దశ పూర్తయి లాగ్‌లు పైన ఆరోగ్యంగా కనిపించినా, టన్నెల్ ఒక్క ప్యాకెట్ కూడా మోసుకెళ్లదు.
ప్రతి జాబితా లోపలి క్రమం కూడా ముఖ్యం. ప్రతిస్పందించేవాడు ప్రారంభకుడి క్రమబద్ధ ఆఫర్ల నుండి ఎంచుకుంటాడు, కాబట్టి విస్తృతంగా సరిపోయే నమోదును ఇరుకైన దానికి పైనకు జరపడం ఏ సెట్ ఇన్‌స్టాల్ అవుతుందో మారుస్తుంది, ఏ అల్గారిథమ్ పేరు మారకుండానే. డిఫాల్ట్‌లపై ఆధారపడకుండా ఆ క్రమాన్ని కాన్ఫిగరేషన్‌లో పిన్ చేయండి. స్థిరమైన క్రమం సైట్‌ల మధ్య లాగ్ పోలికను కూడా అర్థవంతం చేస్తుంది.
ఏ ఫీల్డ్‌లు ఏ ప్రతిపాదనకు
ఫీల్డ్‌ల సెట్ చిన్నది, కానీ రెండు చర్చలలో ఒకేలా ఉండదు. ఒక నిలువు వరుసలోని ఫీల్డ్ మరొకదానిలో లేకపోవచ్చు, కాబట్టి పట్టికను వరుస వరుసగా చదవండి. వాక్యనిర్మాణం అమలుపై ఆధారపడి మారుతుంది; strongSwan ప్రతిపాదన పత్రాలు ఒక నిర్దిష్ట సూచన.
| Field | IKE SA proposal | CHILD SA proposal |
|---|---|---|
| Encryption | Required | Required |
| Integrity | Required unless AEAD | Required unless AEAD |
| PRF | Required | Not present |
| DH group | Required | Only for PFS |
| ESN | Not present | Optional |
ఎన్‌క్రిప్షన్ ఫీల్డ్ సైఫర్‌ను మరియు చాలా వాక్యనిర్మాణాలలో దాని కీ పొడవును సూచిస్తుంది. సమగ్రత ఫీల్డ్ సైఫర్ టెక్స్ట్‌ను ధృవీకరించడానికి ఉపయోగించే హాష్‌ను సూచిస్తుంది, PRF IKE SA కోసం కీ పదార్థాన్ని పొందే ఫంక్షన్‌ను సూచిస్తుంది. DH సమూహం కొత్త భాగస్వామ్య రహస్య పదార్థాన్ని ఏర్పాటు చేస్తుంది, అందుకే అది రెండు వైపులా కనిపిస్తుంది, కానీ వేర్వేరు లక్ష్యాల కోసం.
విస్తరించిన క్రమ సంఖ్యలు డేటా మార్గానికి మాత్రమే చెందుతాయి. అవి క్రమ స్థలాన్ని విస్తరిస్తాయి మరియు CHILD ప్రతిపాదనలో భాగంగా చర్చించబడతాయి, కాబట్టి అక్కడి అసమతౌల్యం CHILD ఆఫర్‌ను తిరస్కరిస్తుంది, IKE SA తాకబడకుండా ఉంటుంది.
ఒక పూర్తి ఆఫర్ ఎలా ఎంపిక చేయబడుతుంది
ప్రతి ప్రతిపాదన ఒక సెట్, ప్రతిస్పందించేవాడు ప్రతి తప్పనిసరి ఫీల్డ్ ఆమోదయోగ్యంగా ఉన్న సెట్‌ను వెతుకుతాడు. రెండు జాబితాలలో AES మరియు SHA-256 ఉండవచ్చు, అయినా సరిపోయే నమోదు లేకపోవచ్చు, ఎందుకంటే కీ పొడవు, PRF లేదా DH సమూహం భిన్నంగా ఉంటాయి. పోలిక ప్రతి అల్గారిథమ్‌కు కాదు, ప్రతి ప్రతిపాదనకు జరుగుతుంది.
ఏదీ సరిపోలకపోతే, ప్రతిస్పందించేవాడు విఫలమైన SA రకంతో NO_PROPOSAL_CHOSEN పంపుతాడు. కాన్ఫిగరేషన్‌ను సవరించే ముందు నోటిఫికేషన్ ఏ ప్రతిపాదన జాబితాకు సంబంధించిందో చదవండి; IKE ప్రతిపాదన తిరస్కరించబడినప్పుడు ESP అల్గారిథమ్‌లను మార్చడం ఒక డీబగ్ చక్రాన్ని వృథా చేస్తుంది.
ప్రొఫైల్ ట్యూన్ చేసేటప్పుడు ఎంపిక ప్రవర్తనను తెలుసుకోవడం ఉపయోగం. కొన్ని అమలులు ప్రారంభకుడి క్రమాన్ని ఇష్టపడతాయి, మరికొన్ని స్థానిక విధానం ప్రకారం తిరిగి క్రమబద్ధీకరిస్తాయి, కాబట్టి రెండు విక్రేతల మధ్య పనిచేసే సెట్ అదృశ్యమవచ్చు కనెక్షన్‌ను ఏ వైపు ప్రారంభిస్తుందో మీరు తిప్పినప్పుడు.
AEAD ఫీల్డ్‌ను జోడించడం బదులు తీసివేస్తుంది
AES-GCM మరియు ChaCha20-Poly1305 ఒకే కార్యకలాపంలో ధృవీకరణ మరియు ఎన్‌క్రిప్షన్ చేస్తాయి. వాటిలో ఏదైనా ESP కోసం ఎంపికయ్యాక, సమగ్రత అల్గారిథమ్ విడిగా చర్చించబడదు, ఎందుకంటే AEAD నిర్మాణం దాన్ని ఇప్పటికే కవర్ చేస్తుంది. కాబట్టి AES-GCM ను SHA-256 తో జోడించే ప్రతిపాదన ఉత్తమ స్థితిలో అనవసరం, అత్యంత చెడు స్థితిలో తిరస్కరించబడుతుంది.
IKE వైపు PRF ఇంకా వేరుగా ఉంటుంది, ఎందుకంటే అది పేలోడ్‌లను రక్షించడం బదులు నియంత్రణ ఛానెల్‌కు కీలను పొందుతుంది. అందుకే IKE ప్రతిపాదన AEAD సైఫర్‌ను PRF మరియు DH సమూహంతో చట్టబద్ధంగా కలపగలదు, అయితే సంబంధిత ESP ప్రతిపాదన AEAD సైఫర్ మరియు ఐచ్ఛిక PFS సమూహాన్ని మాత్రమే జాబితా చేస్తుంది.
కీ పొడవు ఎన్‌క్రిప్షన్ టోకెన్‌లో భాగం, కాబట్టి AES-128-GCM మరియు AES-256-GCM వేర్వేరు ఆఫర్లు. 256-bit కీలను ఊహించిన మార్గదర్శకం నుండి కాపీ చేసిన ప్రొఫైల్ 128-bit కోసం కాన్ఫిగర్ చేసిన ఎండ్‌పాయింట్‌తో సరిపోదు, రెండు పంక్తులు AES-GCM అని చెప్పినా. రెండు వైపులా సైఫర్ కుటుంబంపై అంగీకరించి కూడా గీత తర్వాతి సంఖ్య కారణంగా ఒకరినొకరు తిరస్కరించుకోవచ్చు.
కాన్ఫిగరేషన్ కాదు, ఇన్‌స్టాల్ చేసిన SA చదవండి
కాన్ఫిగర్ చేసిన ప్రతిపాదన జాబితా ఒక ఆఫర్; ఇన్‌స్టాల్ చేసిన SA ఫలితం. strongSwan మరియు Linux కెర్నల్‌లో రెండు వీక్షణలు అందుబాటులో ఉన్నాయి:
sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policyswanctl --list-sas ప్రతి SA కి చర్చించిన అల్గారిథమ్‌లను ముద్రిస్తుంది, CHILD AEAD ఉపయోగిస్తుందా అనేది కూడా కలిపి. ip xfrm state కెర్నల్ నిజంగా ఏమి ఇన్‌స్టాల్ చేసిందో చూపిస్తుంది, మరియు కీ పునరుద్ధరణ మీరు పత్రీకరించిన దాని నుండి భిన్నమైన సెట్‌కు తిరోగమించలేదని నిర్ధారించే స్థలం అక్కడే.
సవరణ తర్వాత ఆ అవుట్‌పుట్‌ను కాన్ఫిగరేషన్ పక్కన సేవ్ చేయండి. క్లయింట్ నవీకరణ దాని డిఫాల్ట్‌లను మార్చినప్పుడు, నమోదు చేసిన సెట్ పోలిక కోసం ఆధార రేఖను ఇస్తుంది, పోలిక విచారణను మొదటి నుండి ప్రారంభించడం బదులు కదిలిన ఫీల్డ్‌ను చూపిస్తుంది.