ExpressRoute தனிப்பட்ட peering வழியாக போக்குவரத்தை மறையாக்க நெட்வொர்க் மெய்நிகர் சாதனம் தேவை என்று கூறுவது ஒரு கட்டுக்கதை. அது தேவையில்லை. Azure, சுரங்கப்பாதையின் முனை சுற்று வழியாக எடுத்துச் செல்லப்படும் தனிப்பட்ட RFC1918 முகவரியாக இருக்கும் Site-to-Site VPN Gateway ஐ ஆதரிக்கிறது, மேலும் சாதனம் கட்டமைப்பு அல்ல, விருப்பமானது. சாதனக் கதை மறைப்பது உண்மையில் வலிக்கும் பகுதி: தனிப்பட்ட முனையை இரண்டு பொருட்களுக்குப் பதிலாக ஒன்றில் இயக்குவது, மற்றும் நேரடி peering வழி மறையாக்கப்பட்ட பாதையை அமைதியாக வெல்ல அனுமதிப்பது.

கதை எங்கிருந்து வந்தது

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

இவற்றில் எதுவும் NVA வை ஓய்வுபெறச் செய்யாது. சாதனமே தேவைக்கான ஒரே வழி என்ற அனுமானத்தை ஓய்வுபெறச் செய்கிறது.

இரண்டு நிலைகளிலும் தனிப்பட்ட முனையை இயக்கவும்

VPN நுழைவாயில் உள்ள VNet உடன் இணைக்கப்பட்ட செயல்படும் ExpressRoute தனிப்பட்ட peering இணைப்பில் தொடங்கவும். சுரங்கப்பாதை அந்த முகவரிகளைப் போக்குவரத்தாகப் பயன்படுத்துவதால், உள்ளூர் பக்கம் ஏற்கனவே அந்தச் சுற்று வழியாக தொடர்புடைய தனிப்பட்ட முகவரிகளை அடைந்திருக்க வேண்டும். பின்னர் நுழைவாயிலின் முன்நிபந்தனை: தனிப்பட்ட-IP VPN க்கான Microsoft நடைமுறைக்கு Standard பொது IP வளத்தின் மீது கட்டப்பட்ட நுழைவாயில் தேவை. தனிப்பட்ட சுரங்கப்பாதை முகவரியிடல் அந்த நிபந்தனையை நீக்காது, இது „தனிப்பட்ட“ என்றால் „எங்கும் பொது IP இல்லை“ என்று கருதுபவர்களை வியக்க வைக்கிறது.

இப்போது இரண்டு இடங்களிலும் கொடியை இயக்கவும். நுழைவாயில் கட்டமைப்புக்கு தனிப்பட்ட IP களுக்கான சொந்த சுவிட்ச் உள்ளது, தனி Site-to-Site இணைப்புக்கு அந்த இணைப்பை தனிப்பட்ட முகவரியைப் பயன்படுத்த வைக்கும் இரண்டாவது உள்ளது. ஒன்றை அமைத்து மற்றொன்றை அமைக்காதது மிகவும் பொதுவான முழுமையற்ற கட்டமைப்பாகும்; சுரங்கப்பாதை ஒன்று நிறுவப்படாது அல்லது தவறான முனையில் நிறுவப்படும்.

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

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

இரண்டாவது கதை: நிறுவப்பட்ட சுரங்கப்பாதை உங்கள் போக்குவரத்தை மறையாக்குகிறது

இப்போது பயன்பாட்டு நெட்வொர்க்கை இரண்டு பாதைகள் அடைகின்றன: நேரடி தனிப்பட்ட peering பாதை மற்றும் VPN வழியாக பாதை. இரண்டும் வேலை செய்கின்றன. இந்த IPsec அடுக்கைப் பயன்படுத்துவது ஒன்று மட்டுமே. ஒரே முன்னொட்டுகள் ExpressRoute மற்றும் VPN இரண்டிலும் அறிவிக்கப்படும்போது Azure நேரடி ExpressRoute பாதைக்கு முன்னுரிமை அளிக்கிறது என்று Microsoft ஆவணப்படுத்துகிறது, எனவே ஆரோக்கியமான சுரங்கப்பாதையும் ஆரோக்கியமான கவுண்டர்களும் பயன்பாட்டுப் பொதிகளை எங்கு சென்றன என்பதை எதுவும் நிரூபிக்காது.

ஆவணப்படுத்தப்பட்ட திசைவிப்பு முறைகள் ExpressRoute இல் மூடும் வரம்பு மற்றும் VPN இல் மிகவும் குறிப்பிட்ட பாதுகாக்கப்பட்ட வரம்பு, அல்லது இரண்டு பாதைகளில் பிரிந்த முன்னொட்டுகள் ஆகும். உதாரணமாக, தனிப்பட்ட peering 10.40.0.0/16 ஐ எடுத்துச் செல்லலாம், VPN 10.40.12.0/24 ஐ அறிவிக்கிறது. மிகவும் குறிப்பிட்ட முன்னொட்டு வெல்லும், மீதமுள்ள வரம்பு நேரடியாகவே இருக்கும்.

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

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

சுரங்கப்பாதை விழும்போது என்ன நடக்கும் என்பதை முடிவு செய்யுங்கள்

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

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

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

தொடர்புடைய கட்டுரைகள்