Linux EHOSTUNREACH OpenVPN-നൊപ്പം: ഏത് അടുത്ത ഹോപ്പ് പരാജയപ്പെട്ടു?

EHOSTUNREACH വിദൂര പരാജയത്തോളം തന്നെ പ്രാദേശിക തീരുമാനവുമാണ്. കെർണലിന് പാക്കറ്റ് നിരസിക്കാം, കാരണം ഒരു റൂട്ട് ലക്ഷ്യം അഗമ്യമാണെന്ന് പറയുന്നു, കാരണം Ethernet-ന്റെ അടുത്ത ഹോപ്പ് ഒരിക്കലും ഉത്തരം നൽകിയില്ല, അല്ലെങ്കിൽ കാരണം വഴിയുടെ കൂടുതൽ ദൂരത്തുനിന്ന് ഒരു ICMP host-unreachable റിപ്പോർട്ട് എത്തി. ഓരോ ഉറവിടവും വ്യത്യസ്ത പട്ടികയിലോ കാഷെയിലോ ജീവിക്കുന്നു, ഓരോന്നും വ്യത്യസ്ത സ്ഥലത്ത് പരിഹരിക്കുന്നു. സൈഫറുകളിൽ സ്പർശിക്കുന്നതോ ടണൽ വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നതോ ആയതിന് മുമ്പ് തിരഞ്ഞെടുത്ത റൂട്ടും അടുത്ത ഹോപ്പിന്റെ അവസ്ഥയും വായിക്കുക.

ക്ലയന്റ് യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന വിലാസവും നെയിംസ്പേസും തിരഞ്ഞെടുക്കുക

പിശക് ഉണ്ടാക്കിയ ലക്ഷ്യവും നെറ്റ്വർക്ക് നെയിംസ്പേസും ഉറപ്പിക്കുന്നതിൽ നിന്ന് തുടങ്ങുക. ഒരു VPN ക്ലയന്റ് അതിന്റെ സ്വന്തം നെയിംസ്പേസിൽ പ്രവർത്തിക്കാം, കൂടാതെ സ്ഥിരസ്ഥിതി നെയിംസ്പേസിൽ നിന്നുള്ള തിരയൽ വ്യത്യസ്ത നയ നിയമങ്ങളുള്ള മറ്റൊരു റൂട്ടിംഗ് പട്ടിക സമീപിക്കുന്നു.

തിരയൽ പരാജയപ്പെടുന്ന ആപ്ലിക്കേഷനുമായി ഒരേ ഉറവിടം, മാർക്ക്, പട്ടിക സന്ദർഭം ഉപയോഗിക്കണം, അല്ലാത്തപക്ഷം ആരും ചോദിക്കാത്ത ഒരു ചോദ്യത്തിന് ഉത്തരം നൽകിയേക്കാം. ഒരു ഉദാഹരണ IPv4 പിയറിന് വായന-മാത്ര പരിശോധനകൾ ഇവയാണ്:

ip -4 route get 198.51.100.25
ip -4 neigh show 198.51.100.1
ip -4 route show table all | grep -w unreachable

ഒരു അഡ്മിനിസ്ട്രേറ്റീവ് ഷെല്ലിൽ നിന്നുള്ള ഫലം ആ ഷെൽ എന്ത് ചെയ്യുമെന്ന് മാത്രം തെളിയിക്കുന്നു. ക്ലയന്റ് ഒരു ഫയർവാൾ മാർക്ക് സെറ്റ് ചെയ്യുകയോ VRF-ലേക്ക് ബന്ധിക്കുകയോ ചെയ്താൽ, പൊരുത്തപ്പെടുന്ന മാർക്ക് ഉപയോഗിച്ചോ VRF-നുള്ളിൽനിന്നോ തിരയൽ ആവർത്തിക്കുക, തിരഞ്ഞെടുത്ത റൂട്ടും അടുത്ത ഹോപ്പും താരതമ്യം ചെയ്യുക. സ്ഥിരീകരിക്കേണ്ട ആദ്യ വിലാസം പ്രൊഫൈലിലെ പിയർ വിലാസമാണ്, ഉപയോക്താവ് പേരിടുന്ന ക്ലസ്റ്ററോ സേവനമോ അല്ല.

വ്യക്തമായ അഗമ്യ റൂട്ട് പാക്കറ്റ് പ്രാദേശികമായി നിരസിക്കുന്നു

unreachable തരം റൂട്ട് ഉദ്ദേശപൂർവമുള്ള പ്രാദേശിക ഉത്തരമാണ്. അത് കെർണലിനോട് പാക്കറ്റ് ഉപേക്ഷിച്ച് EHOSTUNREACH അയച്ചയാൾക്ക് തിരികെ നൽകാൻ പറയുന്നു, അതിനാൽ പിശക് തൽക്ഷണം, യന്ത്രത്തിൽ നിന്ന് ഒരു ട്രാഫിക്കും പുറത്തുപോകാതെ പ്രത്യക്ഷപ്പെടുന്നു. ആരോ, അല്ലെങ്കിൽ ഏതോ ഓട്ടോമേഷൻ, ആ റൂട്ട് ബോധപൂർവം അവിടെ വച്ചു.

റൂട്ട് തരങ്ങൾ പരസ്പരം മാറ്റാനാവില്ല. Blackhole അയച്ചയാൾക്ക് പിശകില്ലാതെ പാക്കറ്റ് ഉപേക്ഷിക്കുന്നു, prohibit EACCES തിരികെ നൽകുന്നു, unreachable EHOSTUNREACH തിരികെ നൽകുന്നു. അതിനാൽ വീണ്ടും ബന്ധിപ്പിക്കുമ്പോൾ സിങ്ക് റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്യുന്ന ഒരു VPN സഹായി ടണൽ ഉയരുമ്പോൾ അപ്രത്യക്ഷമാകുന്ന host-unreachable പിശകങ്ങളുടെ ഒരു പ്രവാഹം ഉണ്ടാക്കാം, അതേസമയം blackhole റൂട്ട് പകരം നിശബ്ദ സമയപരിധികൾ ഉണ്ടാക്കിയേനേ.

വിദൂര അറ്റത്തെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് എല്ലാ പട്ടികകളിലും തരം തിരയുക. പട്ടിക തിരഞ്ഞെടുക്കുന്ന നിയമം അതിലെ റൂട്ടിനോളം തന്നെ പ്രധാനമാണ്, കൂടാതെ പ്രധാന പട്ടികയിൽ ചേർത്ത റൂട്ട്, അതിന്റെ നയ നിയമം ട്രാഫിക് മറ്റൊരിടത്തേക്ക് അയക്കുന്ന ക്ലയന്റിനെ സഹായിക്കില്ല.

മരിച്ച അയൽക്കാരൻ Ethernet-ൽ അതേ പിശക് ഉണ്ടാക്കുന്നു

തിരഞ്ഞെടുത്ത റൂട്ട് ഓൺ-ലിങ്ക് ഗേറ്റ്വേ ഉപയോഗിക്കുമ്പോൾ, ഡെലിവറിക്ക് പരിഹരിച്ച ലിങ്ക്-ലെയർ വിലാസം വേണം. കെർണൽ ARP അല്ലെങ്കിൽ IPv6 അയൽക്കാരൻ അഭ്യർത്ഥന അയക്കുന്നു, ഉത്തരം വരാത്ത പക്ഷം പാക്കറ്റ് ഫ്രെയിം ചെയ്യാനാവില്ല. അപ്പോൾ റൂട്ട് തന്നെ സാധുവാണെങ്കിലും അയക്കൽ EHOSTUNREACH-നൊപ്പം പരാജയപ്പെടുന്നു.

അയൽക്കാർ പട്ടിക ഘട്ടത്തെ പേരിടുന്നു. INCOMPLETE എന്നാൽ പരിഹാരം ഇപ്പോഴും നടക്കുന്നു, FAILED എന്നാൽ അവസാന ശ്രമത്തിന് ഉത്തരം കിട്ടിയില്ല, REACHABLE അല്ലെങ്കിൽ STALE എന്നാൽ കെർണലിന് ഉപയോഗയോഗ്യമായ വിലാസമുണ്ട്. VPN ഗേറ്റ്വേയ്ക്കുള്ള FAILED എൻട്രി പ്രാദേശിക ഡെലിവറി പ്രശ്നമാണ്, ടണലിന്റെ വിദൂര വശത്തെക്കുറിച്ചുള്ള തെളിവല്ല.

യഥാർത്ഥ അടുത്ത ഹോപ്പിനുള്ള എൻട്രി വായിക്കുക, വിദൂര ഇന്റർനെറ്റ് വിലാസത്തിനുള്ളതല്ല. വിദൂര വിലാസത്തിൽ സാധാരണയായി ഒരു റൂട്ടർ വഴി എത്തുന്നു, അതിനാൽ അതിന് സ്വന്തം ARP രേഖ ഉണ്ടാകില്ല; അത് ആവശ്യപ്പെടുന്നത് ഒരിക്കലും ഉണ്ടാകാനിരുന്നില്ലാത്ത ഒരു കാണാത്ത എൻട്രി തിരയാൻ ആളുകളെ അയക്കുന്ന ഒരു വിഭാഗ പിശകാണ്.

വിദൂര റിപ്പോർട്ടുകളും അസിങ്ക്രോണസ് UDP പിശകുകളും

EHOSTUNREACH-ന് പുറത്തുനിന്നും വരാം. പാക്കറ്റ് ഫോർവേഡ് ചെയ്യാനാവാത്ത ഒരു റൂട്ടർ ICMP host unreachable അയച്ചേക്കാം, കെർണൽ ആ റിപ്പോർട്ട് ഫ്ലോ ഉള്ള സോക്കറ്റിന് കൈമാറുന്നു. ആ സന്ദർഭത്തിൽ റൂട്ടും അയൽക്കാരനും കുഴപ്പമില്ല, പരാജയം പ്രാദേശിക നെറ്റ്വർക്കിനപ്പുറമുള്ള ഒരു ഹോപ്പിനുള്ളതാണ്.

UDP ആരോപണം ബുദ്ധിമുട്ടാക്കുന്നു. പിന്നീടുള്ള send അല്ലെങ്കിൽ receive കോളിൽ നിന്ന് തിരികെ ലഭിക്കുന്ന പിശക് മുൻപത്തെ ഡാറ്റാഗ്രാമിനെ സൂചിപ്പിച്ചേക്കാം, അതിനാൽ പരാജയപ്പെട്ട കോളിന്റെ വിലാസവും സമയവും റിപ്പോർട്ട് ഉണ്ടാക്കിയ പാക്കറ്റുമായി പൊരുത്തപ്പെട്ടെന്നു വരില്ല. ബന്ധിപ്പിച്ച UDP സോക്കറ്റ് പിശക് ഒരിക്കൽ സ്വീകരിക്കുന്നു, ബന്ധിപ്പിക്കാത്ത സോക്കറ്റ് അത് ഒരിക്കലും കാണാനിടയില്ല.

അതിനാൽ സമയം തെളിവിന്റെ ഭാഗമാണ്. പിശക് എപ്പോൾ പ്രത്യക്ഷപ്പെട്ടു, സോക്കറ്റ് ഏത് പിയർ വിലാസം ഉപയോഗിച്ചു, ടണൽ ഇപ്പോൾ വീണ്ടും ബന്ധിപ്പിച്ചോ എന്ന് രേഖപ്പെടുത്തുക. റൂട്ട് മാറ്റത്തിന് തൊട്ടുപിന്നാലെയുള്ള പ്രവാഹം പ്രാദേശിക പട്ടികയെ സൂചിപ്പിക്കുന്നു; സ്ഥിരതയുള്ള ഫ്ലോയുടെ കുറച്ച് മിനിറ്റുകൾക്കുശേഷമുള്ള ഒറ്റ പിശക് പാത്ത് റിപ്പോർട്ടിനെ സൂചിപ്പിക്കുന്നു.

ക്രിപ്റ്റോ മാറ്റുന്നതിന് മുമ്പ് പാളികൾ വേർതിരിക്കുക

മൂന്ന് ചോദ്യങ്ങൾ പിശക് തരംതിരിക്കുന്നു. കെർണൽ ലക്ഷ്യത്തെ നിരസിക്കുന്ന റൂട്ട് തിരഞ്ഞെടുത്തോ? സാധുവായ റൂട്ട് തിരഞ്ഞെടുത്തെങ്കിലും അടുത്ത ഹോപ്പ് പരിഹരിക്കാനായില്ലേ? അതോ പ്രാദേശിക നെറ്റ്വർക്കിനപ്പുറത്തുനിന്ന് ഒരു റിപ്പോർട്ട് എത്തിയോ? മൂന്നാമത്തെ കേസിന് മാത്രമേ ടണലിന്റെ വിദൂര അറ്റം ഉൾപ്പെടുത്താനാകൂ, അപ്പോഴും അത് എൻക്രിപ്ഷൻ ഉൾപ്പെടുത്തുന്നില്ല.

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

ആദ്യ മാറ്റത്തിന് മുമ്പ് ലക്ഷ്യം, നെയിംസ്പേസ്, തിരഞ്ഞെടുത്ത പട്ടിക, അടുത്ത ഹോപ്പ്, അയൽക്കാരന്റെ അവസ്ഥ, പിശകിന്റെ സമയം എന്നിവ രേഖപ്പെടുത്തുക. തിരുത്തലിനുശേഷം അതേ തിരയൽ വീണ്ടും പ്രവർത്തിപ്പിക്കുക; ഇപ്പോൾ ടണലിലേക്ക് ചൂണ്ടുന്ന റൂട്ടും ഇപ്പോൾ പരിഹരിക്കപ്പെടുന്ന അയൽക്കാരൻ എൻട്രിയും ബന്ധമില്ലാത്ത വിലാസത്തിലേക്കുള്ള വിജയകരമായ ping-നേക്കാൾ ശക്തമായ തെളിവാണ്.