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 விதிகள், மற்றும் கண்காணிப்பு அதன் முகவரியிலிருந்து எதிர்பார்க்கக் கற்றுக்கொண்ட அனைத்தும். ஆதரிக்கப்படும் இலக்கு அருகில் வடிவமைக்கப்பட்டு சரிபார்க்கப்படும்போது தேவையான வழித்தடங்களையும் சோதிக்கப்பட்ட மீட்புப் பாதையையும் பாதுகாக்கவும்.

ஆதரவுத் திறனையும் தொழில்நுட்பக் கண்டறிதலையும் எல்லா நேரத்திலும் தனித்தனி கண்டுபிடிப்புகளாக வைத்திருங்கள். ஆதரிக்கப்படாத ஏற்பாட்டில் சாதாரண வழிமாற்றுப் பிழையும் இருக்கலாம், அந்தப் பிழையைச் சரிசெய்வது அதன் ஆதரவு நிலையை மாற்றாது. இரண்டு கூற்றுகளும் அறிக்கைக்கு உரியவை, எதுவும் மற்றொன்றை ரத்து செய்யாது.

ஆதரவு மேற்கோள், தேவைகள் பட்டியல், தேர்ந்தெடுக்கப்பட்ட மாற்று மற்றும் மாற்ற வரிசை ஆகியவற்றைப் பதிவு செய்து வழிகாட்டியை முடிக்கவும். தணிக்கையாளர் அல்லது புதிய குழு உறுப்பினர் முதலில் கேட்பது இந்த நான்கு விஷயங்களையே.