Ping തെളിവല്ല: രണ്ട് സൈറ്റുകൾക്കിടയിലുള്ള പാത പരിശോധിക്കുക

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

സേവനം ആവശ്യമുള്ള ക്ലയന്റിൽ നിന്ന് ആരംഭിക്കുക

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

രേഖപ്പെടുത്തിയ ഹോസ്റ്റ് പേര് പരീക്ഷിക്കുക, സേവനം അനുവദിക്കുന്നിടത്ത് അതേ പോർട്ടിന്റെ നേരിട്ടുള്ള വിലാസ പരിശോധനയും. പരാജയപ്പെട്ട പേര് തിരയലും എത്തിച്ചേരാനാവാത്ത പരിഹരിച്ച വിലാസവും നിങ്ങളെ വ്യത്യസ്ത പാതകളിലേക്ക് നയിക്കുന്നു. ഹോസ്റ്റ് പേരിന് പകരം IP നൽകിയാൽ, പ്രവർത്തിക്കാൻ HTTPS ഐഡന്റിറ്റി പരിശോധന ഓഫ് ചെയ്യരുത്; സർട്ടിഫിക്കറ്റ് മുന്നറിയിപ്പ് വിവരമാണ്, തടസ്സമല്ല.

ഓരോ അരികിലും പാത നടക്കുക

ക്ലയന്റ് തിരഞ്ഞെടുക്കുന്ന റൂട്ട് വായിക്കുക, തുടർന്ന് ഗേറ്റ്വേ ആ ലക്ഷ്യത്തിന് തിരഞ്ഞെടുക്കുന്ന റൂട്ട്, തുടർന്ന് ഓരോ അരികിലുമുള്ള കൗണ്ടറുകൾ അല്ലെങ്കിൽ പരിമിതമായ ക്യാപ്ചർ. നിങ്ങൾ രണ്ട് വസ്തുതകൾ തേടുന്നു: അഭ്യർത്ഥന വിദൂര LAN-ൽ എത്തിയോ, മറുപടി തിരിച്ചുവന്നോ. ഇന്റർഫേസ് കൗണ്ടറുകൾ മറ്റെല്ലാ ഫ്ലോകളും ഉൾക്കൊള്ളുന്നു, അതിനാൽ ഗ്രാഫിന്റെ ആകൃതിക്ക് പകരം കൃത്യമായ സമയമുദ്രയും വിലാസ ജോടിയും ഉപയോഗിച്ച് ബന്ധിപ്പിക്കുക. തെറ്റായ അരികിൽ എടുത്ത ക്യാപ്ചർ ഒന്നും ഇല്ലാത്തതിനേക്കാൾ മോശമാണ്, കാരണം അത് തെളിവുപോലെ തോന്നുന്നു.

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

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

ആപ്പ് ഉപയോഗിക്കുന്ന പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുക

ICMP ദുർബലമായ പരിശോധനയാണ്. അത് ഫിൽട്ടർ ചെയ്യാം, നിരക്ക് പരിമിതപ്പെടുത്താം, അല്ലെങ്കിൽ സേവനത്തിൽ നിന്ന് വ്യത്യസ്തമായ നയം കൊണ്ട് കൈകാര്യം ചെയ്യാം, ഇത് അതിന്റെ വിജയവും പരാജയവും അവ്യക്തമാക്കുന്നു. യഥാർത്ഥ പോർട്ടും കഴിയുമെങ്കിൽ യഥാർത്ഥ പ്രോട്ടോക്കോൾ ഹാൻഡ്ഷേക്കും പരിശോധിക്കുക.

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

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

പരാജയപ്പെടുന്ന അവസ്ഥ പുനഃസൃഷ്ടിക്കുക

വലിയ കൈമാറ്റങ്ങളിൽ മാത്രം കാണുന്ന പരാജയങ്ങൾ വലുപ്പ പ്രശ്നമാണ്, കണക്റ്റിവിറ്റിയല്ല. don't-fragment ബിറ്റ് സജ്ജമാക്കിയ വലിയ പാക്കറ്റ് അയച്ച് അത് എവിടെ നിൽക്കുന്നുവെന്ന് നോക്കുക. ചെറിയ അഭ്യർത്ഥന വിജയിക്കുകയും വലുത് തൂങ്ങുകയും ചെയ്താൽ, ടണലിന്റെ MTU-വും ഗേറ്റ്വേകളിലെ MSS കൈകാര്യം ചെയ്യലും അടുത്ത സംശയിക്കുന്നവരാണ്.

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

ഒരു സബ്നെറ്റ് മാത്രം പരാജയപ്പെട്ടാൽ, ട്രാഫിക് സെലക്ടറുകൾ, റൂട്ട് പ്രഖ്യാപനങ്ങൾ, ആ സബ്നെറ്റിന്റെ തിരിച്ചുവരവ് ഗേറ്റ്വേ എന്നിവ നോക്കുക. ഹോസ്റ്റ് പേര് മാത്രം പരാജയപ്പെട്ടാൽ, DNS പിന്തുടരുക, ക്ലയന്റ് ഏത് റിസോൾവർ ഉപയോഗിച്ചു, ആ സൈറ്റിൽ നിന്ന് വിദൂര കാഴ്ച ദൃശ്യമാണോ എന്നതും ഉൾപ്പെടെ. മൂന്ന് വ്യത്യസ്ത പരാജയങ്ങൾ, മൂന്ന് വ്യത്യസ്ത പരിഹാരങ്ങൾ, പിംഗ് പരിശോധന അവയിലൊന്നും വേർതിരിക്കുന്നില്ല.

പരിഹാരത്തിന് ശേഷം അതേ പരിശോധന ആവർത്തിക്കുക

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

നാല് അടിസ്ഥാന മൂല്യങ്ങളും ഫലവും രേഖപ്പെടുത്തുക. അതേ ലക്ഷണത്തിന്റെ അടുത്ത റിപ്പോർട്ടിന് അപ്പോൾ പിംഗിന് പകരം തെളിവിൽ നിന്ന് ആരംഭിക്കാം.