Azure Point-to-Site VPN లాగ్లు ఎక్కడ ఉన్నాయి? Monitor లో చూడండి

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

స్పష్టమైన శోధన ఎందుకు విఫలమవుతుంది

పాత మార్గదర్శకాలు Azure Point-to-Site VPN కు ఆడిట్ లేదని చెబుతాయి, సేవ ప్రతి కనెక్షన్కు ఏ రికార్డునూ బహిర్గతం చేయనప్పుడు అది నిజం. ప్రస్తుత గేట్వేలు టన్నెల్ డయాగ్నస్టిక్ రికార్డులను ప్రచురిస్తాయి, కాబట్టి ఉపయోగకరమైన ప్రశ్న మారింది: లాగ్లు ఉన్నాయా అని కాదు, ఏ రిసోర్స్ వాటిని విడుదల చేస్తుంది మరియు మీరు ఏ వర్గాన్ని ఆన్ చేశారు. గేట్వే బ్లేడ్ ఒక కాన్ఫిగరేషన్ ఉపరితలం, కాన్ఫిగరేషన్ ఉపరితలాలు లాగ్ వ్యూయర్లుగా కూడా అరుదుగా పనిచేస్తాయి. డయాగ్నస్టిక్ సెట్టింగ్ ప్రతి రిసోర్స్కు ఒక వస్తువు, కాబట్టి మీరు ఎంచుకునే రిసోర్స్ తదుపరి అన్నింటినీ నిర్ణయిస్తుంది.

గందరగోళంలో మిగిలిన సగం ప్రామాణీకరణ. సర్టిఫికెట్ ఆధారిత Point-to-Site కనెక్షన్లు గుర్తింపు ప్రదాత లాగా ప్రతి వినియోగదారుకు సైన్-ఇన్ ఈవెంట్ను సృష్టించవు, కాబట్టి పాస్వర్డ్ టైప్ చేసే పేరు ఉన్న వ్యక్తి రికార్డు ఉండదు.

డయాగ్నస్టిక్ సెట్టింగ్ను గేట్వే రిసోర్స్కు జోడించండి

Monitor తెరవండి, ఆపై Diagnostic settings, మరియు లక్ష్యం దాన్ని కలిగి ఉన్న వర్చువల్ నెట్వర్క్ కాకుండా వర్చువల్ నెట్వర్క్ గేట్వే స్వయంగా ఉండే కొత్త సెట్టింగ్ను జోడించండి. Point-to-Site డయాగ్నస్టిక్ వర్గాన్ని ఎంచుకోండి, P2SDiagnosticLog అనే దాన్ని, ఎందుకంటే ప్రతి క్లయింట్కు కనెక్షన్ రికార్డులను అదే మోస్తుంది; టన్నెల్, రూట్ లేదా IKE వర్గాలను అవి కవర్ చేసే site-to-site లోపాలకు మాత్రమే జోడించండి. తర్వాత డేటాను మీరు నియంత్రించే Log Analytics వర్క్స్పేస్కు పంపండి, మీరు ఉద్దేశపూర్వకంగా ఎంచుకున్న నిల్వ కాలంతో. చాలా విఫలమైన శోధనలు తప్పు రిసోర్స్కు జోడించిన సెట్టింగ్, తప్పిపోయిన ఫీచర్ కాదు.

వర్గ జాబితాలు గేట్వే రకం మరియు తరం ప్రకారం భిన్నంగా ఉంటాయి. Point-to-Site వర్గం లేకపోతే, గేట్వే ఈ ఫీచర్ కంటే పాతది కావచ్చు లేదా దాన్ని ఎప్పుడూ విడుదల చేయని SKU పై నడుస్తుండవచ్చు, కాబట్టి అనుమతి సమస్యను వెతకడానికి ముందు మద్దతు ఉన్న వర్గాలను తనిఖీ చేయండి. Point-to-Site వర్గం లేని గేట్వే పాడైపోలేదు; అది ఆ రికార్డు మూలం కాలేదు, సమీప ప్రత్యామ్నాయం టన్నెల్ లేదా IKE వర్గం, అది Point-to-Site సెషన్ను వివరించకపోయినా క్లయింట్ చిరునామాను నమోదు చేస్తుంది. తప్పిపోయిన లాగ్ల గురించి మద్దతు కేసు తెరవడానికి ముందు వర్గ జాబితాను నిర్ధారించండి.

మీ మోడ్ ఉపయోగించే పట్టికలో రికార్డులను చదవండి

పాత సేకరణ మోడ్లో, నమోదులు AzureDiagnostics పట్టికలోకి వెళ్తాయి మరియు వర్గం నిలువు విలువగా కనిపిస్తుంది; రిసోర్స్-నిర్దిష్ట పట్టికలలో గేట్వేకు దాని సొంత పట్టిక ఉంటుంది. ఏ సందర్భంలోనైనా, గేట్వే రిసోర్స్ మరియు విఫలమైన ప్రయత్నం చుట్టూ ఉన్న సమయ విండో ద్వారా ప్రశ్నించి, తర్వాత వ్యక్తిగత వరుసలకు బదులుగా సహసంబంధాన్ని చదవండి:

AzureDiagnostics
| where ResourceType == "VIRTUALNETWORKGATEWAYS"
| where _ResourceId has "gateway-name"
| where TimeGenerated > ago(2h)
| project TimeGenerated, Category, OperationName, ResultType, ResultDescription
| order by TimeGenerated desc

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

గేట్వే రికార్డును క్లయింట్ యొక్క స్వంత దృక్పథంతో జత చేయండి

గేట్వే లాగ్లు టన్నెల్ను వివరిస్తాయి, ల్యాప్టాప్ ఎందుకు నిర్మించలేకపోయిందో కాదు. అదే టైమ్స్ట్యాంప్లో క్లయింట్ వైపును సేకరించండి: RAS క్లయింట్ కోసం Windows ఈవెంట్ లాగ్, macOS కనెక్షన్ లాగ్, లేదా క్లయింట్ యాప్ చూపిన లోపం వచనం. సరిపోలే క్లయింట్ ప్రయత్నం లేని గేట్వే రికార్డు క్లయింట్ను సూచిస్తుంది; గేట్వే ఏమీ నమోదు చేయనప్పుడు క్లయింట్ విజయాన్ని నివేదిస్తే, సాధారణంగా ప్రొఫైల్ మరొక గేట్వే వైపు మళ్లించబడిందని అర్థం.

రెండు భాగాలను ఒకే టికెట్లో ఉంచండి. గేట్వే లాగ్ మాత్రమే తప్పు నిర్ధారణకు ఆహ్వానిస్తుంది, క్లయింట్ లాగ్ మాత్రమే ప్యాకెట్ ఎప్పుడైనా చేరిందో లేదో చూపలేదు.

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

నిల్వ, పరిధి మరియు runbook నమోదు

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

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