NVA ഇല്ലാതെ ExpressRoute-ൽ Azure സ്വകാര്യ IP VPN

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-യെ അതിന്റെ യഥാർത്ഥ സവിശേഷതകൾ അനുസരിച്ച് വിലയിരുത്താനും അനുവദിക്കുന്നു, ഒന്നിലധികം ടണലുകൾ, ത്രൂപുട്ട് അല്ലെങ്കിൽ വെണ്ടർ പരിശോധന പോലുള്ളവ, അന്ത്യ ബിന്ദു സ്വകാര്യമായതിനാൽ ഒന്ന് വാങ്ങുന്നതിന് പകരം.