Azure S2S VPN కనెక్ట్ అయింది కానీ ట్రాఫిక్ లేదు: IKE లాగ్ చదవండి

పోర్టల్ Connected అని చెబుతుంది, టన్నెల్‌కు పని సమయ కౌంటర్ ఉంది, మరియు మీ వర్చువల్ మెషీన్ నుండి తీసిన trace రెండవ హాప్‌లో మరణిస్తుంది. కనెక్షన్ స్థితి IKE మరియు IPsec చర్చలను వివరిస్తుంది, ఏ వైపు అయినా ఒక ప్యాకెట్ పాలసీ పొరను దాటుతుందా అని కాదు. ఈ టికెట్లలో చాలావాటికి కారణం రెండు లోపాలు, వాటిలో ఒకటి కూడా Azure మార్గాన్ని మార్చడం ద్వారా సరికాదు. రెండూ ఇప్పటికే గేట్‌వే సృష్టించిన లాగ్‌లో రాయబడ్డాయి, అందుకే నేను రూట్ టేబుల్ నుండి కాకుండా అక్కడి నుండి ప్రారంభిస్తాను.

Connected నిజంగా ఏమి ధృవీకరిస్తుంది

కనెక్ట్ అయిన site-to-site కనెక్షన్ అంటే దశ 1 మరియు దశ 2 పూర్తయ్యాయి మరియు భద్రతా సంఘాలు చురుకుగా ఉన్నాయి. ఇది చర్చల గురించిన ప్రకటన: రెండు వైపులా ఒక ప్రతిపాదనపై అంగీకరించి, కీలను మార్పిడి చేసుకుని SA జోడిని ఇన్‌స్టాల్ చేశాయి. మీరు రక్షితమని భావించే సబ్‌నెట్‌లతో ట్రాఫిక్ సెలెక్టర్లు సరిపోతాయా, లేదా డీక్రిప్ట్ చేసిన తర్వాత ఎదుటి వైపు ప్యాకెట్‌ను ఎక్కడికైనా రూట్ చేస్తుందా అనే దాని గురించి ఇది ఏమీ చెప్పదు. టన్నెల్ వారాల పాటు నడుస్తూనే ప్రతి ఆసక్తికరమైన ఫ్లోను పడేయవచ్చు, మరియు ఆరోగ్యకరమైన గేట్‌వేను తిరిగి నిర్మించేలా ప్రజలను పురికొల్పేది అదే నమూనా.

మొదట తనిఖీ చేయవలసిన రెండు లోపాలు ESP బదులు AH ప్రతిపాదించే peer, మరియు గేట్‌వే అంతర్గతంగా పరిగణించని స్థలంలో నంబర్ చేయబడిన వర్చువల్ నెట్‌వర్క్.

రూట్లను తాకే ముందు ఎగుమతి చేసిన లాగ్ తెరవండి

పోర్టల్‌లో వర్చువల్ నెట్‌వర్క్ గేట్‌వే తెరిచి కనెక్షన్‌పై VPN troubleshoot ఆపరేషన్ నడపండి, తర్వాత అది సృష్టించే బండిల్‌ను డౌన్‌లోడ్ చేసి తెరవండి. లోపల దశ 1 మరియు దశ 2 మార్పిడులతో IKE లాగ్ ఉంది, సమయ ముద్రలతో మరియు సాధారణ టెక్స్ట్‌గా చదవగలిగేది. పైనుండి కిందకు చదవడం బదులు అందులో transform లైన్ వెతకండి, ఎందుకంటే ఆసక్తికరమైన ఎంట్రీ సాధారణంగా కొన్ని వందల లైన్ల లోపల ఉంటుంది. పోర్టల్ యాక్సెస్ లేకపోతే, డయాగ్నస్టిక్ సెట్టింగ్‌లు ఆన్‌లో ఉన్నప్పుడు అదే డయాగ్నస్టిక్స్ గేట్‌వే లాగ్ గమ్యస్థానంలో కనిపిస్తాయి.

రెండు ఎంట్రీలు ఎక్కువ విలువను మోస్తాయి. మొదటిది సుమారుగా ఇలా చదవబడుతుంది: expected ESP with combined authentication and cipher, received AH. రెండవది IKE మార్పిడి సమయంలో invalid payload లోపం, దీని అర్థం సాధారణంగా తప్పుగా రూపొందించిన లేదా మద్దతు లేని ప్రతిపాదన ఫీల్డ్.

రెండూ ఆన్-ప్రిమైస్ పరికరం ఏమి ప్రతిపాదించిందో వివరిస్తాయి, కాబట్టి రెండూ peer వైపు సెట్టింగ్‌లు. కనెక్షన్ యొక్క Azure వైపు తిరిగి సృష్టించడం మీ ఫైర్‌వాల్ పంపే ప్రతిపాదనను మార్చదు, అలా చేయడం ఈ పనిలో ఎక్కువగా వృథా అయ్యే గంట. peer‌లో దశ 2ని సంయుక్త ప్రామాణీకరణ మరియు సైఫర్‌తో ESPకి సెట్ చేసి అల్గారిథమ్‌ను చర్చించనివ్వండి, తర్వాత combined mode వంటి పేరుతో ఉన్న విక్రేత చెక్‌బాక్స్ కింద నుండి నిశ్శబ్దంగా AH ప్రతిపాదనను ఎంచుకుంటోందా అని తనిఖీ చేయండి.

వర్చువల్ నెట్‌వర్క్ చిరునామా స్థలాన్ని నిర్ధారించండి

గేట్‌వే వర్చువల్ నెట్‌వర్క్ ప్రైవేట్ పరిధుల్లో ఉండాలని ఆశిస్తుంది. పబ్లిక్ బ్లాక్‌లో నంబర్ చేయబడిన నెట్‌వర్క్, ఉదాహరణకు 111.xతో ప్రారంభమయ్యేది, టన్నెల్‌ను పైకి లేపవచ్చు కానీ Azure ఆ స్థలాన్ని అంతర్గతంగా పరిగణించడానికి నిరాకరిస్తుంది, కాబట్టి కనెక్షన్ ఆరోగ్యకరంగా కనిపిస్తుంది మరియు ఏ ఫ్లో స్వీకరించబడదు. సెలెక్టర్లపై మధ్యాహ్నం వెచ్చించే ముందు చిరునామా స్థలాన్ని నిర్ధారించండి. నంబరింగ్ పాత కేటాయింపు నుండి వచ్చిన కఠిన అవసరం అయితే, పరిష్కారం మరో గేట్‌వే కాదు, చిరునామా ప్రణాళికను మార్చడం.

చిరునామా స్థల బ్లేడ్‌లో ఉన్నప్పుడే ఆన్-ప్రిమైస్ పరిధులతో ఓవర్‌ల్యాప్‌ను నమోదు చేయండి, ఎందుకంటే ఓవర్‌ల్యాప్ అయ్యే ప్రిఫిక్స్‌లు క్లయింట్ నుండి ఒకేలా కనిపించే భిన్నమైన వైఫల్యాన్ని సృష్టిస్తాయి.

రెండు దిశల్లో ప్రిఫిక్స్‌లను ధృవీకరించండి

స్థానిక నెట్‌వర్క్ గేట్‌వే రిసోర్స్ ఆన్-ప్రిమైస్ ప్రిఫిక్స్‌లను కలిగి ఉంటుంది, అవి రిమోట్ పరికరం నిజంగా రక్షించే సబ్‌నెట్‌లతో సరిపోవాలి. పరికరం పడేసే చిరునామాలను కలిగి ఉన్న సారాంశం కొన్ని ఫ్లోలను దాటిస్తుంది మరియు మరికొన్నింటిలో విఫలమవుతుంది, ఇది కాన్ఫిగరేషన్ అసమతుల్యతగా కాకుండా అడపాదడపా వచ్చే రూటింగ్ వైఫల్యంగా చదవబడుతుంది. రిమోట్ వైపు కూడా చూడండి: ఒక చివర /16 జాబితా చేస్తే మరో చివర దానిలో మూడు /24 జాబితా చేస్తుంది — ఇదే సాంప్రదాయిక పాక్షిక వైఫల్యం. ఏ జాబితా ఒంటరిగా అధికారికం కాదు, కాబట్టి మీరు చూడగలిగే దానిపై నమ్మకం పెట్టుకోవడం బదులు రెండింటినీ పక్కపక్కన పోల్చండి.

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

ping కాదు, మార్గాన్ని పరీక్షించండి

పనిచేసే టన్నెల్‌ను పనిచేసే మార్గం నుండి వేరు చేసే trace ఇలా ఉంటుంది: మొదటి హాప్ ఆన్-ప్రిమైస్ గేట్‌వే, తర్వాత స్పందించని కొన్ని హాప్‌లు, తర్వాత రిమోట్ హోస్ట్ సమాధానం ఇస్తుంది. trace ఎప్పటికీ హోస్ట్‌ను చేరుకోకపోతే, అప్లికేషన్ నిజంగా ఉపయోగించే TCP పోర్ట్‌ను పరీక్షించండి, ఎందుకంటే ICMP తగినంత తరచుగా ఫిల్టర్ అవుతుంది, విఫలమైన ping చాలా తక్కువ నిరూపిస్తుంది. అదే traceను రిమోట్ హోస్ట్ నుండి Azureలోని వర్చువల్ మెషీన్ వైపు నడపండి. రెండు ఫలితాల మధ్య అసమమితి తప్పిపోయిన తిరిగి వచ్చే మార్గాన్ని లేదా ఒక దిశకు మాత్రమే అనుమతించే నియమాన్ని కనుగొనడానికి అత్యంత వేగవంతమైన మార్గం.

peer ప్రతిపాదన, రెండు చిరునామా స్థలాలు మరియు కనెక్షన్ సృష్టించిన సమయాన్ని టికెట్‌లో రాయండి, తద్వారా తదుపరి ఇంజనీర్ ఏ విలువలు తిరిగి నిర్మించబడ్డాయో, ఏవి ఎప్పుడూ తాకబడలేదో తెలుసుకోగలరు.

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