Windows మరియు FortiGateలో IKEv2: ప్రజలు కలిపేయు మూడు సెట్టింగ్లు
IKE కీ మార్పిడి, CHILD SA రక్షణ మరియు సహచర ప్రామాణీకరణ మూడు వేర్వేరు వరుసలు. రెండు సంభాషణల్లో సరిపోలే సమూహ సంఖ్యలు వాటిని కలపవు.
Windows క్లయింట్ మరియు FortiGate గేట్వే మధ్య IKEv2 ఒప్పందం విఫలమవుతూనే ఉంటుంది, సరిపోలని సంఖ్య కోసం వెతకడం మరింత పొడవైన సంఖ్యల జాబితాను ఇస్తుంది. ఆ జాబితా స్వతంత్రంగా విఫలమయ్యే మూడు వరుసలుగా విభజించినప్పుడే నిర్వహించదగినదవుతుంది: IKEని రక్షించే కీ మార్పిడి, CHILD SAకి వర్తించే రక్షణ, మరియు ప్రతి వైపు ఎవరో నిరూపించే ప్రామాణీకరణ. సమూహ సంఖ్యలు ఆ రెండు వరుసల్లో కనిపించి వేర్వేరు అర్థాలను ఇస్తాయి.
స్వతంత్రంగా విఫలమయ్యే మూడు వరుసలు
మొదటి వరుస IKE లోపల జరిగే కీ మార్పిడి, అది చర్చను రక్షించే కీలను ఉత్పత్తి చేస్తుంది. రెండవది CHILD SA కోసం ప్రతిపాదన, అది సొరంగం మోసే ట్రాఫిక్ను రక్షిస్తుంది. మూడవది ప్రామాణీకరణ, ప్రతి వైపు ఏమి ప్రదర్శిస్తుంది మరియు మరొక వైపు దానిని ఎలా ధృవీకరిస్తుంది అనేది అది నిర్ణయిస్తుంది.
వైఫల్యాలు వేర్వేరు చోట్ల పడతాయి. మార్పిడి వైఫల్యం ఏ సొరంగం ఏర్పడకముందే చర్చను ఆపుతుంది. CHILD SA వైఫల్యం ప్రామాణీకరణ విజయవంతమైన తర్వాత జరుగుతుంది, కొన్నిసార్లు కీ మార్పు సమయంలో మాత్రమే. మొదటి లోపాన్ని మాత్రమే చదివితే, ప్రామాణీకరణ వైఫల్యం లాగ్లలో మార్పిడి వైఫల్యంలా కనిపించవచ్చు.
వరుసలను విభజించడం లెక్కల పని కాదు. ఏ సెట్టింగ్ను మార్చడం విలువైనదో అది మారుస్తుంది, మరియు ఈ ప్రాంతం మొత్తంలో అత్యంత ఖరీదైన చర్యను నివారిస్తుంది, అది ప్రతిపాదన అసమతౌల్యాన్ని సరిచేయడానికి పనిచేస్తున్న సర్టిఫికెట్లను తిరిగి ఉత్పత్తి చేయడం. ఒక వరుస మారితే మిగిలిన రెండూ దానితో పాటు మారవలసిన అవసరం లేదు. వాటిని విడిగా రాయడం మొత్తం ఉద్దేశ్యం ఆ స్వాతంత్ర్యమే.
Windowsలోని రెండు ఫీల్డ్లు ఏమి నియంత్రిస్తాయి
Windows రెండు ఫీల్డ్లను వేరుగా ఉంచుతుంది: DHGroup IKE మార్పిడిని నిర్వహిస్తుంది, PfsGroup సొరంగ ట్రాఫిక్ను రక్షించే IPsec విధానాన్ని నిర్వహిస్తుంది. అవి వేర్వేరు దశలకు చెందుతాయి. Windows IKE ఫీల్డ్ను FortiGate phase-2 విలువతో పోల్చడం తప్పు జతను పరీక్షిస్తుంది, సంఖ్యలు సరిపోలినా అంతర్లీన మార్పిడి ఇప్పటికీ విఫలమవుతుంది.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAరెండవ మరియు మూడవ ఆదేశాలు వాస్తవంగా ఉన్న భద్రతా సంఘాలను నివేదిస్తాయి, క్లయింట్ మీకు ఇవ్వగల సమాధానానికి అదే దగ్గరగా ఉంటుంది. quick-mode సంఘం లేని main-mode సంఘం CHILD SA సమస్య, అది సర్టిఫికెట్ సమస్య కాదు, phase-2 అసమతౌల్యపు సంతకం.
ఒక ప్రయత్నంలో ఏమి అందించబడింది, ఏమి ఎంపికైంది అని నమోదు చేయండి. ఆమోదయోగ్యమైన ప్రతిపాదన ఉన్న అందించిన జాబితా, గేట్వే విధానంతో సరిపోలని ఎంపికైన ప్రతిపాదన అనేవి కాన్ఫిగరేషన్ విభేదం, ఇంటర్ఆపరేబిలిటీ రహస్యం కాదు.
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
దీర్ఘవృత్తాకార వక్ర సమూహం మీ సంతకం కీని ఎంచుకోదు
ఈ ప్రాంతంలో అత్యంత నిలకడైన తప్పు అనుమానం ఏమిటంటే దీర్ఘవృత్తాకార వక్ర DH సమూహాన్ని ఎంచుకోవడానికి దీర్ఘవృత్తాకార వక్ర సర్టిఫికెట్ అవసరం అని. DH సమూహం కీ మార్పిడి పదార్థాన్ని అందిస్తుంది; సంతకం అల్గోరిథం ప్రామాణీకరణ ఫ్రేమ్వర్క్ ద్వారా చర్చించబడుతుంది, IKEv2లో ఇవి రెండు వేర్వేరు నిర్ణయాలు.
ఆ నిర్ణయాలు మునుపు పెనవేసుకుపోయినందునే RFC 7427 ఉంది, సంతకం అల్గోరిథంలు కీ మార్పిడికి స్వతంత్రంగా ఎలా ప్రకటించబడతాయో, ఎంపిక చేయబడతాయో అది నిర్వచిస్తుంది. ఒక గేట్వే వక్ర సమూహాన్ని మరియు సంతకం పథకాల ఎంపికను ఒకేసారి మద్దతు ఇవ్వగలదు.
కాబట్టి సమూహ మార్పు తర్వాత చర్చ విఫలమైతే, సర్టిఫికెట్ కీ రకాన్ని చూసే ముందు ప్రామాణీకరణ పద్ధతిని చూడండి. సర్టిఫికెట్ మార్చడం నెమ్మదైన, ప్రమాదకరమైన చర్య, అది అరుదుగానే సమాధానం, దానిని మొదట చేయడం ఏ మార్పు నిజంగా సహాయపడిందో తెలుసుకునే సామర్థ్యాన్ని నాశనం చేస్తుంది. సర్టిఫికెట్ నిల్వను తాకే ముందు ప్రామాణీకరణ వరుసను చదవండి.
ఒప్పంద పత్రంలోని వేర్వేరు వరుసల్లో రెండింటిని ఉంచండి, ఆ తప్పు ఆకర్షణీయంగా ఉండదు. ఒక వరుస సమూహాలను జాబితా చేస్తుంది, మరొకటి సంతకం పథకాలు మరియు గుర్తింపులను జాబితా చేస్తుంది, ఏదీ మరొకదానికి సాక్ష్యం కాదు.
ప్రతి ప్రైవేట్ కీని దాని నిజమైన యజమాని వద్ద ఉంచండి
తన సర్టిఫికెట్ను ప్రదర్శించే గేట్వేకు దానికి సరిపోలే ప్రైవేట్ కీ అవసరం. గొలుసును ధృవీకరించే సహచరుడికి CA సర్టిఫికెట్ అవసరం, దానికి CA సంతకం కీ అవసరం లేదు. ఆ మూడు వస్తువులను కలిపేయడమే, ఒక సర్టిఫికెట్ వేరే వర్గంలో కనిపించాలని CA ప్రైవేట్ కీని VPN పరికరంలోకి దిగుమతి చేసుకునే పరిస్థితికి దారి తీస్తుంది.
FortiOSలో పాత్రలు వేరు: దాని కీతో కూడిన local సర్టిఫికెట్, సహచరుడిని గుర్తించడానికి ఉపయోగించే remote సర్టిఫికెట్, ఆ CA సంతకం చేసిన సర్టిఫికెట్లపై నమ్మకాన్ని ఏర్పాటు చేసే remote CA నమోదు. ప్రైవేట్ కీ లేని remote CA నమోదు అసంపూర్ణం కాదు; అది తన ఉద్దేశానికి సరైనది.
దిగుమతి చేసిన CA సంతకం కీలు ఆ పరికరాన్ని చదవగల ఎవరి అధికారాన్ని అయినా విస్తరిస్తాయి. అవి సాధారణ సహచర ధృవీకరణను కూడా పరిష్కరించవు, ఎందుకంటే ధృవీకరణకు పబ్లిక్ సర్టిఫికెట్ మరియు నమ్మక నిర్ణయం అవసరం, కొత్త సర్టిఫికెట్లను సృష్టించే సామర్థ్యం కాదు.
CA సంతకం కీని జారీ చేసేవారి సొంత ప్రక్రియలో ఉంచండి, ఏ పరికరం ఏ కీని కలిగి ఉందో నమోదు చేయండి. ఆడిట్ ఎవరు ఎవరిగా నటించగలరని అడిగినప్పుడు యజమానుల చిన్న పట్టిక అల్గోరిథమ్ల పొడవైన పట్టిక కంటే విలువైనది. ఇది కేవలం జాబితా అని తెలిసిన కీని ఎవరూ దిగుమతి చేయరు. జాబితాను సంఘటనకు ముందు రాయండి, తర్వాత కాదు.