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 උමං එකක් කියන්නේ සමස්තකයන් ගුප්තකේතනය ගැන එකඟ වන බවයි; ගමනාන්ත වෙන් කර හඳුනාගත හැකි වූවාද යන්න ගැන එය කිසිවක් නොකියයි.
පසුව ප්‍රතික්ෂේපිත මාර්ග ක්‍රියාත්මක කරන්න: වෙත ළඟා නොවිය යුතු ලිපිනයක්, සහ ප්‍රතිපත්තිය අවහිර කළ යුතු සේවාවක්. දෙකම තවමත් සාර්ථක නම්, පරිවර්තනය නිර්මාණයේ අභිප්‍රායට වඩා පුළුල් ය.
පසුව මෙම සැකසුම පැහැදිලි කරන කරුණු සමඟ අවසන් කරන්න: මූලික පරාසය, ඉදිරිපත් කළ පරාසය, පරිවර්තනය කරන උපාංගය, සහ සෑම පැත්තකටම ආරම්භ කළ හැකි දිශාව. ඒවායින් එකක් හෝ නොමැති නම්, ඊළඟ ඉංජිනේරුවාට සත්කාරක දෙකක් එකම නම බෙදාගන්නා සහ ඒවායින් එකක් පිළිතුරු දෙන්නේ ඇයි කිසිවෙකුට මතක නැති ජාලයක් උරුම වේ.