Azure P2S VPN-ന്റെ തിരിച്ചുവരവ് ട്രാഫിക് ഒരു ദിശയിൽ മാത്രം പ്രവർത്തിക്കുന്നു

ടണൽ ഐക്കൺ പച്ചയാണ്, NSG അനുവദിക്കുന്നതായി തോന്നുന്നു, ഫലപ്രദമായ റൂട്ടുകൾ ശരിയായി കാണപ്പെടുന്നു, എന്നിട്ടും VM-ന് ബന്ധിപ്പിച്ച ക്ലയന്റിലേക്ക് തിരികെ ഒരു കണക്ഷൻ തുറക്കാനാകുന്നില്ല. സാധാരണ ഊഹം ഇതാണ്: പ്രവർത്തിക്കുന്ന point-to-site ടണൽ സമമിതമാണ്; ക്ലയന്റ് VM-നെ എത്തുന്നുവെങ്കിൽ VM-ഉം ക്ലയന്റിനെ എത്തും. ആ ഊഹമാണ് യുക്തിയിലെ പിഴവ്, കോൺഫിഗറേഷനിലെ അല്ല. ഒരു ടണലിന് അഭ്യർത്ഥിക്കാത്ത പ്രവാഹത്തിന്റെ ഒരു ദിശ കൊണ്ടുപോകാനും മറ്റേത് ഉപേക്ഷിക്കാനും കഴിയും, പരിഹാരം ഏത് ലെയർ അത് ഉപേക്ഷിക്കുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.

മിഥ്യ: ബന്ധിപ്പിച്ച ടണൽ ഇരുദിശാ ടണലാണ്

VPN ടണൽ ഒരു നയപഥമാണ്, വയർ അല്ല. ഓരോ ദിശയും സെലക്ടർമാർ, റൂട്ടുകൾ, ഫിൽട്ടറുകൾ എന്നിവയുമായി പൊരുത്തപ്പെടുത്തുന്നു, അവയിൽ ഏതെങ്കിലും ഒന്ന് ഒരു ദിശ അനുവദിച്ച് മറ്റേത് തടയാം.

പ്രായോഗികമായി അസമത്വം വളരെ സാധാരണമാണ്, അതിനാൽ ദിശ ആദ്യ പരിശോധനയിൽ വേണം, അവസാനത്തേതിൽ അല്ല. ക്ലയന്റ് ആരംഭിക്കുന്നു, ഗേറ്റ്വേ പ്രവാഹം ട്രാക്ക് ചെയ്യുന്നു, മറുപടി സൃഷ്ടിച്ച അവസ്ഥ പിന്തുടരുന്നു. പുതിയ പ്രവാഹം ആരംഭിക്കുന്ന VM-ന് അത്തരം അവസ്ഥയില്ല, അതിനാൽ തിരിച്ചുവരവ് പാത വ്യക്തമായി റൂട്ട് ചെയ്യാവുന്നതും അനുവദിക്കപ്പെട്ടതുമായിരിക്കണം എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു. ആ പാത ഇല്ലെങ്കിൽ, ഏതെങ്കിലും ആപ്ലിക്കേഷൻ അത് കാണുന്നതിന് മുമ്പേ കണക്ഷൻ ശ്രമം മരിക്കുന്നു.

എത്തിച്ചേരാനുള്ള കഴിവ് പരിശോധിക്കുന്നതിന് മുമ്പ് ദിശ പരിശോധിക്കുക

ഒരു ക്ലയന്റ് വിലാസം, ഒരു VM വിലാസം, ഒരു പ്രോട്ടോക്കോൾ എന്നിവ തിരഞ്ഞെടുക്കുക. ക്ലയന്റിൽ നിന്ന് കണക്ട് ചെയ്ത് ഫലം രേഖപ്പെടുത്തുക; പിന്നീട് അതേ പരിശോധന VM-ൽ നിന്ന് ആരംഭിച്ച് അതും രേഖപ്പെടുത്തുക. ആദ്യത്തേത് വിജയിക്കുകയും രണ്ടാമത്തേത് പരാജയപ്പെടുകയും ചെയ്താൽ, ക്ലയന്റ് പൂൾ, ഗേറ്റ്വേ അസോസിയേഷൻ, ക്ലയന്റിൽ നിന്ന് VNet-ലേക്കുള്ള പാത എന്നിവയെല്ലാം പ്രവർത്തിക്കുന്നു.

അടുത്ത ഘട്ടം തെളിവുകളാണ്, കൂടുതൽ നിയമങ്ങളല്ല. VM സബ്നെറ്റിലെ NSG ഇരുദിശകളിലും പരിശോധിക്കുക, VM-ന്റെ NIC-ൽ ഫലപ്രദമായ റൂട്ടുകൾ വായിക്കുക, ക്ലയന്റ് ട്രാഫിക് അയക്കുമ്പോൾ VM-ൽ പാക്കറ്റുകൾ പിടിച്ചെടുക്കുക. മറുപടിയില്ലാതെ എത്തുന്ന അഭ്യർത്ഥന ഫിൽട്ടർ അല്ലെങ്കിൽ തിരിച്ചുവരവ് റൂട്ട് പ്രശ്നമാണ്; ഒരിക്കലും എത്താത്ത അഭ്യർത്ഥന പാത പ്രശ്നമാണ്. പരാജയപ്പെട്ട ping-നെ VM എത്തിച്ചേരാനാകില്ല എന്നതിന്റെ തെളിവായി കാണരുത്, കാരണം TCP പ്രവർത്തിക്കുമ്പോൾ ICMP നയത്തിന് മറുപടി ഉപേക്ഷിക്കാനാകും.

IKEv2 point-to-site തിരിച്ചുവരവ് പാതയാണ് സാധാരണ സംശയിക്കുന്നത്

ഈ ലേഖനത്തിന് പിന്നിലുള്ള Azure റിപ്പോർട്ടിൽ, ഒരു ക്ലയന്റിന് IKEv2 വഴി VM-കളിൽ എത്താനാകുമായിരുന്നു, പക്ഷേ VM-ൽ നിന്ന് ക്ലയന്റിലേക്കുള്ള ഇൻബൗണ്ട് ICMP, ഗേറ്റ്വേയുടെ ടണൽ തരം OpenVPN-ലേക്ക് മാറ്റുന്നതുവരെ പരാജയപ്പെട്ടു. റിപ്പോർട്ട് രചയിതാവ് പറയുന്നത്, IKEv2 point-to-site പാതയിൽ ഒരു പരിമിതി Microsoft സ്ഥിരീകരിച്ചു എന്നാണ്: ക്ലയന്റ് സെഷൻ ആരംഭിച്ചില്ലെങ്കിൽ VM-ൽ നിന്ന് ക്ലയന്റിലേക്കുള്ള തിരിച്ചുവരവ് ട്രാഫിക് സമമിതമായി റൂട്ട് ചെയ്യപ്പെടുന്നില്ല. IKEv2 ട്രാഫിക് സെലക്ടറുകളെ ആശ്രയിക്കുന്നു, ആ സന്ദർഭത്തിൽ ഗേറ്റ്വേ തിരിച്ചുവരവ് ദിശ മാനിച്ചില്ല.

അത് OpenVPN-നെ പൊതുവായി മികച്ച ടണൽ തരമാക്കുന്നില്ല. ഈ ജോലിഭാരത്തിന്റെ പരിശോധന മെട്രിക്സിൽ ടണൽ തരത്തെ ഒരു ചരമാക്കുന്നു.

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

മിഥ്യ: ബ്രോഡ്കാസ്റ്റ് കണ്ടെത്തൽ VNet അതിർത്തി കടക്കുന്നു

രണ്ടാമത്തെ ഊഹം ബന്ധമില്ലാത്ത കാരണത്താൽ പരാജയപ്പെടുന്നു. Azure വെർച്വൽ നെറ്റ്വർക്ക് ബ്രോഡ്കാസ്റ്റ് ട്രാഫിക് കൊണ്ടുപോകുന്നില്ല, അതിനാൽ VM-ന് site-to-site അല്ലെങ്കിൽ point-to-site കണക്ഷനിലൂടെ ഓൺ-പ്രെമൈസ് നെറ്റ്വർക്കിൽ നിന്ന് ബ്രോഡ്കാസ്റ്റ് ഫ്രെയിമുകൾ സ്വീകരിക്കാനാകില്ല. ബ്രോഡ്കാസ്റ്റ് വഴി സഹകാരികളെ കണ്ടെത്തുന്ന ആപ്ലിക്കേഷനുകൾ, ഉദാഹരണത്തിന് പഴയ ഫയൽ ബ്രൗസിംഗ് അല്ലെങ്കിൽ ചില ഉപകരണ-കണ്ടെത്തൽ പ്രോട്ടോക്കോളുകൾ, റൂട്ടുകൾ എങ്ങനെ എഴുതിയാലും വിദൂര വശം ഒരിക്കലും കാണില്ല.

ബ്രോഡ്കാസ്റ്റ് കണ്ടെത്തൽ DNS നാമങ്ങൾ, ഡയറക്ടറി സേവനം അല്ലെങ്കിൽ വ്യക്തമായ സഹകാരി പട്ടിക എന്നിവ ഉപയോഗിച്ച് മാറ്റുക. ആപ്ലിക്കേഷന് unicast ബദൽ ഇല്ലെങ്കിൽ, രൂപകൽപ്പനയ്ക്ക് വീതിയേറിയ ടണലല്ല, മറ്റൊരു കണ്ടെത്തൽ സംവിധാനം വേണം.

എന്ത് മാറ്റണം, എങ്ങനെ തെളിയിക്കണം

ദിശാ പരിശോധന IKEv2-ൽ മാത്രം പരാജയപ്പെട്ടാൽ, ഗേറ്റ്വേയുടെ ടണൽ തരം, ക്ലയന്റ് വിലാസ പൂൾ, കൃത്യമായ ICMP അല്ലെങ്കിൽ TCP പരിശോധന എന്നിവ രേഖപ്പെടുത്തുക, തുടർന്ന് ബാധിത ക്ലയന്റുകൾക്കായി അനുവദിച്ച OpenVPN പ്രൊഫൈൽ വിലയിരുത്തുക. എല്ലാ ടണൽ തരങ്ങളിലും പരാജയപ്പെട്ടാൽ, തിരിച്ചുവരവ് പാതയിൽ പ്രവർത്തിക്കുക: ക്ലയന്റ് വിലാസം VM സബ്നെറ്റിൽ നിന്ന് റൂട്ട് ചെയ്യാവുന്നതായിരിക്കണം, ഉപയോക്താവ് നിർവചിച്ച ഏത് റൂട്ടും സാധുവായ അടുത്ത ഹോപ്പിലേക്ക് ചൂണ്ടണം, ക്ലയന്റ് ഫയർവാൾ ഇൻബൗണ്ട് പ്രവാഹം സ്വീകരിക്കണം. NSG, റൂട്ട് തെളിവുകൾ ടിക്കറ്റിൽ ഉൾപ്പെടുത്തുക.

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