பீர் செய்யப்பட்ட Azure VNet க்கு அதன் சொந்த VPN கேட்வே தேவையா?

ஒரு புதிய spoke VNet தோன்றுகிறது, hub-இல் ஏற்கனவே செயல்படும் site-to-site கேட்வே உள்ளது, மேலும் வெளிப்படையான கேள்வி என்னவென்றால் இரண்டாவது கேட்வேக்கு நீங்கள் பணம் செலுத்த வேண்டுமா என்பதுதான். பொதுவாக இல்லை: கேட்வே டிரான்சிட் spoke-ஐ peering மூலம் hub-இன் கேட்வேவைப் பயன்படுத்த அனுமதிக்கிறது. இது வேலை செய்யுமா என்பதை மூன்று நிபந்தனைகள் தீர்மானிக்கின்றன, அவற்றில் எதுவும் peering நிலை பேட்ஜில் தெரியவில்லை. peering இணைப்பும் வேறொருவரின் கேட்வேவைப் பயன்படுத்தும் அனுமதியும் தனித்தனி அமைப்புகள், எனவே ஏற்கனவே ஒருவரையொருவர் ping செய்யக்கூடிய இரண்டு VM VPN பாதையைப் பற்றி எதையும் நிரூபிக்கவில்லை.

முதல் நிபந்தனை: கேட்வே, மற்றும் spoke-இல் அது இல்லாதது

Azure, Basic தவிர மற்ற VPN Gateway SKU-களுக்கு கேட்வே டிரான்சிட்டை ஆதரிக்கிறது, மேலும் பிராந்திய மற்றும் உலகளாவிய peering இரண்டும் அதை எடுத்துச் செல்ல முடியும். spoke தனக்குச் சொந்தமில்லாத கேட்வேவைப் பயன்படுத்துகிறது, எனவே அதற்கு சொந்தமான ஒன்று இருக்க முடியாது: spoke-இல் ஏற்கனவே கேட்வே இருந்தால், அல்லது தொலை கேட்வே விருப்பம் ஏற்கனவே தேர்ந்தெடுக்கப்பட்டிருந்தால், நீங்கள் விரும்பும் டிரான்சிட் அமைப்பு கிடைக்காது அல்லது பயனற்றதாக இருக்கும். எதையும் பிழைத்திருத்துவதற்கு முன் இதைச் சரிபார்க்கவும், ஏனெனில் முடக்கப்பட்ட தேர்வுப்பெட்டி அறிகுறி, குறைபாடு அல்ல. முதலில் SKU மற்றும் உள்ள கேட்வேவைப் படித்து, பின்னர் peering அமைப்புகளைப் பார்க்கவும்.

விருப்பம் தோன்றுவதற்காக உள்ள spoke கேட்வேவை அது எதைச் சார்ந்துள்ளது என்று தெரியும் வரை நீக்க வேண்டாம். இடம்பெயர்வு வரிசை தேர்வுப்பெட்டியை விட முக்கியம்.

இரண்டாவது நிபந்தனை: ஒவ்வொரு peering திசையிலும் ஒரு அமைப்பு

peering என்பது இரண்டு பொருட்கள், ஒவ்வொரு VNet-இலும் ஒன்று, மேலும் டிரான்சிட் அமைப்புகள் அந்த இணையின் வெவ்வேறு பக்கங்களில் உள்ளன. hub-இலிருந்து spoke நோக்கிய peering, hub கேட்வே spoke-க்கு சேவை செய்ய அனுமதிக்க வேண்டும்; spoke-இலிருந்து hub நோக்கிய peering, hub-இன் கேட்வேவை ஏற்க வேண்டும். Microsoft-இன் கேட்வே-டிரான்சிட் வழிகாட்டி திசையின்படி அவற்றிற்குப் பெயரிடுகிறது, அவற்றைச் சரியாக வைத்திருக்க இதுவே ஒரே வழி:

remote என லேபிளிடப்பட்ட கட்டுப்பாடு நீங்கள் எந்த VNet-இன் peering-ஐ திருத்துகிறீர்கள் என்பதைப் பொறுத்து பொருளை மாற்றுகிறது, எனவே வார்த்தையல்ல, திசையைப் படியுங்கள். இரு பக்கங்களையும் அமைத்து, சேமித்து, peering இரு இடங்களிலும் இணைக்கப்பட்டதாகத் தெரிவிக்கிறதா என்பதை உறுதிப்படுத்துங்கள்.

மூன்றாவது நிபந்தனை: முகவரி இடைவெளி மற்றும் அனுமதி எல்லைகள்

ஒரே இலக்கு முன்னொட்டு இரண்டு நெட்வொர்க்குகளைக் குறிக்க டிரான்சிட் செய்ய முடியாது, எனவே hub, spoke மற்றும் உள்ளூர் நெட்வொர்க் வரம்புகள் இவற்றில் எதுவும் செயல்படுவதற்கு முன் தனித்தனியாக இருக்க வேண்டும். VNet-கள் வெவ்வேறு சந்தாக்கள் அல்லது வெவ்வேறு குத்தகைதாரர்களில் இருக்கலாம்; அது தடையல்ல, ஆனால் ஒவ்வொரு peering-ஐ உருவாக்கும் அல்லது புதுப்பிக்கும் அடையாளத்திற்கு அந்த நெட்வொர்க்கில் தேவையான அனுமதிகள் இருக்க வேண்டும். சந்தாக்களுக்கு இடையிலான மாற்றங்கள் பெரும்பாலும் அனுமதியில் தோல்வியடைகின்றன, மேலும் பிழையை டோபாலஜி சிக்கலாகத் தவறாகப் படிப்பது எளிது.

மாற்றத்திற்கு முன் வரம்புகளையும் உரிமையாளர்களையும் எழுதுங்கள். இரண்டில் ஏதேனும் ஒன்றை ஊகிப்பது இணைக்கும் ஆனால் எதையும் வழிமாற்றாத peering-ஐ உருவாக்கும்.

peering நிலையால் அல்ல, பயனுள்ள வழிகளால் சரிபார்க்கவும்

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

spoke பணிச்சுமையிலிருந்து ஒரு சேவையைச் சோதித்து பதிலைப் பின்தொடருங்கள். VPN கேட்வே அல்லது hub VM-இலிருந்து சோதனை வேறு மூல முன்னொட்டையும் வேறு பாதையையும் பயன்படுத்துகிறது.

டோபாலஜி point-to-site வாடிக்கையாளர்களுக்கும் சேவை செய்தால், அவர்களின் நிறுவப்பட்ட வழிகளைத் தனித்தனியாகச் சரிபார்க்கவும். டோபாலஜி மாற்றத்திற்குப் பிறகு Windows வாடிக்கையாளர் தொகுப்புகள் மீண்டும் உருவாக்கப்பட வேண்டியிருக்கலாம், மேலும் அது கேட்வே பங்கீடு தோல்வியடைந்ததற்கான ஆதாரம் அல்ல, வாடிக்கையாளர் வழிமாற்றுப் பணி.

கேட்வே பகிர்வு எதை வழங்காது

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

peering கூட மக்கள் நம்புவது போல் கடத்தக்கூடியது அல்ல. மற்றொரு spoke அல்லது தனியார் முனைச் சேர்க்கையைச் சேர்ப்பது தற்போதைய டிரான்சிட் அமைப்பு உள்ளடக்காத அதன் சொந்த வழிமாற்று மற்றும் அணுகல் தேவைகளைக் கொண்டுவருகிறது.