Azure സൈറ്റ്-ടു-സൈറ്റ് VPN ട്രാഫിക്കിൽ NSG എവിടെ പ്രയോഗിക്കണം

സൈറ്റ്-ടു-സൈറ്റ് ടണൽ പ്രവർത്തിക്കുന്നു, ഓൺ-പ്രെമൈസ് ക്ലയന്റ് ചില Azure ഹോസ്റ്റുകളിൽ എത്തുന്നു, മറ്റുള്ളവയിൽ എത്തുന്നില്ല, അത് ശരിയാക്കാൻ ആരോ GatewaySubnet-ൽ ഒരു നെറ്റ്വർക്ക് സെക്യൂരിറ്റി ഗ്രൂപ്പ് ചേർത്തു. അവിടെ നിർത്തുക. Azure GatewaySubnet-ൽ NSG പിന്തുണയ്ക്കുന്നില്ല, വർക്ക്ലോഡ് നിയമം എങ്ങനെ കാണുന്നുവോ അതുപോലെ ഗ്രൂപ്പിന് ആന്തരിക പാക്കറ്റ് കാണാൻ കഴിയില്ല. നയം ലക്ഷ്യ സബ്നെറ്റിലോ NIC-ലോ ഇടുക, ഡീക്രിപ്ഷന് ശേഷം നിലനിൽക്കുന്ന ഉറവിട വിലാസം പൊരുത്തപ്പെടുത്തുക, പിന്നീട് പഴയതിനു പകരം പുതിയ കണക്ഷനിൽ പരിശോധിക്കുക.

Azure അതിനെ വിലയിരുത്തുന്നിടത്ത് NSG ഇടുക

വർക്ക്ലോഡ് ഫിൽട്ടറിംഗിനുള്ള പിന്തുണയുള്ള അതിർത്തി ലക്ഷ്യ സബ്നെറ്റോ ലക്ഷ്യ നെറ്റ്വർക്ക് ഇന്റർഫേസോ ആണ്. ഗേറ്റ്‌വേ സബ്നെറ്റ് അടിസ്ഥാന സൗകര്യമാണ്, അവിടെ NSG പിന്തുണയ്ക്കുന്നില്ല എന്നും ഗേറ്റ്‌വേയുടെ പ്രവർത്തനം തകരാറാക്കാമെന്നും Azure രേഖപ്പെടുത്തുന്നു.

വിന്യാസത്തിൽ ഒരു യുക്തിപരമായ പ്രശ്നവുമുണ്ട്. GatewaySubnet-ലെ NSG പുറം IPsec കൈമാറ്റം വിലയിരുത്തും, അതിന്റെ വിലാസങ്ങൾ രണ്ട് ഗേറ്റ്‌വേകൾക്കുള്ളതാണ്. നിങ്ങളുടെ ആപ്ലിക്കേഷൻ നിയമത്തിന് ടണലിനുള്ളിലെ സ്വകാര്യ ഉറവിടം വേണം, ആ പാക്കറ്റ് ഗേറ്റ്‌വേ ഡീക്രിപ്റ്റ് ചെയ്തതിന് ശേഷം മാത്രമേ ഉണ്ടാകൂ. ഗ്രൂപ്പ് വർക്ക്ലോഡ് സബ്നെറ്റിൽ ചേർക്കുക, നിയമം ഉദ്ദേശിച്ച വിലാസം കാണും.

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് നിലവിലെ അസോസിയേഷനുകൾ പരിശോധിക്കുക, എന്താണ് നീക്കുന്നതെന്ന് അറിയാൻ:

az network vnet subnet show -g rg-net -n snet-app --vnet-name vnet-prod --query networkSecurityGroup.id
az network vnet subnet show -g rg-net -n GatewaySubnet --vnet-name vnet-prod --query networkSecurityGroup.id

ഡീക്രിപ്ഷന് ശേഷം ഉറവിട വിലാസം കണ്ടെത്തുക

ആന്തരിക ഉറവിടം ഓൺ-പ്രെമൈസ് ക്ലയന്റിന്റെ സ്വകാര്യ വിലാസമോ, ഒരു ഉപകരണമോ VPN NAT പരിഭാഷയ്ക്ക് ശേഷം അവതരിപ്പിക്കുന്ന വിലാസമോ ആണ്. ഇത് ഓൺ-പ്രെമൈസ് VPN ഗേറ്റ്‌വേയുടെ പൊതു വിലാസമല്ല, അത് പുറം കൈമാറ്റത്തിന്റേതാണ്.

NAT രൂപകൽപ്പനയുടെ ഭാഗമാണെങ്കിൽ, അനുമാനിക്കുന്നതിനു പകരം അവതരിപ്പിച്ച ഉറവിടം സ്ഥിരീകരിക്കുക. Azure VM-ലെ പാക്കറ്റ് ക്യാപ്ചർ, അല്ലെങ്കിൽ സേവനത്തിന്റെ കണക്ഷൻ ലോഗിലെ ഉറവിട ഫീൽഡ്, ഓൺ-പ്രെമൈസ് കോൺഫിഗറേഷൻ വായിക്കുന്നതിനേക്കാൾ വേഗത്തിൽ ചോദ്യം തീർക്കുന്നു. തുടർന്ന് ആ വിലാസത്തിനും യഥാർത്ഥ ലക്ഷ്യ പോർട്ടിനും എതിരെ നിയമം എഴുതുക.

az network nsg rule create -g rg-net --nsg-name nsg-app -n allow-onprem-https --priority 200 --direction Inbound --access Allow --protocol Tcp --source-address-prefixes 192.168.10.0/24 --destination-address-prefixes 10.1.2.0/24 --destination-port-ranges 443

നിങ്ങൾ തുറക്കാൻ ആഗ്രഹിക്കുന്ന ഓരോ സേവനത്തിനും ഒരു നിയമം ഉപയോഗിക്കുക, പോർട്ട് പട്ടിക ചെറുതായി സൂക്ഷിക്കുക. ഓൺ-പ്രെമൈസ് ശ്രേണിയിൽ നിന്നുള്ള എല്ലാ പോർട്ടുകളും അനുവദിക്കുന്ന നിയമം NSG-യെ ഒരു ഔപചാരികതയാക്കി മാറ്റുന്നു.

സ്ഥിരസ്ഥിത VirtualNetwork പരിധി പരിശോധിക്കുക

VirtualNetwork സേവന ടാഗ് പ്രാദേശിക വെർച്വൽ നെറ്റ്വർക്കിനേക്കാൾ വിശാലമാണ്. അതിന്റെ നിർവചനത്തിൽ ബന്ധിപ്പിച്ച ഓൺ-പ്രെമൈസ് വിലാസ ഇടങ്ങൾ, പിയർ ചെയ്ത നെറ്റ്വർക്കുകൾ, ഗേറ്റ്‌വേയിലൂടെ ബന്ധിപ്പിച്ച മറ്റ് പ്രിഫിക്സുകൾ എന്നിവ ഉൾപ്പെടുന്നു. അതായത് VirtualNetwork-ൽ പരിമിതപ്പെടുത്തിയ സ്ഥിരസ്ഥിത അനുമതി നിയമം ഓപ്പറേറ്റർ ബാഹ്യമെന്ന് കരുതിയ ടണൽ ട്രാഫിക്ക് ഇതിനകം അനുമതി നൽകിയേക്കാം.

ഇടുങ്ങിയ നിയമങ്ങൾ ചേർക്കുന്നതിന് മുമ്പ് സ്ഥിരസ്ഥിത നിയമങ്ങൾ വായിക്കുക, ആദ്യം പൊരുത്തപ്പെടാൻ സാധ്യതയുള്ള ഓരോ ഉയർന്ന മുൻഗണനാ നിയമവും വായിക്കുക. വ്യക്തമായ അനുമതി ചേർക്കുന്നത് ഇതിനകം ഫ്ലോ അനുവദിക്കുന്ന വിശാലമായ നിയമം നീക്കം ചെയ്യുന്നില്ല. നയം നിരസിക്കൽ ആവശ്യപ്പെടുന്നിടത്ത്, അനുമതിക്ക് മുമ്പ് യഥാർത്ഥത്തിൽ വിലയിരുത്തപ്പെടുന്ന മുൻഗണനയിൽ അത് ഇടുക.

Microsoft-ന്റെ സേവന ടാഗ് ഡോക്യുമെന്റേഷൻ VirtualNetwork ടാഗ് എന്ത് ഉൾക്കൊള്ളുന്നു എന്ന് പട്ടികപ്പെടുത്തുന്നു, ടാഗ് VNet പരിധി മാത്രം അർത്ഥമാക്കുന്നു എന്ന് ആരെങ്കിലും വാദിക്കുമ്പോൾ ഉദ്ധരിക്കേണ്ട റഫറൻസ് അതാണ്.

രണ്ട് അതിർത്തികളിലും ഫലപ്രദമായ നിയമങ്ങൾ വായിക്കുക

സബ്നെറ്റ് NSG-യും NIC NSG-യും ഒരുമിച്ച് ബാധകമാകുമ്പോൾ, ഫ്ലോ രണ്ടിനെയും തൃപ്തിപ്പെടുത്തണം. ഒന്നിലെ അനുമതി മറ്റൊന്നിലെ നിരസിക്കലിനെ റദ്ദാക്കുന്നില്ല, പാക്കറ്റ് യഥാർത്ഥത്തിൽ നേരിടുന്നത് സംയോജിത കാഴ്ചയെയാണ്.

az network nic show-effective-nsg -g rg-net -n vm-app-nic -o table

Azure Virtual Network Manager-ന്റെ സുരക്ഷാ അഡ്മിൻ നിയമങ്ങൾ പ്രാബല്യത്തിലുണ്ടെങ്കിൽ, ആ പാളിയും പരിശോധിക്കുക. അഡ്മിൻ Always allow നിയമം NSG വിലയിരുത്തലില്ലാതെ ട്രാഫിക് എത്തിക്കാം, അഡ്മിൻ Deny NSG-കൾ കാണുന്നതിന് മുമ്പ് അത് നിർത്തുന്നു. അത്തരം ക്രമീകരണത്തിന് NSG മാത്രം പരിശോധിക്കുന്നത് അപൂർണ്ണമാണ്.

NSG-കൾ സ്റ്റേറ്റ്ഫുൾ ആണെന്ന് ഓർക്കുക. ഒരു നിയമം എഡിറ്റ് ചെയ്യുന്നത് നിലവിലുള്ള അനുവദിച്ച കണക്ഷൻ അവസാനിപ്പിക്കണമെന്നില്ല, അതിനാൽ സ്വീകാര്യതാ പരിശോധനയ്ക്ക് പുതിയ ഫ്ലോ വേണം. ഈ സ്വഭാവം ഉൽപാദനത്തിൽ ഉപകാരപ്രദവും മാറ്റ വിൻഡോയിൽ തെറ്റിദ്ധരിപ്പിക്കുന്നതുമാണ്.

പുതിയ കണക്ഷനിൽ പരിശോധിക്കുക

ഓൺ-പ്രെമൈസ് ക്ലയന്റിൽ നിന്ന് സേവന പോർട്ടിലേക്ക് പുതിയ സെഷൻ തുറക്കുക, തുടർന്ന് നിരസിക്കേണ്ട ഹോസ്റ്റിൽ നിന്ന് ആവർത്തിക്കുക. VM വശത്തുനിന്നും ഫ്ലോ ടെസ്റ്റ് പ്രവർത്തിപ്പിക്കുക, തിരിച്ചുവരവ് പാത കേടുകൂടാതെയുണ്ടെന്ന് അറിയാൻ.

az network watcher test-ip-flow -g rg-net --vm vm-app --direction Inbound --protocol Tcp --local 10.1.2.4:443 --remote 192.168.10.50:51515

NSG അനുമതി ഒരു ആക്സസ് തീരുമാനമാണ്, റൂട്ടല്ല, ലിസണറുമല്ല. നിയമം ഫ്ലോ അനുവദിക്കുകയും കണക്ഷൻ ഇപ്പോഴും പരാജയപ്പെടുകയും ചെയ്താൽ, ഗ്രൂപ്പ് വീണ്ടും എഡിറ്റ് ചെയ്യുന്നതിന് മുമ്പ് VPN-ലേക്കുള്ള ക്ലയന്റ് റൂട്ട്, Azure-ന്റെ തിരിച്ചുവരവ് റൂട്ട്, ഹോസ്റ്റ് ഫയർവാൾ എന്നിവ പരിശോധിക്കുക. യഥാർത്ഥ ഉറവിട വിലാസം, NSG അസോസിയേഷനുകൾ, പൊരുത്തപ്പെടുന്ന നിയമം എന്നിവ അംഗീകൃത സേവനത്തോടൊപ്പം രേഖപ്പെടുത്തുക, അടുത്ത പിയറിംഗ് അല്ലെങ്കിൽ റൂട്ട് മാറ്റം VirtualNetwork ടാഗ് എന്ത് ഉൾക്കൊള്ളുന്നു എന്നത് മാറ്റിയേക്കാം.