Azure VM పై RRAS మద్దతు లేదు: డిజైన్ ముందు తనిఖీ చేయండి

మీరు పోర్టల్ తెరిచి, Windows Server 2022 ను సబ్నెట్లో అమర్చి, Remote Access పాత్ర ఇబ్బంది లేకుండా ఇన్స్టాల్ అవుతుంది. ఆ క్రమం ఇన్స్టాలర్ పని చేస్తుందని నిరూపిస్తుంది, Microsoft ఈ కాన్ఫిగరేషన్కు మద్దతు ఇస్తుందని కాదు. Azure వర్చువల్ మెషీన్ల కోసం ప్రచురించిన సర్వర్ సాఫ్ట్వేర్ మద్దతు మార్గదర్శకం RRAS ను Azure VM పై మద్దతు లేని Windows Server ఫీచర్లలో జాబితా చేస్తుంది, ఇది సమస్య పరిష్కార వివరం కాదు, నిర్మాణ నిర్ణయం. పైకి వచ్చే టన్నెల్ అమరికను మద్దతు సరిహద్దు లోపలికి కదిలించదు.

క్రింది మార్గదర్శకం మద్దతు పేజీలో ప్రారంభమై, తర్వాత అవసరాలు మరియు ప్రత్యామ్నాయ ఎంపికల వైపు కదులుతుంది.

ప్రయోగశాలలో కాదు, మద్దతు పేజీ నుండి ప్రారంభించండి

ఏదైనా కొలవడానికి ముందు Azure VM మద్దతు మార్గదర్శకాన్ని చదవండి. ఇది Windows Server ను ఒక విభజించని బ్లాక్గా పరిగణించడం బదులు మద్దతు ఉన్న ఉత్పత్తులు, పాత్రలు మరియు ఫీచర్లను వేరు చేస్తుంది. మీ ఉద్దేశిత పనిభారం నిజంగా ఏ వరుసలో వస్తుందో గమనించండి, ఎందుకంటే కన్సోల్లో సంబంధితంగా కనిపించే రెండు భాగాలు వేర్వేరు వరుసల్లో ఉండవచ్చు.

పేజీ తెరిచి ఉన్నప్పుడే డిజైన్ పత్రంలో ఉల్లేఖనం రాయండి. మద్దతు స్థితి మూలం ఉన్న వాస్తవం, దాన్ని ఉల్లేఖించలేని డిజైన్ సమీక్షను డెమో ఉన్న వ్యక్తి వాదంలో ఓడిస్తాడు.

OS మద్దతును పాత్ర మరియు ఫీచర్ మద్దతు నుండి వేరు చేయండి

అదే మార్గదర్శకం Network Policy and Access Services ను మద్దతు ఉన్న పాత్రల్లో జాబితా చేస్తుంది, అదే సమయంలో RRAS ను విడిగా మద్దతు లేనిదిగా జాబితా చేస్తుంది. ఆ రెండు నమోదులు వేర్వేరు విషయాలను వివరిస్తాయి, వాటిని “రిమోట్ యాక్సెస్ మద్దతు ఉంది”గా కలిపి వేయడమే తప్పు చదవడం ఆధారంగా ప్రాజెక్టు ఆమోదించబడే మార్గం. ఆపరేటింగ్ సిస్టమ్ మద్దతు ఉండటం దాని సొంత వరుస ఉన్న ఫీచర్ గురించి ఏమీ చెప్పదు.

పరిమితి కొన్నిసార్లు ఉల్లేఖించే దానికంటే కూడా సన్నగా ఉంటుంది. ఇది Azure VM లోపల నడిచే ఆ ఫీచర్ గురించి; ప్రైవేట్ నెట్వర్క్ Azure కు కనెక్ట్ కాలేదని అర్థం కాదు, RRAS ప్రతిచోటా మద్దతు లేదని కూడా చెప్పదు. ప్యాకెట్లను సరిగ్గా ఫార్వార్డ్ చేసే పాత ప్రయోగశాల ప్యాకెట్ల గురించి సాక్ష్యం, మద్దతు ప్రకటన గురించి కాదు.

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

డిజైన్ నిజంగా ఏమి చేయాలో రాయండి

ప్రత్యామ్నాయాన్ని ఎంచుకునే ముందు సైట్ జాబితాను ఉత్పత్తిని కొలవగల అవసరాలుగా మార్చండి:

• శాఖ పరికరాలు ఇప్పటికే మాట్లాడే టన్నెల్ ప్రోటోకాల్లు, మరియు ఏదైనా సైట్కు డైనమిక్ రౌటింగ్ అవసరమా.
• దూర ప్రిఫిక్స్లు, రౌటింగ్ బదులు అనువాదం అవసరమయ్యే ఏదైనా అతివ్యాప్తి చెందే చిరునామా స్థలంతో సహా.
• Azure తో రూట్ మార్పిడి, మరియు రౌటింగ్ పట్టికలోని ప్రతి నమోదు యజమాని ఎవరు.
• అత్యంత రద్దీ సమయం తట్టుకోవాల్సిన థ్రూపుట్ మరియు కనెక్షన్ల సంఖ్య.
• సైట్ యజమానులు అంగీకరించిన ఫెయిల్ఓవర్ ప్రవర్తన, మీరు నిర్మించగలిగేది మాత్రమే కాదు.

NAT అనేది దాటవేయబడి ఆపై మొత్తం డిజైన్ను నిర్ణయించే అంశం. IPsec ను ఏర్పాటు చేయగల పరికరం ఇప్పటికీ తాను భర్తీ చేస్తున్న RRAS అమరిక కంటే భిన్నంగా చిరునామాలను అనువదించవచ్చు, అది శాఖ ఏ చిరునామాలను మూలంగా చూస్తుంది మరియు మీ లాగ్లు ఏమి నమోదు చేస్తాయో మారుస్తుంది.

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

ఆ అవసరాలకు వ్యతిరేకంగా ప్రత్యామ్నాయాలను అంచనా వేయండి

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

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

అవసరం నిజంగా సరళంగా ఉన్నప్పుడు — ఒక సైట్, ఒక ప్రిఫిక్స్, అతివ్యాప్తి లేదు — నిర్వహిత సేవ సాధారణంగా నిర్వహణ ఖర్చులో గెలుస్తుంది. అనువాదం మరియు డైనమిక్ రౌటింగ్ రెండూ ఆటలో ఉన్నప్పుడు, పరికర మార్గం మాత్రమే సరిపోయేది కావచ్చు, అది మద్దతు లేని VM ను ఉంచుకోవడం బదులు పొడవైన మార్పిడిని ప్లాన్ చేయడానికి కారణం.

RRAS VM ఇప్పటికే నడుస్తుంటే

ఆవిష్కరణ దాన్ని తొలగించడానికి కారణం కాదు. ఆ VM సేకరించిన ఆధారాల చుట్టూ మార్పును ప్లాన్ చేయండి: ఇతర సబ్నెట్లు ఆధారపడే రూట్లు, మూల చిరునామాలను దాచే NAT నియమాలు, మరియు పర్యవేక్షణ దాని చిరునామా నుండి ఆశించడం నేర్చుకున్నవన్నీ. మద్దతు ఉన్న లక్ష్యం పక్కనే డిజైన్ చేయబడి ధృవీకరించబడుతుండగా అవసరమైన రూట్లు మరియు పరీక్షించిన పునరుద్ధరణ మార్గాన్ని కాపాడండి.

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

మద్దతు ఉల్లేఖనం, అవసరాల జాబితా, ఎంచుకున్న ప్రత్యామ్నాయం మరియు మార్పిడి క్రమాన్ని నమోదు చేసి మార్గదర్శకాన్ని ముగించండి. ఆడిటర్ లేదా కొత్త బృంద సభ్యుడు మొదట అడిగేది ఈ నాలుగు అంశాలే.