Google Cloud HA VPN నుండి వచ్చే AUTHENTICATION_FAILED సాధారణంగా వ్యక్తులను ముందుగా పంచుకున్న కీ వైపు తిరిగి పంపుతుంది, కీ సాధారణంగా సరిగ్గా ఉంటుంది. టన్నెల్ 1 దశలో ఆగిపోతుంది ఎందుకంటే Google మరొక విషయాన్ని కూడా పోలుస్తుంది: IKE మార్పిడి సమయంలో భాగస్వామి ప్రకటించే గుర్తింపు. FortiGateలో ఎవరూ చిరునామా సవరించకుండానే ఆ గుర్తింపు రకం మారవచ్చు. కీ రెండుసార్లు మళ్లీ నమోదు చేసిన తర్వాత లాగ్ను గుర్తింపు అసమానతగా చదవండి.

ఒక వైఫల్యం, రెండు తనిఖీలు

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

రెండు దశలూ లాగ్లో ఒకే బకెట్లో పడతాయి, ఇది గుర్తింపు పేలోడ్ను ఎవరూ చదవకముందే కీని నాలుగుసార్లు మళ్లీ టైప్ చేసే పరిచిత చక్రాన్ని వివరిస్తుంది.

FortiGate గుర్తింపు పేలోడ్లో ఏమి పెడుతుంది

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

IKE డీబగ్గింగ్ ఆన్ చేసి దీన్ని ఒకసారి పునరుత్పత్తి చేయండి మరియు ఫైర్వాల్ నిజంగా పంపే గుర్తింపు పేలోడ్ను చదవండి.

అదే దశలో మూడు చవకైన వాస్తవాలను నిర్ధారించండి: రెండు చివరలు ఉపయోగించే IKE వెర్షన్, కనిపించని చివరి అక్షరాలతో సహా ఖచ్చితమైన కీ, మరియు Google ఆశించే భాగస్వామి చిరునామా. అవి వేర్వేరు ప్రశ్నలకు సమాధానమిస్తాయి, సరిపోలే కీ గుర్తింపు గురించి ఏమీ చెప్పదు.

ఎంపికలు, మరియు ప్రతిదాని ఖర్చు

ప్రతి నిష్క్రమణ వేరే పొరను సరిచేస్తుంది, ఏదీ ప్రతి అమరికకు అందుబాటులో లేదు.

OptionWhen it worksWhat it costs
Set an address identity on the firewallYour firmware lets you choose the typeBehaviour you must retest per release
Put a public address on the negotiating interfaceThe firewall can hold a routable addressNot possible behind NAT
Terminate on a peer that accepts your identityAnother endpoint validates what you produceA topology change

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

చర్చా ఇంటర్ఫేస్లో రూట్ చేయగల పబ్లిక్ చిరునామా డాక్యుమెంట్ చేయబడిన పరిష్కారం, ఎందుకంటే అప్పుడు డిఫాల్ట్ గుర్తింపు Google ఆశించే దానితో సరిపోతుంది మరియు ఏ ఓవర్రైడ్ అవసరం లేదు. ఫైర్వాల్ అలాంటి చిరునామాను ఉంచగలిగితే చాలా అమరికలు ఇక్కడే ముగుస్తాయి.

మీరు ఉత్పత్తి చేసేది ధృవీకరించే భాగస్వామిపై ముగించడం టోపాలజీ మార్పు. దాన్ని మృదువైన వివరణ ఉన్న పరిష్కారంగా కాకుండా డిజైన్ నిర్ణయంగా పరిగణించండి.

NAT ఒక ఎంపికను తొలగించినప్పుడు

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

వీటిలో ఏదైనా అర్థం చేసుకునే ముందు, Google వైపు టన్నెల్ స్థితిని మరియు IKE కేవలం దారిలో పడవేయబడటం లేదని నిర్ధారించండి. పడవేసిన ప్యాకెట్ సమయం ముగిసి ఆగిపోతుంది; అది తిరస్కరణను సృష్టించదు.

అది పని చేస్తున్నప్పుడు ఏమి నమోదు చేయాలి

టన్నెల్ చివరిసారి పైకి వచ్చినప్పుడు అమలులో ఉన్న గుర్తింపు రకం, దాని విలువ, ఫర్మ్వేర్ వెర్షన్ మరియు భాగస్వామి చిరునామాను నమోదు చేయండి. ఫర్మ్వేర్ అప్డేట్ డిఫాల్ట్ను మళ్లీ మార్చవచ్చు, తదుపరి వైఫల్యం సరిగ్గా కీ అసమానతలా కనిపిస్తుంది. గుర్తింపు కీ మరియు భాగస్వామి చిరునామా పక్కన నిల్వ ఉంటే, తదుపరి వ్యక్తి చవకైన తనిఖీల నుండి ప్రారంభిస్తాడు.

ఆ నమోదే తదుపరి అప్గ్రేడ్ తర్వాత కూడా పరిష్కారం అవసరమా అని తెలుసుకోవడానికి ఏకైక మార్గం.

సంబంధిత వ్యాసాలు