IKEv1 యొక్క హైబ్రిడ్ ప్రామాణీకరణ IKEv2 యొక్క వినియోగదారు ప్రామాణీకరణలోకి ఎలా మారుతుంది
హైబ్రిడ్ మోడ్ గేట్వే రుజువును వినియోగదారు రుజువు నుండి వేరు చేసేది. IKEv2 కి మారినప్పుడు ఆ విభజన కొనసాగుతుంది, కానీ మార్పిడి, EAP పద్ధతి మరియు ధృవపత్ర తనిఖీలు మారుతాయి.
మొదట సర్వర్ ధృవపత్రం, తర్వాత వినియోగదారు పేరు అడిగే ప్రతి పాత VPN ప్రొఫైల్ ఒకే మార్పిడిలో ప్రామాణీకరణ యొక్క రెండు సంఘటనలను మోస్తుంది, ఈ ఆకృతి దానిని తెచ్చిన ప్రోటోకాల్ కంటే ఎక్కువ కాలం జీవిస్తుంది. IKEv1 యొక్క హైబ్రిడ్ మోడ్ సరిగ్గా దీని కోసమే నిర్మించబడింది: గేట్వే తనను తాను పబ్లిక్ కీతో నిరూపించుకుంటుంది, వినియోగదారు తర్వాత XAuth ద్వారా తనను నిరూపించుకుంటాడు. IKEv2 అదే రెండు-దశల భావనను మరో యంత్రాంగంతో వ్యక్తపరుస్తుంది, ఈ భేదాల్లోనే స్థానభ్రంశాలు విఫలమవుతాయి. ఏ వెర్షన్ సంఖ్యా ఒకదాన్ని మరొకటిగా మార్చదు, పాత ఎంపికల పేర్లను కొత్త ప్రొఫైల్లో కాపీ చేయడం చర్చలు జరిపి తర్వాత ఏమీ ప్రామాణీకరించని క్లయింట్ను ఇస్తుంది.
హైబ్రిడ్ మోడ్ IKEv1 లోపల ఏమి చేసింది
హైబ్రిడ్ ప్రొఫైల్లో స్పందించే పక్షం మొదటి దశ మార్పిడిని తన ధృవపత్రంతో సంతకం చేస్తుంది, ప్రారంభకుడు ఉద్దేశపూర్వకంగా ఏ ధృవపత్రాన్ని చూపించడు. కాబట్టి గుర్తింపు రుజువు అసమమితం, ఇదే గేట్వే తన ప్రస్తుత PKI ను ఉంచుకోవడానికి, వినియోగదారులు తమ డైరెక్టరీ పాస్వర్డ్లను ఉంచుకోవడానికి దారితీసింది. మొదటి దశ పూర్తయ్యాక XAuth అభ్యర్థన మరియు సమాధానంగా నడుస్తుంది, అవి ఇప్పుడు గుప్తీకరించిన ISAKMP ఛానెల్ లోపల వినియోగదారు పేరు మరియు పాస్వర్డ్ లక్షణాలను మోస్తాయి.
నమ్మకం ఎక్కడ పడుతుందో గమనించండి. ధృవపత్రం క్లయింట్ ఏ గేట్వేను చేరుకుందో సమాధానమిస్తుంది; XAuth ఏ వినియోగదారు ప్రాప్యత కోరుతున్నారో సమాధానమిస్తుంది. ఒకటి మరొకదానికి ప్రత్యామ్నాయం కాదు, ఏ సర్వర్ ధృవపత్రాన్నైనా అంగీకరించేలా పెట్టిన క్లయింట్ మొదటి సమాధానాన్ని నిశ్శబ్దంగా పారేసింది. హైబ్రిడ్ అనే లేబుల్ ముందే పంచుకున్న కీతో కూడిన ఆక్రమణ మోడ్ మరియు XAuth కోసం కూడా వాడబడుతుంది, అది అదే వినియోగదారు అనుభవంతో ఉన్న వేరే ఏర్పాటు, కాబట్టి పేరు కాదు, ప్రొఫైల్ చదవండి. రెండు రూపాలూ ఎప్పుడూ ప్రమాణం కాని ముసాయిదాల నుండి వస్తాయి, అందుకే ఇద్దరు తయారీదారులు హైబ్రిడ్ మోడ్ను అమలు చేసి ఎవరితోనూ పరస్పర చర్య లేకుండా ఉండవచ్చు.
IKEv2 అదే రెండు రుజువులను ఎలా చేరుకుంటుంది
IKEv2 పనిని IKE_SA_INIT మరియు IKE_AUTH మధ్య విభజిస్తుంది. మొదటి మార్పిడి ఎటువంటి గుర్తింపు లేకుండా ప్రతిపాదనలు మరియు కీలపై అంగీకరిస్తుంది; రెండవది IDi, IDr మరియు AUTH భారాలను మోస్తుంది. EAP కింద ప్రారంభకుడి మొదటి AUTH భారం ఖాళీగా వెళ్తుంది, స్పందించే పక్షం మొదట తన ధృవపత్రంతో, సంతకంతో ప్రామాణీకరించబడుతుంది, ఆ తర్వాత EAP సంభాషణ IKE_AUTH సందేశాల లోపల నడుస్తుంది.
దీన్ని సురక్షితం చేసే యంత్రాంగం కీ పదార్థం. విజయవంతమైన EAP పద్ధతి సెషన్ కీని ఎగుమతి చేస్తుంది, ప్రారంభకుడి చివరి AUTH భారం దాని నుండి లెక్కించబడుతుంది, కాబట్టి వినియోగదారు రుజువు మరియు సొరంగం కీలు ఒకదానితో ఒకటి బంధించబడతాయి. XAuth కి అలాంటి సమానార్థం లేదు: దాని లక్షణాలు మొదటి దశ తర్వాత వస్తాయి, కీలకు ఏమీ జోడించవు. ఈ ఖాళీని పూరించడానికే IKEv2 చట్రం రూపొందించబడింది, అందుకే పనిచేసే IKEv2 లాగిన్ ఏదైనా అడిగే ముందు సర్వర్ ధృవపత్రాన్ని ధృవీకరిస్తుంది.
ఈ క్రమం ఉపయోగకరమైన నిర్ధారణ కూడా. క్లయింట్ మీకు ధృవపత్రం చూపించక ముందే ఆధారాల గురించి ఫిర్యాదు చేస్తే, అతను IKEv2 EAP మార్పిడి అసలు చేయడం లేదు.
మూడు గుర్తింపులను వేరుగా ఉంచండి
మూడు గుర్తింపులు ఒకే క్షేత్రంలో కుప్పకూలినప్పుడు స్థానభ్రంశం తప్పుగా జరుగుతుంది. క్లయింట్ ధృవీకరించే గేట్వే గుర్తింపు ఉంది, సాధారణంగా ధృవపత్రం యొక్క subject లేదా SAN లో DNS పేరు. EAP లో అందించే వినియోగదారు గుర్తింపు ఉంది, డొమైన్ లాగిన్, చిరునామా లేదా స్పష్టమైన EAP గుర్తింపు స్ట్రింగ్ కావచ్చు. మరియు ఆ వినియోగదారుని నెట్వర్క్లకు, మార్గాలకు మ్యాప్ చేసే అనుమతి మూలం ఉంది.
strongSwan యొక్క swanctl వాక్యనిర్మాణం విభజనను కనిపించేలా చేస్తుంది: కనెక్షన్ గేట్వే కోసం remote { auth = pubkey } మరియు వినియోగదారు కోసం local { auth = eap-mschapv2 } సెట్ చేస్తుంది, EAP గుర్తింపు విడిగా మోయబడుతుంది.
కొత్త ప్రొఫైల్లో వినియోగదారు గుర్తింపు పాత XAuth లక్షణాలకు భిన్నంగా ఉంటే, ఉదాహరణకు చిన్న పేరుకు బదులు UPN, ప్రామాణీకరణ సర్వర్ తెలియని వినియోగదారుని చూస్తుంది, వైఫల్యం తప్పు పాస్వర్డ్లా కనిపిస్తుంది. ఆధారాలను తనిఖీ చేసే ముందు గుర్తింపు స్ట్రింగ్ను తనిఖీ చేయండి.
ఎంపికలను మ్యాప్ చేయండి, తర్వాత ఉచ్చులను ఆశించండి
మ్యాపింగ్ చిన్నది, ప్రతి వరుసలో ప్రామాణీకరణ సమయంలో మాత్రమే కనిపించే ఒక ఉచ్చు ఉంటుంది.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
ఆ వరుసల్లో ఏదీ కేవలం పేరు మార్పు కాదు. కాన్ఫిగరేషన్ భారం చిరునామాలు మరియు రిజాల్వర్లను టైప్ చేసిన లక్షణాల జాబితా ద్వారా అందిస్తుంది, XAuth యొక్క లక్షణ క్షేత్రం దాని సొంత ఆవిష్కరణ; వాటిని పరస్పరం మార్చుకోగలిగినవిగా భావించడమే ప్రొఫైల్ గేట్వే ఎప్పుడూ పంపని సెట్టింగ్ను అడిగే మార్గం.
ట్రాఫిక్ ఎంపికకర్తలు తమకంటూ హెచ్చరికకు అర్హులు. IKEv1 ఆసక్తికర ట్రాఫిక్ను quick mode మార్పిడికి కట్టుబడిన ప్రాక్సీ ఐడీలతో వ్యక్తపరిచేది, IKEv2 IKE_AUTH సమయంలో ఎంపికకర్తలపై చర్చలు జరిపి స్పందించే పక్షం వాటిని సన్నగా చేయవచ్చు. సరిపోకపోవడం child SA లేని స్థాపిత IKE SA ను సృష్టిస్తుంది, కొన్ని క్లయింట్లు దాన్ని సంతోషంగా అనుసంధానమైనట్లు చూపిస్తాయి.
పాత కనెక్షన్ను సరిహద్దుగా పరిగణించండి
RFC 9395 IKEv1 ను వాడుకలో లేనిదిగా ప్రకటిస్తుంది, కాబట్టి పాత హైబ్రిడ్ కనెక్షన్ తేదీ ఉన్న అనుకూలత సరిహద్దు, పునాది కాదు. మార్పు సమయంలో రెండు ప్రొఫైల్లను పక్కపక్కనే నడపండి, ఎందుకంటే ముఖ్యమైన పరీక్ష కొత్త ప్రొఫైల్ లేస్తుందా అన్నది కాదు, అదే వినియోగదారు అదే పరికరంలో అదే వనరులను చేరుకుంటారా అన్నది.
ధృవపత్ర ధృవీకరణను మొదటి నుండి చివరి వరకు కఠినంగా ఉంచండి. క్లయింట్ తన ధృవపత్రాన్ని చూపించడం ఆపిన వెంటనే, చేతులు కలపడం పూర్తయ్యే వరకు సర్వర్ తనిఖీని సడలించాలనే ప్రలోభం వస్తుంది, అది మిగిలిన ఏకైక రుజువును ఆకుపచ్చ గుర్తుతో భర్తీ చేస్తుంది.
పాత ప్రొఫైల్ను విరమించే ముందు నాలుగు విషయాలు రాయండి: EAP పద్ధతి, గుర్తింపు స్ట్రింగ్, అనుమతి మూలం మరియు మద్దతు ముగిసే తేదీ.