NAT-ന് പിന്നിലുള്ള പിയറുമായി Azure സൈറ്റ്-ടു-സൈറ്റ് VPN: ചെക്ക്ലിസ്റ്റ്

ഈ പരിശോധനകൾ ക്രമത്തിൽ ചെയ്ത് ആദ്യം പരാജയപ്പെടുന്നതിൽ നിർത്തുക. Azure NAT-ന് പിന്നിലുള്ള ഉപകരണത്തെ പിന്തുണയ്ക്കുന്നില്ല എന്ന പരാതികളിൽ ഭൂരിഭാഗവും യഥാർത്ഥത്തിൽ Azure എത്തിപ്പെടാനാകാത്ത പിയർ വിലാസമോ, ശരിയായ വശത്തുനിന്ന് ഒരിക്കലും ആരംഭിക്കാത്ത ടണലോ ആണ്. പുറം ഗതാഗതവും ഉള്ളിലെ റൂട്ടിംഗും രണ്ട് വ്യത്യസ്ത പ്രശ്നങ്ങളാണ്, അവ കൂട്ടിക്കലർത്തുന്നത് ഒരു ഉച്ചയ്ക്കുശേഷം നഷ്ടപ്പെടുത്തുന്നു. താഴെയുള്ള ഓരോ ഘട്ടവും മറ്റൊരാൾക്ക് കൈമാറാവുന്ന ഒരു നിരീക്ഷണം നൽകുന്നു.

ഘട്ടം 1: പിയർ യഥാർത്ഥത്തിൽ NAT-ന് പിന്നിലാണെന്ന് സ്ഥിരീകരിക്കുക

ഉപകരണത്തിന്റെ WAN ഇന്റർഫേസിലെ വിലാസം Azure അതിനായി കാണുന്ന വിലാസവുമായി താരതമ്യം ചെയ്യുക. അവ വ്യത്യസ്തമാണെങ്കിൽ എന്തോ വിവർത്തനം ചെയ്യുന്നു, ആ വിവർത്തകൻ ഇപ്പോൾ നിങ്ങളുടെ VPN രൂപകൽപ്പനയുടെ ഭാഗമാണ്. മാപ്പിംഗ് സ്ഥിരമാണോ പങ്കിട്ടതാണോ എന്ന് ദാതാവിനോട് ചോദിക്കുക, കാരണം പങ്കിട്ട മാപ്പിംഗ് നിങ്ങൾക്ക് ആശ്രയിക്കാവുന്നതിനെ മാറ്റുന്നു. സ്വകാര്യ WAN വിലാസവും ഫോർവേഡിംഗും ഇല്ലാത്ത ഉപകരണം സ്ഥിരമായ പൊതു മാപ്പിംഗുള്ള കാരിയർ-ഗ്രേഡ് NAT-ന് പിന്നിലുള്ള ഉപകരണത്തിൽ നിന്ന് വ്യത്യസ്തമായ കേസാണ്.

രണ്ട് വിലാസങ്ങളും ഒത്തുപോയാൽ ഇവിടെ നിർത്തുക: NAT നിങ്ങളുടെ പ്രശ്നമല്ല, ഈ ലിസ്റ്റിന്റെ ബാക്കി സഹായിക്കില്ല.

ടിക്കറ്റിൽ രണ്ട് വിലാസങ്ങളും വിവർത്തകന്റെ മോഡലും രേഖപ്പെടുത്തുക. ആ ഒരു വരി കോൺഫിഗർ ചെയ്ത പിയർ എന്തുകൊണ്ട് ഉത്തരം നൽകുന്നില്ല എന്ന അടുത്ത ചോദ്യവട്ടം തടയുന്നു.

ഘട്ടം 2: ആരാണ് ആരംഭിക്കുന്നതെന്ന് യോജിക്കുക

Azure VPN Gateway FAQ 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 കൈമാറ്റം നൽകുന്നില്ല.

രണ്ട് സൈറ്റുകളും ഒത്തുപോകുന്ന സ്വകാര്യ ശ്രേണികൾ ഉപയോഗിക്കുന്നുവെങ്കിൽ ടണലിനുള്ളിലെ വിവർത്തനം സ്വന്തം നിയമങ്ങളുള്ള വേറിട്ട രൂപകൽപ്പനയാണ്. പുറം ഗേറ്റ്വേ വീട്ടിലെ റൗട്ടറിന് പിന്നിലാണ് എന്ന കാരണത്താൽ സബ്നെറ്റ് പുനർനമ്പർ ചെയ്യരുത്.

എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് പരാജയം ഘട്ടം അനുസരിച്ച് വർഗ്ഗീകരിക്കുക, ആ വർഗ്ഗീകരണം ടിക്കറ്റിൽ സൂക്ഷിക്കുക, അതുവഴി അടുത്ത ആൾ നിങ്ങൾ നിർത്തിയിടത്തുനിന്ന് ആരംഭിക്കും.