VPN ప్రారంభమైన తర్వాత Azure VM IMDS లేదా WireServer చేరుకోలేదు

VM నడుస్తోంది, VPN క్లయింట్ కనెక్ట్ అయిందని చెబుతోంది, కొన్ని నిమిషాల తర్వాత Azure ఏజెంట్ అనారోగ్య స్థితిని నివేదించడం ప్రారంభిస్తుంది. కొన్నిసార్లు SSH నిలిచి ఉంటుంది కానీ పోర్టల్ Run Command ఉండదు, ఇది ప్రజలను రూట్ టేబుల్ కాకుండా ఏజెంట్ వైపు చూసేలా చేస్తుంది. టన్నెల్ పైకి వచ్చినప్పుడు అతిథి యొక్క స్వంత ఫార్వార్డింగ్ నిర్ణయాలు మారాయి, సాధారణంగా రెండు ప్లాట్ఫారమ్ చిరునామాలు మొదటి బాధితులు. నేను దీన్ని ఏజెంట్ వైఫల్యంగా పరిగణించే ముందు రూటింగ్ లక్షణంగా పరిగణిస్తాను.

లక్షణం విరిగిన ఏజెంట్‌లా కనిపిస్తుంది

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

పనిచేసే క్రమం: మొదట విఫలమైన కాల్ నిజంగా ఏ చిరునామాను లక్ష్యంగా చేసుకుందో నిర్ధారించండి, తర్వాత అతిథి దాన్ని ఎలా పరిష్కరిస్తుందో చదవండి. మిగతావన్నీ అదనపు దశలతో ఊహ మరియు పొడవైన మార్పు విండో.

168.63.129.16 పబ్లిక్ గమ్యం కాదు

168.63.129.16 అనేది Azure యొక్క ప్రత్యేక వర్చువల్ ప్లాట్ఫారమ్ చిరునామా, దాని ఒక పాత్ర WireServer, దాన్ని VM ఏజెంట్ ఫ్యాబ్రిక్‌తో మాట్లాడటానికి ఉపయోగిస్తుంది. TCP పోర్టులు 80 మరియు 32526కి ఏజెంట్ ట్రాఫిక్ అందుబాటులో ఉండాలని Microsoft డాక్యుమెంట్ చేస్తుంది. ఇది సాధారణ ఇంటర్నెట్ హోస్ట్ కాదు, పూర్తి-టన్నెల్ VPN దాన్ని దూరపు నిష్క్రమణకు తీసుకెళ్లకూడదు. అందుకే ఆరోగ్యంగా కనిపించే టన్నెల్ కూడా ఏజెంట్‌ను ఆకలితో ఉంచగలదు.

ప్లాట్ఫారమ్ చిరునామా పత్రం ఈ చిరునామా వినియోగదారు-నిర్వచిత రూట్లకు లోబడదని కూడా చెబుతుంది, ఇది Azure ఫ్యాబ్రిక్ లక్షణం, మీ అతిథి గురించి వాగ్దానం కాదు. స్థానిక ఫైర్‌వాల్ నియమం లేదా VPN క్లయింట్ యొక్క స్వంత రూటింగ్ విధానం ఇంకా మార్గాన్ని విచ్ఛిన్నం చేయగలవు, వాటిలో ఏదీ VNet రూట్ టేబుల్‌లో నివసించదు.

సమస్యను నివేదిస్తున్నది ఏజెంట్ అయితే, ఏదైనా మళ్లీ ఇన్‌స్టాల్ చేసే ముందు సేవ స్థితి మరియు ఆ చిరునామాకు మార్గాన్ని తనిఖీ చేయండి.

169.254.169.254కి దాని స్వంత నియమాలు ఉన్నాయి

169.254.169.254 అనేది Azure Instance Metadata Service యొక్క link-local చిరునామా. దానికి వచ్చే అభ్యర్థనలకు వాటి స్వంత షరతులు ఉన్నాయి: ప్రాథమిక NIC మరియు ప్రాథమిక IP, చిరునామాకు మద్దతు ఇచ్చే DHCP కాన్ఫిగరేషన్, మరియు ఏదైనా HTTP ప్రాక్సీని దాటవేయడం. వాటిని దూరపు VPN నిష్క్రమణ లేదా ఏకపక్ష ఇంటర్నెట్ గేట్‌వే ద్వారా పంపడం Microsoft వివరించే యాక్సెస్ మోడల్ కాదు.

ఆ ప్రాక్సీ నిబంధన మార్గాన్ని సరిచేసి ఇంకా వైఫల్యాలు చూస్తున్నవారిని పట్టుకుంటుంది. అతిథి HTTP ప్రాక్సీ IMDSని విచ్ఛిన్నం చేయగలదు, అయితే ip route get మీరు ఆశించిన ఇంటర్‌ఫేస్‌ను ఖచ్చితంగా తిరిగి ఇస్తుంది, కాబట్టి మార్గాలతో పాటు ప్రాక్సీ మినహాయింపులను కూడా తనిఖీ చేయండి.

దీన్ని డీబగ్ చేస్తున్నప్పుడు మెటాడేటా ప్రతిస్పందనలను సపోర్ట్ టికెట్‌లో అతికించవద్దు. అవి సంఘటన కంటే ఎక్కువ కాలం నిలిచే ఆధారాలు మరియు ఇన్‌స్టాన్స్ వివరాలను కలిగి ఉండవచ్చు.

అతిథి యొక్క విధాన రూటింగ్ చదవండి, ప్రధాన పట్టిక మాత్రమే కాదు

Linux అతిథిలో, మూడు చదవడం-మాత్రమే ఆదేశాలు పొరలను వేరు చేస్తాయి: విధాన నియమాలకు ip -4 rule show, తర్వాత కెర్నల్ నిజంగా తీసుకునే నిర్ణయాలకు ip -4 route get 168.63.129.16 మరియు ip -4 route get 169.254.169.254. VPN కనెక్ట్ కావడానికి ముందు మరియు తర్వాత వాటిని అమలు చేయండి. ఆ రెండు అవుట్‌పుట్‌ల మధ్య వ్యత్యాసం మీ మార్పు-సమితి, క్లయింట్ ఏమి చేసిందనే దానిపై ఏదైనా ఊహ కంటే ఇది ఉపయోగకరం.

విధాన నియమాలను ఇన్‌స్టాల్ చేసే VPN క్లయింట్ ప్రధాన పట్టికను తాకకుండా ఆ శోధనలను మళ్లించగలదు. అందుకే ప్రధాన పట్టికను మాత్రమే సరిచేసే పరిష్కారం ఒక హోస్ట్‌లో పనిచేసినట్లు కనిపించి తదుపరి దానిలో ఏమీ చేయదు. బహుళ NICలు ఉన్న అతిథులు అదే సమస్యను మరొక వైపు నుండి జోడిస్తాయి, ఎందుకంటే సమాధానం నియమం ఏ NIC మరియు మూల చిరునామాను ఎంచుకుంటుందనే దానిపై ఆధారపడి ఉంటుంది.

పాత గేట్‌వే ద్వారా రెండు /32 మార్గాలను జోడించే వంటకాన్ని ఎదిరించండి. link-local ప్లాట్ఫారమ్ మార్గం మరియు సాధారణ WAN తదుపరి హాప్ వేర్వేరు వస్తువులు, మరియు సర్వవ్యాప్త మినహాయింపు నిజమైన విధాన ఘర్షణను దాచుతుంది.

నిర్వహణ మరియు పునరుద్ధరణను వేరుగా ఉంచండి

మీ SSH లేదా RDP ప్రతిస్పందన కూడా పూర్తి-టన్నెల్ డిఫాల్ట్ ద్వారా పట్టుబడవచ్చు, కానీ అది ప్లాట్ఫారమ్ ఎండ్‌పాయింట్ కాకుండా నిర్వాహకుడి గమనించిన చిరునామాను లక్ష్యంగా చేసుకుంటుంది. దాన్ని దాని స్వంత అభ్యర్థన-ప్రతిస్పందన జత నుండి నిర్ధారించండి, మరియు VPN విధానాన్ని మార్చే ముందు సీరియల్ కన్సోల్ వంటి స్వతంత్ర పునరుద్ధరణ ఛానెల్‌ను ఉంచండి. ఒక డిప్లాయ్‌మెంట్ VMని పునఃప్రారంభించి ఏజెంట్ అనారోగ్యాన్ని నివేదిస్తే, మార్గ మార్పే రీబూట్‌కు కారణమని భావించకుండా నమోదైన చర్య మరియు బాధ్యతాయుత సేవను పరిశీలించండి.

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

ఆమోదించిన మినహాయింపును అతిథి నెట్‌వర్క్ మరియు VPN కాన్ఫిగరేషన్ యజమాని పేరిట రాయండి, తిరిగి కనెక్ట్ అయ్యేటప్పుడు మరియు పునఃప్రారంభించేటప్పుడు ఏమి జరుగుతుందో కూడా చేర్చండి. Azure UDRలు అతిథి యొక్క రూట్ టేబుల్ కావు, వాటిని సవరించడం స్థానిక విధాన నియమాన్ని సరిచేయదు.