ఒక IKEv2 లాగిన్లో రెండు గుర్తింపులు: యంత్రం, ఆ తర్వాత వినియోగదారు

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

లక్షణం: విజయవంతమైన మొదటి రుజువు తర్వాత వైఫల్యం

మొదటి మార్పిడి పూర్తవుతుంది, లాగ్ ఆరోగ్యంగా కనిపిస్తుంది, గేట్వే EAP ద్వారా వినియోగదారు గుర్తింపును అడిగే వరకు. తర్వాత హ్యాండ్షేక్ ఆగిపోతుంది లేదా అదనపు రౌండ్ను పేర్కొనే ప్రోటోకాల్ లోపాన్ని తిరిగి ఇస్తుంది. పూర్తిగా చెల్లుబాటు అయ్యే యంత్ర సర్టిఫికెట్ దాని చెల్లుబాటుకు సంబంధం లేని కారణంతో తిరస్కరించబడుతోంది. విధానం రెండవ రుజువును అడిగింది, క్లయింట్ సమాధానం ఎప్పుడూ రాలేదు.

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

పొడిగింపు ఏమి జోడిస్తుంది, ఏమి జోడించదు

IKEv2 ఒకే సెషన్లో ఒకటి కంటే ఎక్కువ ప్రామాణీకరణ మార్పిడులను నడపడానికి ఒక పొడిగింపును కలిగి ఉంది. RFC 4739, ఇతర క్రమాలతో పాటు, ఒక క్లయింట్ సర్టిఫికెట్ గుర్తింపును నిరూపించి, ఆ తర్వాత EAP ద్వారా ఒక వ్యక్తిని ప్రామాణీకరించడాన్ని రూపొందిస్తుంది. పత్రం ప్రయోగాత్మకం, అంటే ఏ అమలు కూడా ఆ ఫీచర్ను మీకు అప్పుగా ఇవ్వదు. తోటి వైపు దానిని బేరమాడే వరకు మద్దతు గురించి ఏమీ ఊహించవద్దు.

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

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

EAP-TLS మూడవ రూపం, అది కూడా ఇది కాదు. అక్కడ క్లయింట్ సర్టిఫికెట్ EAP పద్ధతిలో ప్రదర్శించబడుతుంది, కాబట్టి క్లయింట్ ఇప్పటికీ ఒకే IKE ప్రామాణీకరణను పూర్తి చేస్తుంది. ఆధారాలు బహుళ రౌండ్ కేసుతో సమానంగా కనిపించవచ్చు, ప్రోటోకాల్ రెండు కాకుండా ఒక రౌండ్ను మోసుకెళుతుంది. అందుకే EAP-TLS విస్తరణ నుండి కాపీ చేసిన డిజైన్ రెండవ రుజువు ఆశించే స్థానంలో విఫలమవుతుంది.

అదే ఫైల్ గేట్వేలో భిన్నంగా చదవబడుతుంది

అదే swanctl ఫైల్ ఎక్కడ నడుస్తుందనే దానిపై భిన్నంగా చదవబడుతుంది, అదే ప్రజలను కలవరపెట్టే భాగం. ల్యాప్టాప్లో గేట్వే తోటి వైపు, గేట్వేలో ల్యాప్టాప్ అలా ఉంటుంది, కాబట్టి local వైపును నేను ఎవరు అనీ, remote వైపును నేను ఎవరిని అంగీకరిస్తాను అనీ రాయండి. local బ్లాక్ ఈ ఎండ్పాయింట్ తనను తాను ఎలా ప్రామాణీకరించుకుంటుందో వివరిస్తుంది, remote బ్లాక్ మరొక చివర నుండి ఏమి కోరుతుందో తెలియజేస్తుంది. రెండు ఫైళ్ల మధ్య బ్లాక్ను కాపీ చేయడం ఒక్క అక్షరం మార్చకుండా దాని అర్థాన్ని తలకిందులుగా మారుస్తుంది. రెండు ఫైళ్లను పోల్చడం దాదాపు ఏమీ చెప్పదు, ఎందుకంటే అదే పదాలు ప్రతి దానిలో వ్యతిరేక అర్థాలను ఇస్తాయి.

ఒక విభాగం స్థానం దాని క్రమాన్ని నిర్ణయిస్తుంది, ఒక రౌండ్ సంఖ్య దానిని అధిగమించకపోతే. అదనపు local లేదా remote విభాగాలు అందువల్ల ప్రత్యామ్నాయాలకు బదులుగా అదనపు రౌండ్లను వివరిస్తాయి, మరియు swanctl.conf సూచనలోని స్పష్టమైన రౌండ్ సంఖ్య ఆ క్రమాన్ని ఉద్దేశపూర్వకంగా చేయడానికే ఉంది. అది లేకుండా, బ్లాక్ను కదిలించడం ప్రవర్తనను మారుస్తుంది. అందుకే కాగితంపై సమానంగా కనిపించే రెండు కాన్ఫిగరేషన్లు వ్యతిరేక క్రమంలో ప్రవర్తించగలవు.

ఆ క్రమ నియమం గుర్తుంచుకోదగిన వైఫల్య విధానాన్ని ఉత్పత్తి చేస్తుంది. రెండవ remote బ్లాక్ మరో ఆమోదయోగ్యమైన ఎంపిక కాదు; అది రెండవ డిమాండ్, అందుకే ఇది/అది అని చదివే విధానం మరియు-తర్వాతగా ప్రవర్తిస్తుంది. ఒక గేట్వే విధానం నమోదైన యంత్రం సర్టిఫికెట్ను అంగీకరించి, ఆ తర్వాత ఆ వినియోగదారు EAP మార్పిడిని అదే క్రమంలో కోరవచ్చు.

రౌండ్లను స్వతంత్ర కారకాల నుండి వేరు చేయండి

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

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

ప్రతి రౌండ్ నిజంగా ఏమి నిరూపిస్తుందో జోడించే ముందు రాయండి. రెండు రౌండ్లు ఒకే విషయాన్ని రెండుసార్లు నిరూపిస్తే, రెండవది భరోసాకు బదులుగా ఆలస్యాన్ని, మద్దతు టికెట్లను జోడిస్తుంది. ఆ గమనికే అదనపు రౌండ్ దాని ఖర్చుకు తగినదా అనే వాదనను ఆపుతుంది.

జత నియమాన్ని రాసి తిరస్కరణలను పరీక్షించండి

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

తర్వాత విఫలమవాల్సిన వాటిని పరీక్షించండి: ఆమోదించబడని యంత్రంపై ఆమోదించబడిన వినియోగదారు, యంత్ర ఆధారాన్ని కలిగి ఉన్న ఆమోదించబడని వినియోగదారు, అదనపు రౌండ్ను చేయలేని తోటి వైపు. మూడూ నిశ్శబ్దంగా ఒకే యాక్సెస్ను పొందితే, విధానం అమలు చేయడానికి బదులుగా ఒక ఉద్దేశాన్ని వివరిస్తుంది. ప్రకటించిన కాన్ఫిగరేషన్ను డీమన్ నివేదించే దానితో పోల్చండి, ఎందుకంటే ఎప్పుడూ సరిపోలని కనెక్షన్ దాటిన నియమంలా సమానంగా కనిపిస్తుంది:

swanctl --list-conns
swanctl --list-sas

బేరమాడిన రౌండ్లను, వాటి ఫలిత అనుమతిని తనిఖీ చేయండి, విజయవంతమైన లాగిన్ మాత్రమే కాదు. పాత IKEv1 XAuth సెట్టింగ్లను సత్వరమార్గంగా ఉపయోగించవద్దు: కనెక్షన్ విజయవంతమయ్యే వరకు అవసరమైన రౌండ్ను తొలగించడానికి బదులుగా ప్రోటోకాల్, పాత్రలు, క్రమం మరియు క్లయింట్ యొక్క నిజమైన ప్రవర్తనను సరిపోల్చండి. విఫలమయ్యే రౌండ్ను తొలగించడమే రెండు రుజువుల డిజైన్ ఎవరూ సమీక్షించని ఒక రుజువు డిజైన్గా నిశ్శబ్దంగా మారే మార్గం. తొలగింపును మార్పు రికార్డులో ఉంచండి.