Azure S2S VPN കണക്റ്റുചെയ്തിരിക്കുന്നു പക്ഷേ ട്രാഫിക്കില്ല: IKE ലോഗ് വായിക്കുക

പോർട്ടൽ Connected എന്ന് പറയുന്നു, ടണലിന് അപ്ടൈം കൗണ്ടർ ഉണ്ട്, നിങ്ങളുടെ വിർച്വൽ മെഷീനിൽ നിന്നുള്ള ഒരു trace രണ്ടാമത്തെ hop-ൽ മരിക്കുന്നു. കണക്ഷന്റെ അവസ്ഥ IKE, IPsec ചർച്ചകളെ വിവരിക്കുന്നു, ഇരു വശങ്ങളിലും ഒരു പാക്കറ്റ് പോളിസി പാളിയിലൂടെ കടക്കുന്നുണ്ടോ എന്നല്ല. ഈ ടിക്കറ്റുകളിൽ മിക്കവയ്ക്കും കാരണം രണ്ട് തെറ്റുകളാണ്, അവയിൽ ഒന്നും Azure റൂട്ട് മാറ്റി ശരിയാക്കാനാവില്ല. രണ്ടും ഗേറ്റ്വേ സൃഷ്ടിച്ച ലോഗിൽ ഇതിനകം എഴുതിയിട്ടുണ്ട്, അതുകൊണ്ട് ഞാൻ റൂട്ട് ടേബിളിൽ നിന്നല്ല, അവിടെ നിന്ന് തുടങ്ങുന്നു.

Connected യഥാർത്ഥത്തിൽ എന്താണ് സാക്ഷ്യപ്പെടുത്തുന്നത്

കണക്റ്റുചെയ്ത site-to-site കണക്ഷൻ അർത്ഥമാക്കുന്നത് ഘട്ടം 1ഉം ഘട്ടം 2ഉം പൂർത്തിയായി എന്നും സുരക്ഷാ അസോസിയേഷനുകൾ സജീവമാണ് എന്നുമാണ്. അത് ചർച്ചയെക്കുറിച്ചുള്ള ഒരു പ്രസ്താവനയാണ്: ഇരു പീയറുകളും ഒരു നിർദ്ദേശത്തിൽ യോജിച്ചു, കീകൾ കൈമാറി, SA ജോടി ഇൻസ്റ്റാൾ ചെയ്തു. നിങ്ങൾ സംരക്ഷിതമെന്ന് കരുതുന്ന സബ്നെറ്റുകളുമായി ട്രാഫിക് സെലക്ടറുകൾ പൊരുത്തപ്പെടുന്നുണ്ടോ എന്ന് അത് പറയുന്നില്ല, ഡീക്രിപ്റ്റ് ചെയ്ത ശേഷം ദൂരെയുള്ള വശം പാക്കറ്റ് എവിടെയെങ്കിലും റൂട്ട് ചെയ്യുമോ എന്നും പറയുന്നില്ല. ആഴ്ചകളോളം ടണൽ നിലനിൽക്കുമ്പോൾ തന്നെ ഓരോ താൽപര്യമുള്ള ഫ്ലോയും ഉപേക്ഷിക്കാം, ആരോഗ്യകരമായ ഗേറ്റ്വേ വീണ്ടും നിർമ്മിക്കാൻ ആളുകളെ പ്രേരിപ്പിക്കുന്നത് അതേ മാതൃകയാണ്.

ആദ്യം പരിശോധിക്കേണ്ട രണ്ട് തെറ്റുകൾ ESP-ന് പകരം AH നിർദ്ദേശിക്കുന്ന ഒരു പീയറും, ഗേറ്റ്വേ ആന്തരികമായി കണക്കാക്കാത്ത ഇടത്ത് നമ്പർ ഇട്ട ഒരു വിർച്വൽ നെറ്റ്വർക്കും ആണ്.

റൂട്ടുകളിൽ തൊടുന്നതിന് മുമ്പ് കയറ്റുമതി ചെയ്ത ലോഗ് തുറക്കുക

പോർട്ടലിൽ വിർച്വൽ നെറ്റ്വർക്ക് ഗേറ്റ്വേ തുറന്ന് കണക്ഷനിൽ VPN troubleshoot പ്രവർത്തനം നടത്തുക, തുടർന്ന് അത് സൃഷ്ടിക്കുന്ന ബണ്ടിൽ ഡൗൺലോഡ് ചെയ്ത് അൺപാക്ക് ചെയ്യുക. അകത്ത് ഘട്ടം 1, ഘട്ടം 2 കൈമാറ്റങ്ങളുള്ള IKE ലോഗ് ഉണ്ട്, സമയ മുദ്രകളോടെയും സാധാരണ ടെക്സ്റ്റായി വായിക്കാവുന്നതും. മുകളിൽ നിന്ന് താഴേക്ക് വായിക്കുന്നതിന് പകരം അതിൽ transform വരി തിരയുക, കാരണം താൽപര്യമുള്ള എൻട്രി സാധാരണയായി കുറച്ച് നൂറ് വരികൾക്കുള്ളിൽ ആയിരിക്കും. പോർട്ടലിലേക്ക് പ്രവേശനമില്ലെങ്കിൽ, ഡയഗ്നോസ്റ്റിക് ക്രമീകരണങ്ങൾ പ്രവർത്തനക്ഷമമാക്കിയാൽ അതേ ഡയഗ്നോസ്റ്റിക്സ് ഗേറ്റ്വേയുടെ ലോഗ് ലക്ഷ്യസ്ഥാനത്ത് പ്രത്യക്ഷപ്പെടും.

രണ്ട് എൻട്രികളാണ് മൂല്യത്തിന്റെ ഭൂരിഭാഗവും വഹിക്കുന്നത്. ആദ്യത്തേത് ഏകദേശം ഇങ്ങനെ വായിക്കുന്നു: expected ESP with combined authentication and cipher, received AH. രണ്ടാമത്തേത് IKE കൈമാറ്റത്തിനിടയിലെ invalid payload പിശകാണ്, ഇത് സാധാരണയായി തെറ്റായി രൂപപ്പെടുത്തിയതോ പിന്തുണയ്ക്കാത്തതോ ആയ നിർദ്ദേശ ഫീൽഡ് എന്നാണ് അർത്ഥമാക്കുന്നത്.

രണ്ടും ഓൺ-പ്രെമൈസ് ഉപകരണം എന്താണ് നിർദ്ദേശിച്ചത് എന്ന് വിവരിക്കുന്നു, അതിനാൽ രണ്ടും പീയർ വശത്തെ ക്രമീകരണങ്ങളാണ്. കണക്ഷന്റെ Azure വശം വീണ്ടും സൃഷ്ടിക്കുന്നത് നിങ്ങളുടെ ഫയർവാൾ അയയ്ക്കുന്ന നിർദ്ദേശം മാറ്റുന്നില്ല, അങ്ങനെ ചെയ്യുന്നത് ഈ ജോലിയിൽ ഏറ്റവും കൂടുതൽ പാഴാക്കുന്ന മണിക്കൂറാണ്. പീയറിൽ ഘട്ടം 2 സംയോജിത ആധികാരികതയും സൈഫറും ഉള്ള ESP-യിലേക്ക് ക്രമീകരിച്ച് അൽഗോരിതം ചർച്ച ചെയ്യാൻ അനുവദിക്കുക, തുടർന്ന് combined mode പോലുള്ള പേരുള്ള ഒരു വെണ്ടർ ചെക്ക്ബോക്സ് അതിനടിയിൽ നിന്ന് നിശബ്ദമായി AH നിർദ്ദേശം തിരഞ്ഞെടുക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക.

വിർച്വൽ നെറ്റ്വർക്കിന്റെ വിലാസ സ്ഥലം സ്ഥിരീകരിക്കുക

ഗേറ്റ്വേ വിർച്വൽ നെറ്റ്വർക്ക് സ്വകാര്യ ശ്രേണികളിൽ ആയിരിക്കണമെന്ന് പ്രതീക്ഷിക്കുന്നു. പൊതു ബ്ലോക്കിൽ നമ്പർ ഇട്ട നെറ്റ്വർക്ക്, ഉദാഹരണത്തിന് 111.x ൽ തുടങ്ങുന്നത്, ടണൽ ഉയർത്തിയേക്കാം, പക്ഷേ Azure ആ സ്ഥലം ആന്തരികമായി കണക്കാക്കാൻ വിസമ്മതിക്കുന്നു, അതിനാൽ കണക്ഷൻ ആരോഗ്യകരമായി തോന്നുന്നു, ഒരു ഫ്ലോയും സ്വീകരിക്കുന്നില്ല. സെലക്ടറുകളിൽ ഒരു ഉച്ചയ്ക്ക് ചെലവഴിക്കുന്നതിന് മുമ്പ് വിലാസ സ്ഥലം സ്ഥിരീകരിക്കുക. നമ്പറിംഗ് പഴയ അനുവദനത്തിൽ നിന്നുള്ള കർശനമായ ആവശ്യമാണെങ്കിൽ, പരിഹാരം മറ്റൊരു ഗേറ്റ്വേയല്ല, വിലാസ പ്ലാൻ മാറ്റുന്നതാണ്.

വിലാസ സ്ഥല ബ്ലേഡിൽ ആയിരിക്കുമ്പോൾ തന്നെ ഓൺ-പ്രെമൈസ് ശ്രേണികളുമായുള്ള ഓവർലാപ്പ് രേഖപ്പെടുത്തുക, കാരണം ഓവർലാപ്പ് ചെയ്യുന്ന പ്രിഫിക്സുകൾ ക്ലയന്റിൽ നിന്ന് സമാനമായി തോന്നുന്ന മറ്റൊരു തരത്തിലുള്ള പരാജയം സൃഷ്ടിക്കുന്നു.

ഇരു ദിശകളിലും പ്രിഫിക്സുകൾ പരിശോധിക്കുക

ലോക്കൽ നെറ്റ്വർക്ക് ഗേറ്റ്വേ റിസോഴ്സിൽ ഓൺ-പ്രെമൈസ് പ്രിഫിക്സുകൾ ഉണ്ട്, അവ ദൂരെയുള്ള ഉപകരണം യഥാർത്ഥത്തിൽ സംരക്ഷിക്കുന്ന സബ്നെറ്റുകളുമായി പൊരുത്തപ്പെടണം. ഉപകരണം ഉപേക്ഷിക്കുന്ന വിലാസങ്ങൾ ഉൾപ്പെടുത്തുന്ന ഒരു സംഗ്രഹം ചില ഫ്ലോകൾ കടത്തിവിടുകയും മറ്റുള്ളവയിൽ പരാജയപ്പെടുകയും ചെയ്യും, ഇത് കോൺഫിഗറേഷൻ പൊരുത്തക്കേടായല്ല, ഇടയ്ക്കിടെയുള്ള റൂട്ടിംഗ് തകരാറായി വായിക്കപ്പെടുന്നു. ദൂരെയുള്ള വശവും പരിശോധിക്കുക: ഒരു അറ്റം /16 പട്ടികപ്പെടുത്തുമ്പോൾ മറ്റേ അറ്റം അതിനുള്ളിൽ മൂന്ന് /24 പട്ടികപ്പെടുത്തുന്നത് ക്ലാസിക് ഭാഗിക പരാജയമാണ്. ഒരു പട്ടികയും സ്വയം അധികാരമുള്ളതല്ല, അതിനാൽ കാണുന്നതിനെ വിശ്വസിക്കുന്നതിന് പകരം രണ്ടും അടുത്തടുത്ത് താരതമ്യം ചെയ്യുക.

പ്രിഫിക്സ് മാറ്റം എപ്പോഴും സ്വയം പിടിച്ചെടുക്കുന്നില്ല, അതിനാൽ കണക്ഷൻ ഒബ്ജക്റ്റ് വീണ്ടും സംരക്ഷിക്കാനോ വീണ്ടും സൃഷ്ടിക്കാനോ പദ്ധതിയിട്ട്, പുതിയ പ്രിഫിക്സുകൾ ഇരു വശങ്ങളിലും പ്രത്യക്ഷപ്പെടുന്നുണ്ടെന്ന് സ്ഥിരീകരിക്കുക.

ping അല്ല, പാത പരീക്ഷിക്കുക

പ്രവർത്തിക്കുന്ന ടണലിനെ പ്രവർത്തിക്കുന്ന റൂട്ടിൽ നിന്ന് വേർതിരിക്കുന്ന trace ഇങ്ങനെയാണ്: ആദ്യ hop ഓൺ-പ്രെമൈസ് ഗേറ്റ്വേ, പിന്നെ പ്രതികരിക്കാത്ത കുറച്ച് hop, പിന്നെ ദൂരെയുള്ള ഹോസ്റ്റ് മറുപടി നൽകുന്നു. trace ഒരിക്കലും ഹോസ്റ്റിൽ എത്തുന്നില്ലെങ്കിൽ, അപ്ലിക്കേഷൻ യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന TCP പോർട്ട് പരീക്ഷിക്കുക, കാരണം ICMP മതിയായ ആവർത്തനത്തിൽ ഫിൽട്ടർ ചെയ്യപ്പെടുന്നു, പരാജയപ്പെട്ട ping വളരെ കുറച്ച് മാത്രമേ തെളിയിക്കുന്നുള്ളൂ. അതേ trace ദൂരെയുള്ള ഹോസ്റ്റിൽ നിന്ന് Azure-ലെ വിർച്വൽ മെഷീനിലേക്ക് പ്രവർത്തിപ്പിക്കുക. രണ്ട് ഫലങ്ങൾ തമ്മിലുള്ള അസമമിതിയാണ് കാണാതായ റിട്ടേൺ റൂട്ടോ ഒരു ദിശ മാത്രം അനുവദിക്കുന്ന നിയമമോ കണ്ടെത്താനുള്ള ഏറ്റവും വേഗതയുള്ള വഴി.

പീയർ നിർദ്ദേശം, രണ്ട് വിലാസ സ്ഥലങ്ങൾ, കണക്ഷൻ സൃഷ്ടിച്ച സമയം എന്നിവ ടിക്കറ്റിൽ എഴുതുക, അടുത്ത എഞ്ചിനീയർക്ക് ഏത് മൂല്യങ്ങൾ വീണ്ടും നിർമ്മിച്ചു, ഏതിൽ ഒരിക്കലും തൊട്ടിട്ടില്ല എന്ന് അറിയാൻ.

ലോഗ് ശൂന്യമായി തിരികെ വന്നാൽ, ഗേറ്റ്വേ നിങ്ങളുടെ കണക്ഷൻ അവസാനിപ്പിക്കുന്നേയില്ലായിരിക്കാം. ലോക്കൽ നെറ്റ്വർക്ക് ഗേറ്റ്വേയിലെ പീയർ വിലാസം നിങ്ങൾ ലോഗ് വായിക്കുന്ന ഉപകരണവുമായി പൊരുത്തപ്പെടുന്നുണ്ടെന്ന് സ്ഥിരീകരിക്കുക, കാരണം ഒരേ സബ്സ്ക്രിപ്ഷനിലെ രണ്ട് ഗേറ്റ്വേകൾ പുനർനിർമ്മാണ വേളയിൽ എളുപ്പത്തിൽ കൺഫ്യൂസ് ചെയ്യപ്പെടും. ആ തെറ്റ് ഒരു ദിവസം എടുക്കും, ഒരു ലോഗിലും അടയാളം അവശേഷിപ്പിക്കുന്നുമില്ല.