NAT பின்னால் உள்ள பியருடன் Azure தளம்-முதல்-தளம் VPN: சரிபார்ப்பு பட்டியல்

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

படி 1: பியர் உண்மையில் NAT பின்னால் உள்ளதா என்பதை உறுதிப்படுத்துங்கள்

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

இரண்டு முகவரிகளும் பொருந்தினால், இங்கேயே நிறுத்துங்கள்: NAT உங்கள் பிரச்சினை அல்ல, இந்தப் பட்டியலின் மீதி உதவாது.

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

படி 2: யார் தொடங்குவது என்று ஒப்புக்கொள்ளுங்கள்

Azure VPN Gateway அடிக்கடி கேட்கப்படும் கேள்விகள் NAT-T ஆதரவைக் குறிப்பிடுகின்றன, மேலும் ஆன்-பிரிமைஸ் சாதனம் NAT பின்னால் இருக்கும்போது IPsec சுரங்கப்பாதையை அதுவே தொடங்க வேண்டும் என்று சேர்க்கின்றன. இது நிலைமை கொண்ட மொழிபெயர்ப்பு எவ்வாறு செயல்படுகிறது என்பதற்குப் பொருந்துகிறது, ஏனெனில் உட்புற சாதனம் முதல் பொட்டலத்தை அனுப்பியதால் மொழிபெயர்ப்பாளர் மேப்பிங்கை வைத்திருக்கிறது. Azure தொடங்கும் என்று எதிர்பார்க்கப்பட்டு அந்த மேப்பிங்கை உருவாக்க எதுவும் வரவில்லை என்றால், சுரங்கப்பாதை ஒருபோதும் தொடங்காது.

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

கைமுறை தொடக்கத்தின்போது சாதனத்தில் IKE பரிமாற்றத்தைக் கவனியுங்கள்; அங்குள்ள மௌனம் வழிமாற்றம் அல்லது ஃபயர்வால் பதில், Azure பதில் அல்ல.

படி 3: பியர் முகவரியைச் சரியாகப் பெறுங்கள்

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

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

மூன்று மதிப்புகளையும் எழுதுங்கள்: சாதனத்தின் உள்ளூர் முகவரி, மொழிபெயர்க்கப்பட்ட பொது முகவரி, கட்டமைக்கப்பட்ட பியர் அடையாளம்.

படி 4: NAT-Tக்குத் தேவையான துறைகளை மட்டும் திறங்கள்

NAT-T, ESP-ஐ UDPக்குள் எடுத்துச் செல்கிறது, மேலும் RFC 3948 அந்த என்கேப்சுலேஷனை விவரிக்கிறது, இதில் துறை 500 இல் ஆரம்ப பேச்சுவார்த்தைக்குப் பின் துறை 4500 பயன்படுத்தப்படுகிறது. உங்கள் ஃபயர்வாலும் மொழிபெயர்ப்பாளரும் இரண்டுமே பரிமாற்றத்தையும் அதன் திரும்பும் போக்குவரத்தையும் அனுமதிக்க வேண்டும். தொடர்பில்லாத TCP துறையை அனுமதிப்பது இந்தப் பாதையைப் பற்றி எதையும் நிரூபிக்காது, வெளிச்செல்வதை அனுமதித்து பதிலை அனுமதிக்காத விதியும் தோல்வியடையும்.

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

மொழிபெயர்ப்பாளரின் இரு பக்கங்களிலும் ஒருமுறை பிடியுங்கள்; என்கேப்சுலேஷன் வேறுபாடு உடனே தெரியும்.

படி 5: வெளிப்புறப் போக்குவரத்தை உட்புற வழிமாற்றத்திலிருந்து பிரிக்கவும்

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

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

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