Azure VPN NAT ஒன்றுடன் ஒன்று மேற்பொருந்தும் VNet முகவரிகளை சரிசெய்யாது
ஒரே தனியார் வரம்பைக் கொண்ட இரண்டு VNet NAT இருப்பதால் மட்டும் இணைக்கப்படாது. முதலில் இணைப்பு வகையைப் பார்க்கவும், பின்னர் மீண்டும் எண்ணிடவும் அல்லது மொழிபெயர்ப்பு மாற்றுப்பெயரை வைத்திருங்கள்.
இரண்டு VNet-களும் 10.40.1.0/24 பயன்படுத்துகின்றன, சுரங்கங்கள் மேலெழுகின்றன, ஆனால் எதுவும் இயங்கவில்லை. இரண்டாவது VPN நுழைவாயிலைச் சேர்த்தாலும் அது மாறாது, குறைந்த வழி அளவீட்டாலும் மாறாது, ஏனெனில் சிக்கல் பாதை தேர்வில் இல்லை. ஒரே தனியார் முகவரிக்கு பதிலளிக்கும் இரண்டு பணிச்சுமைகள் ஒவ்வொரு பொதியையும் தெளிவற்ற இலக்கு மற்றும் சரிபார்க்க முடியாத திரும்பும் பாதையுடன் விட்டுவிடுகின்றன. எந்த மொழிபெயர்ப்பையும் திட்டமிடும் முன் நீங்கள் உண்மையில் எந்த இணைப்பு வகையை உருவாக்கினீர்கள் என்பதைக் கண்டறியுங்கள், ஏனெனில் அந்த ஒரு தேர்வே Azure-இன் NAT வசதி அடிப்படையில் கிடைக்குமா என்பதைத் தீர்மானிக்கிறது.
இந்த அறிகுறி உண்மையில் உங்களுக்குச் சொல்வது என்ன
VNet A-வில் உள்ள புரவலன் 10.40.1.10-க்கு அனுப்பும்போது, வழிசெலுத்தல் அட்டவணை அதை எங்காவது மட்டுமே சுட்ட முடியும். VNet B-யிலும் 10.40.1.10 இருந்தால், அந்த முகவரி பாதை வேறுபடுத்தக்கூடிய இலக்கு அல்ல; அது இரண்டு உரிமையாளர்களைக் கொண்ட ஒரு முகவரி.
மக்கள் வழக்கமாகப் பயன்படுத்தும் இரண்டாவது நுழைவாயில் உதவாது. அது மற்றொரு சுரங்கத்தைத் தருகிறது, மற்றொரு முகவரியை அல்ல, நகலெடுக்கப்பட்ட வரம்பு சுரங்கத்தின் உள்ளே மாற்றமின்றி பயணிக்கிறது. நீங்கள் சீரானதாக வைத்திருக்க வேண்டிய கட்டமைப்பையும் அது இரட்டிப்பாக்குகிறது. அது செய்ய முடியாதது ஒரு முகவரி இரண்டு புரவலர்களைக் குறிக்கச் செய்வதுதான்.
VPN சகாக்களின் பொது முகவரிகளை மாற்றுவதும் எதையும் செய்யாது. அந்த முகவரிகள் சுரங்கத்தின் முனைகளை அடையாளம் காட்டுகின்றன, ஆனால் மோதல் அதற்குள் எடுத்துச் செல்லப்படும் தனியார் வரம்பில் உள்ளது.
NAT கிடைக்குமா என்பதை இணைப்பு வகை தீர்மானிக்கிறது
Azure VPN Gateway-க்கு உண்மையில் NAT திறன் உள்ளது, மேலும் குறிப்பிட்ட நுழைவாயில் SKU-களில் பாதை அடிப்படையிலான IPsec இடைத்தள இணைப்புகளுக்கு அது ஆவணப்படுத்தப்பட்டுள்ளது. அதே ஆவணம் VNet-to-VNet மற்றும் point-to-site இணைப்புகளை விலக்குகிறது, எனவே இந்த வசதி ஒவ்வொரு நுழைவாயில் உறவிலும் தோன்றும் ஒரு சரிபார்ப்புப் பெட்டி அல்ல.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
இயல்பான VNet-to-VNet-க்கும் தொடக்கத்திலிருந்தே VNet மற்றும் உள்ளூர் பிணைய வரம்புகள் மேற்பொருந்தாமல் இருக்க வேண்டும், இது இந்த விலக்குடன் ஒத்துப்போகிறது. அதே காரணத்தால் VNet இணைப்பும் மேற்பொருந்துதலுக்கான தீர்வு அல்ல.
மக்கள் இயல்பான வகையுடன் குழப்பிக்கொள்ளும் ஆதரவு பெற்ற மாற்று ஒன்று உள்ளது: மற்ற VNet-ஐ உள்ளூர் பிணையமாக மாதிரியாக்கி, அதை தளத்திலிருந்து-தளம் இணைப்பாக இணைக்கவும். அது வேறு வளமும் வேறு வடிவமைப்பும், எனவே பெயர் மாற்றப்பட்ட இணைப்பை வெறும் பெயர் மாற்றமாக அல்ல, சரிபார்க்க வேண்டிய மாற்றமாகக் கருதுங்கள்.
மீண்டும் எண்ணிடுங்கள், அல்லது மாற்றுப்பெயரை வைத்திருக்கும் ஒன்றால் மொழிபெயர்க்கவும்
இரண்டு VNet-களும் உங்களுடையதாக இருந்தால், திட்டமிடப்பட்ட மறு எண்ணிடலை மொழிபெயர்ப்பின் தொடர் செலவுடன் ஒப்பிடுங்கள். மறு எண்ணிடல் பயன்பாட்டு கட்டமைப்பு, DNS பதிவுகள், பாதுகாப்பு விதிகள் மற்றும் இருக்கும் ஒவ்வொரு இணைப்பையும் தொடுகிறது, ஆனால் பின்னர் சாதாரணமாகப் படிக்கக்கூடிய பிணையத்தை விட்டுச் செல்கிறது. ஒரு நேரத்தில் ஒரு துணைப்பிணையமாகச் செய்யுங்கள், DNS மாற்றம் இறுதியில். பாதி மறு எண்ணிடப்பட்ட வரம்பு எந்த விருப்பத்தையும் விட மோசமானது, ஏனெனில் அப்போது இரண்டு முன்னொட்டுகளும் அடுத்த முறை அட்டவணையைப் படிப்பவருக்கு அதிகாரப்பூர்வமாகத் தெரிகின்றன.
மறு எண்ணிடல் நடைமுறையில் இல்லாத இடத்தில், மாற்றுப்பெயருக்கு உண்மையான உரிமையாளரைக் கொண்ட மொழிபெயர்க்கப்பட்ட வடிவமைப்பைப் பயன்படுத்துங்கள். VNet A-வில் உள்ள அழைப்பாளர்கள் VNet B-யின் 10.40.1.10-ஐ 10.140.1.10 ஆக அடையலாம், ஆனால் அந்த மாற்றுப்பெயருக்கு மொழிபெயர்க்கும் சாதனம், அதை நோக்கிய பாதை மற்றும் பதிலுக்கு பொருந்தும் நடத்தை தேவை. DNS-இல் மட்டும் சேர்க்கப்பட்ட முகவரி மொழிபெயர்ப்பு அல்ல.
இரண்டு வரம்புகளையும் இரு திசைகளிலும் பதிவு செய்யுங்கள்: அழைப்பாளர் எதை அழைக்கிறார், இலக்கு மூலமாக எதைப் பார்க்கிறது, எந்தப் பக்கம் தொடங்கலாம். Azure-இன் சொந்த NAT விதிகள் அவற்றின் SNAT வரைபடங்களுக்கு தலைகீழ் மொழிபெயர்ப்பை உள்ளடக்குகின்றன, எனவே பொருந்தும் DNAT விதியை கையால் எழுதுவதில்லை, ஆனால் அந்த வசதி இந்த அம்சம் ஆதரிக்கும் இணைப்பு வகைகளில் முடிகிறது.
எது வேலை செய்யாது
பயனர் வரையறுத்த வழி அல்லது வழி அளவீடு காணாமல் போன முகவரி வேறுபாட்டை உருவாக்க முடியாது. இரண்டும் இன்னும் தெளிவற்ற இலக்கில் செயல்படுகின்றன, பொதி அட்டவணை விரும்பும் அடுத்த தாவலுக்கு வந்து சேர்கிறது.
நகலெடுக்கப்பட்ட வரம்பை மிகவும் குறிப்பிட்ட முன்னொட்டாக வழி அட்டவணையில் சேர்ப்பது தெளிவின்மையை ஒரு படி மட்டுமே நகர்த்துகிறது. இது எதிர் திசையையும் உடைக்கும் போக்கைக் கொண்டுள்ளது, அங்கு பதிலுக்கு இப்போது இரண்டு நம்பகமான மூலங்கள் உள்ளன.
இரு திசைகளிலும் போக்குவரத்துடன் வடிவமைப்பை ஏற்றுக்கொள்ளுங்கள்
சுரங்க நிலையால் அல்ல, ஒவ்வொரு பக்கத்திலிருந்தும் புதிய அனுமதிக்கப்பட்ட செயல்பாட்டால் வடிவமைப்பை நிரூபியுங்கள். இணைக்கப்பட்ட IPsec சுரங்கம் சகாக்கள் மறையாக்கத்தில் உடன்படுகிறார்கள் என்று சொல்கிறது; இலக்குகள் வேறுபடுத்தக்கூடியதாக மாறினவா என்பதைப் பற்றி எதுவும் சொல்லவில்லை.
பின்னர் மறுக்கப்பட்ட பாதைகளை இயக்குங்கள்: அணுக முடியாததாக இருக்க வேண்டிய முகவரி, மற்றும் கொள்கை தடுக்க வேண்டிய சேவை. இரண்டும் இன்னும் வெற்றி பெற்றால், மொழிபெயர்ப்பு வடிவமைப்பின் நோக்கத்தை விட விரிவானது.
பின்னர் இந்த அமைப்பை விளக்கும் உண்மைகளுடன் முடிக்கவும்: அசல் வரம்பு, வழங்கப்பட்ட வரம்பு, மொழிபெயர்க்கும் சாதனம், மற்றும் ஒவ்வொரு பக்கமும் தொடங்கக்கூடிய திசை. இவற்றில் ஏதேனும் இல்லை என்றால், அடுத்த பொறியாளர் இரண்டு புரவலர்கள் ஒரே பெயரைப் பகிர்ந்து கொள்ளும், அவற்றில் ஒன்று ஏன் பதிலளிக்கிறது என்று யாருக்கும் நினைவில் இல்லாத பிணையத்தை மரபாகப் பெறுவார்.