ടണൽ ഇപ്പോഴും ഉണ്ട്, റൂട്ട് പോയി: രണ്ട് VPN പരാജയങ്ങൾ വേർതിരിക്കൽ

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

ഒരു സംഭവം പോലെ തോന്നുന്ന മൂന്ന് ഘട്ടങ്ങൾ

റൂട്ടിംഗ് തീരുമാനത്തിന് മൂന്ന് ഘട്ടങ്ങളുണ്ട്. പ്രിഫിക്സ് സ്വീകരിക്കുന്നു, മികച്ചതായി തിരഞ്ഞെടുക്കുന്നു, ഫോർവേഡിംഗ് പട്ടികയിൽ ഇൻസ്റ്റാൾ ചെയ്യുന്നു. ഓരോ ഘട്ടവും സ്വന്തമായി പരാജയപ്പെടാം, ആപ്ലിക്കേഷന്റെ ഭാഗത്തുനിന്ന് പരാജയം ഒരുപോലെ കാണപ്പെടുന്നു. പഠിച്ചെങ്കിലും തിരഞ്ഞെടുപ്പിൽ തോറ്റ പ്രിഫിക്സിനെ, ഫോർവേഡിംഗ് പട്ടിക മാത്രം നോക്കിയാൽ ഒരിക്കലും വന്നിട്ടില്ലാത്ത പ്രിഫിക്സിൽനിന്ന് വേർതിരിക്കാനാകില്ല.

അതിനാൽ ആദ്യ ചോദ്യം ഏത് പ്രോട്ടോക്കോൾ കുറ്റക്കാരനെന്നല്ല, ഏത് ഘട്ടം തകർന്നു എന്നാണ്. ഉത്തരം സംഭവം ആരുടേതാണെന്നും അടുത്ത പരിശോധന ഏത് ഉപകരണം ഉപയോഗിക്കുമെന്നും തീരുമാനിക്കുന്നു.

ആദ്യം ഇൻസ്റ്റാൾ ചെയ്ത റൂട്ട് വായിക്കുക

പരാജയപ്പെടുന്ന ലക്ഷ്യത്തിലേക്കുള്ള ട്രാഫിക് യഥാർത്ഥത്തിൽ എവിടെ പോകുന്നുവെന്ന് കേർണലിനോട് ചോദിക്കുക. ip route get അടുത്ത ഹോപ്പ്, ഇന്റർഫേസ്, കേർണൽ ഉപയോഗിക്കുന്ന സ്രോതസ്സ് വിലാസം എന്നിവ പ്രിന്റ് ചെയ്യുന്നു, മുഴുവൻ പട്ടികയ്ക്കല്ല, ഒരു ലക്ഷ്യത്തിന് ഉത്തരം നൽകുന്നു. ഉത്തരം ടണലിനെ പേരിട്ടാൽ, ഫോർവേഡിംഗ് പട്ടിക ഇപ്പോഴും പാത നിലവിലുണ്ടെന്ന് വിശ്വസിക്കുന്നു, പ്രശ്നം അതിന് മുകളിലാണ്.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

«unreachable» എന്ന ഉത്തരം അർത്ഥം ഇൻസ്റ്റാൾ ചെയ്ത റൂട്ട് ഒന്നുമില്ല എന്നാണ്, ഇത് പിൻവലിക്കലിലേക്കോ വിട്ടുപോയ ഇൻസ്റ്റാളിലേക്കോ വിരൽ ചൂണ്ടുന്നു. ഭൗതിക ഇന്റർഫേസിനെ പേരിടുന്ന ഉത്തരം അർത്ഥം ആരും തീരുമാനിക്കാതെ ട്രാഫിക് ടണൽ വിട്ടു എന്നാണ്, അടുത്ത പരിശോധന വിജയിച്ച മുൻഗണനയാണ്. പാക്കറ്റുകൾ ഇപ്പോഴും അപ്രത്യക്ഷമാകുമ്പോൾ ടണലിനെ പേരിടുന്ന ഉത്തരം പാതയിൽ കൂടുതൽ താഴേക്ക്, ഫിൽട്ടറിംഗിലേക്കോ എതിർവശത്തേക്കോ വിരൽ ചൂണ്ടുന്നു.

പിന്നെ പ്രോട്ടോക്കോളിന്റെ സ്വന്തം കാഴ്ച നോക്കുക

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

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

സാരാംശം സെഷൻ സ്ഥാപിതമായോ എന്ന് പറയുന്നു, പ്രിഫിക്സ് അനുസരിച്ചുള്ള കാഴ്ച പ്രിഫിക്സ് സ്വീകരിച്ചോ എന്ന് പറയുന്നു, കേർണലിലെ തിരയൽ അത് ഇൻസ്റ്റാൾ ചെയ്തോ എന്ന് പറയുന്നു. ഈ ക്രമത്തിൽ വായിച്ചാൽ സെഷന്റെ വിറയലിനെ പിൻവലിക്കലായി, പിൻവലിക്കലിനെ നയാധിഷ്ഠിത നിരസിക്കലായി തെറ്റിദ്ധരിക്കാതിരിക്കും.

ക്ലോക്കുകൾ യോജിക്കാത്തപ്പോൾ

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

ഒരു മിനിറ്റ് ക്ലോക്ക് വ്യതിയാനം ആ നിഗമനം തലകീഴാക്കാൻ മതി, അതിനാൽ ക്രമം വിശ്വസിക്കുന്നതിന് മുൻപ് സമയ മേഖലയും ഓഫ്സെറ്റും സ്ഥിരീകരിക്കുക. ഓഫ്സെറ്റ് ഇല്ലാതെ പ്രാദേശിക സമയത്ത് ലോഗ് സൂക്ഷിക്കുന്ന ഉപകരണങ്ങളാണ് ആത്മവിശ്വാസമുള്ളതും എന്നാൽ തെറ്റായതുമായ സമയരേഖയുടെ സാധാരണ ഉറവിടം.

ലൂപ്പ് ഇല്ലാത്ത വീണ്ടെടുക്കൽ

പിൻവലിക്കലിന് ശേഷം രണ്ട് പാതകൾ യോഗ്യമായിരിക്കാം: പ്രോട്ടോക്കോൾ തിരഞ്ഞെടുക്കുന്ന പാതയും നിങ്ങൾ കൈകൊണ്ട് പിൻ ചെയ്യുന്ന പാതയും. നെറ്റ്വർക്ക് നിങ്ങൾക്കുവേണ്ടി എടുത്തുകൊണ്ടിരിക്കുന്ന തീരുമാനം ആദ്യത്തേത് മാത്രമാണ്, അതിനാൽ കൈമാർഗ്ഗം വീണ്ടെടുക്കൽ പദ്ധതിയല്ല, താൽക്കാലിക പരിഹാരമാണ്. ഇതിനകം സ്ഥാപിതമായ സെഷനുവേണ്ടി ഫയർവാൾ അല്ലെങ്കിൽ NAT നില ബദൽ പ്രഖ്യാപനവും സൂക്ഷിക്കുന്നില്ല, അതിനാൽ പുതിയ പ്രവാഹങ്ങൾ പ്രവർത്തിക്കാം, യഥാർത്ഥമെങ്കിൽ തകർന്ന് തുടരാം. ഏത് ബാക്കപ്പ് സജീവമാകണം, വിദൂര സൈറ്റ് അതിലൂടെ മടക്ക പാത സ്വീകരിക്കുമോ എന്നിവ സ്ഥിരീകരിക്കുക.

പിൻവലിക്കൽ എന്തുകൊണ്ട് സംഭവിച്ചുവെന്ന് മനസ്സിലാക്കുന്നതിന് മുൻപ് സ്ഥിരമായ സ്റ്റാറ്റിക് ഓവർറൈഡ് ഇൻസ്റ്റാൾ ചെയ്യരുത്. ആ ഷോർട്ട്കട്ട് ട്രാഫിക്കിനെ പരാജയപ്പെട്ട പാതയിൽ പിൻ ചെയ്യാം അല്ലെങ്കിൽ ബോധപൂർവമായ റൂട്ടിംഗ് നയം നിശ്ശബ്ദമായി മറികടക്കാം, യഥാർത്ഥ കാരണം പുതിയ കോൺഫിഗറേഷന് കീഴിൽ കുഴിച്ചിടുന്നു. റൂട്ട് പുനഃസ്ഥാപിച്ച ശേഷം ആപ്ലിക്കേഷൻ വീണ്ടും പരിശോധിക്കുക, തിരഞ്ഞെടുത്ത പ്രിഫിക്സിന് പട്ടികയിലെ എൻട്രി മാത്രമല്ല, പ്രവർത്തിക്കുന്ന ഡാറ്റ പാതയുണ്ടെന്ന് സ്ഥിരീകരിക്കുക.