തുല്യ ചെലവുള്ള റൂട്ടുകൾ VPN തകരാറുകൾ കാണാൻ പ്രയാസമാക്കുന്നത് എന്തുകൊണ്ട്

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

ഒരു ping, നിരവധി സാധ്യമായ പാതകൾ

ഒരു റൂട്ടിന് ഒരേ ചെലവിൽ ഒന്നിലധികം അടുത്ത ഹോപ്പുകൾ ഉണ്ടെങ്കിൽ, റൂട്ടർ ഓരോ പാക്കറ്റിനും ഒന്ന് തിരഞ്ഞെടുക്കണം. മിക്ക നടപ്പാക്കലുകളും പാക്കറ്റിലെ ഫീൽഡുകൾ ഹാഷ് ചെയ്യുന്നു, സാധാരണയായി ഉറവിട, ലക്ഷ്യ വിലാസങ്ങൾ പ്രോട്ടോക്കോളിനും പോർട്ടുകൾക്കുമൊപ്പം, പ്രതികരണങ്ങൾ അതേ പാതയിൽ നിലനിൽക്കാൻ. വ്യത്യസ്ത ആപ്ലിക്കേഷനുകൾ, ഒരേ ആപ്ലിക്കേഷന്റെ വ്യത്യസ്ത കണക്ഷനുകൾ പോലും വ്യത്യസ്ത ഹാഷുകൾ സൃഷ്ടിക്കുന്നു.

അതുകൊണ്ടാണ് ഗേറ്റ്‌വേയിൽ നിന്നുള്ള ഡയഗ്നോസ്റ്റിക്സ് വളരെ കുറച്ച് മാത്രം തെളിയിക്കുന്നത്. ഗേറ്റ്‌വേയുടെ സ്വന്തം പരിശോധനയ്ക്ക് സ്വന്തം വിലാസങ്ങളും പോർട്ടുകളും ഉണ്ട്, അതിനാൽ സ്വന്തം ഹാഷും. ആരോഗ്യകരമായ ടണലിൽ അത് എത്തിയേക്കാം, ഉപയോക്താവ് തകർന്ന ടണലിൽ തുടരുമ്പോൾ.

പ്ലാറ്റ്ഫോം അടുത്ത ഹോപ്പ് തിരഞ്ഞെടുക്കുന്നത് എങ്ങനെ

ഊഹിക്കുന്നതിന് പകരം തിരഞ്ഞെടുപ്പ് പുനരാവിഷ്കരിക്കുക. പരാജയപ്പെടുന്ന സെഷനുള്ള അതേ ഉറവിടത്തിനും ലക്ഷ്യത്തിനും കേർണൽ ഏത് റൂട്ട് ഉപയോഗിക്കുമെന്ന് ചോദിക്കുക. ലളിതമായ ലക്ഷ്യ-തിരയൽ അവഗണിക്കുന്ന ഫീൽഡുകളും ആ തിരയലിൽ ഉൾപ്പെടുന്നു. പ്രവർത്തിക്കുന്ന ഒരു ക്ലയന്റിൽ നിന്നും അത് പ്രവർത്തിപ്പിച്ച് രണ്ട് ഉത്തരങ്ങളും താരതമ്യം ചെയ്യുക:

ip route get 10.20.5.7 from 10.20.0.14

പുതിയ iproute2 പതിപ്പുകൾ പ്രോട്ടോക്കോളും ലക്ഷ്യ പോർട്ടും സ്വീകരിക്കുന്നു, ഹാഷിൽ അവ ഉൾപ്പെടുമ്പോൾ ഇത് പ്രധാനമാണ്. ആ ഔട്ട്പുട്ട് പ്രവർത്തിക്കുന്ന ക്ലയന്റിൽ നിന്നുള്ള അതേ തിരയലുമായി താരതമ്യം ചെയ്യുക, വ്യത്യാസമാണ് നിങ്ങൾക്ക് നഷ്ടമായ തെളിവ്.

പരാജയപ്പെടുന്ന ഫ്ലോ പിന്തുടരുക, റൂട്ട് പട്ടികയല്ല

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

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

ഓരോ പാതയിലും MTU പരിശോധിക്കുക. അധിക എൻക്യാപ്സുലേഷനുള്ള പാത ഉപയോഗയോഗ്യമായ വലുപ്പം കുറയ്ക്കുന്നു, ഒരു ടണലിൽ വിജയിക്കുന്ന കൈമാറ്റം മറ്റേതിൽ ചെറുത് പൊട്ടുന്ന അതേ വലുപ്പത്തിൽ നിലയ്ക്കുന്നു.

ഒരു സമയത്ത് ഒരു പാത മാത്രം താരതമ്യം ചെയ്യുക

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

ആവർത്തിച്ചുള്ള ping അല്ല, യഥാർത്ഥ ആപ്ലിക്കേഷൻ താരതമ്യം ചെയ്യുക. തകരാർ ഒരു പ്രത്യേക അടുത്ത ഹോപ്പിനെയോ പാക്കറ്റ് വലുപ്പത്തെയോ വീണ്ടും കണക്ട് ചെയ്തതിന് ശേഷമുള്ള മാറ്റത്തെയോ പിന്തുടരുന്നുവെന്ന് രേഖപ്പെടുത്തുക, കാരണം ഈ മൂന്ന് മാതൃകകൾ വ്യത്യസ്ത അറ്റകുറ്റപ്പണികളിലേക്ക് വിരൽ ചൂണ്ടുന്നു.

അവസാനമായി, പാതകൾ എന്തുകൊണ്ട് തുല്യമായി കണക്കാക്കുന്നു, തകരാർ എങ്ങനെ അവയിലൊന്ന് സേവനത്തിൽ നിന്ന് നീക്കണം എന്നിവ എഴുതുക. പാതകൾ യഥാർത്ഥത്തിൽ പരസ്പരം മാറ്റാവുന്നത് ആയിരിക്കുമ്പോൾ മാത്രമേ മൾട്ടിപാത്ത് സുരക്ഷിതമാകൂ, അത് അനുമാനിക്കേണ്ടതല്ല, പരിശോധിക്കേണ്ട ഡിസൈൻ പ്രസ്താവനയാണ്.