VPN കണക്ട് ചെയ്തു എന്ന് പറയുന്നു, കോഴ്സ് ലക്ഷ്യം ping-ന് മറുപടി നൽകുന്നു, എന്നിട്ടും ലാബ് ടൂൾ പിശകോടെ പുറത്തുപോകുന്നു. പരിശീലന പരിതസ്ഥിതികളിൽ ഈ സംയോജനം സാധാരണമാണ്, കാരണം ടണലും പിന്തുണയുള്ള റൺടൈമും രണ്ട് വ്യത്യസ്ത ആവശ്യകതകളാണ്. ഒന്ന് പാക്കറ്റ് പാത തെളിയിക്കുന്നു; മറ്റൊന്ന് ഈ മെഷീനിൽ പ്രോഗ്രാം ഒട്ടും പ്രവർത്തിക്കാമോ എന്ന് തെളിയിക്കുന്നു. ഈ പരാജയത്തെ VPN പ്രശ്നമായി കണ്ടാൽ, ഒരിക്കലും തെറ്റായിരുന്നിട്ടില്ലാത്ത നെറ്റ്വർക്ക് ക്രമീകരണങ്ങൾ മാറ്റാൻ നിങ്ങൾ പോകും.

കണക്ട് സൂചകം യഥാർത്ഥത്തിൽ എന്താണ് തെളിയിക്കുന്നത്

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

രണ്ടിൽ ഏതാണ് നിങ്ങൾ യഥാർത്ഥത്തിൽ പരിശോധിച്ചതെന്ന് എഴുതിവയ്ക്കുക, കാരണം കണക്ട് ബാഡ്ജിനെ രണ്ടിനും ഉള്ള തെളിവായി തെറ്റിദ്ധരിക്കാൻ എളുപ്പമാണ്.

ആദ്യം കോഴ്സിന്റെ രേഖപ്പെടുത്തിയ പാത പരിശോധിക്കുക

അഭ്യാസം പ്രവർത്തിപ്പിക്കുന്ന അതേ മെഷീനിൽ നിന്നോ വർക്ക്സ്പേസിൽ നിന്നോ അധ്യാപകൻ പ്രസിദ്ധീകരിച്ച പരിശോധന ഉപയോഗിക്കുക. വ്യത്യസ്ത പരിതസ്ഥിതി പരീക്ഷിച്ച് അതിനെ തുല്യമെന്ന് വിളിക്കുന്നത് ഇത് ഒഴിവാക്കുന്നു.

ip route get 10.50.20.15
nc -vz 10.50.20.15 8080

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

പിന്നെ ടൂൾ പിന്തുണാ മാട്രിക്സുമായി ഒത്തുനോക്കുക

പാത തെളിഞ്ഞാൽ, അഭ്യാസം യഥാർത്ഥത്തിൽ പ്രവർത്തിപ്പിക്കുന്ന പ്രോഗ്രാം പരിശോധിക്കുക. ആർക്കിടെക്ചറും ലൈബ്രറിയും തമ്മിലുള്ള പൊരുത്തക്കേടുകൾ ഉച്ചത്തിൽ പരാജയപ്പെടുന്നു, അവയെ ടൈംഔട്ടായി തെറ്റായി വായിക്കാൻ എളുപ്പമാണ്.

uname -m
file ./lab-tool
ldd ./lab-tool

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

ഉടമയ്ക്ക് രണ്ട് വേർതിരിച്ച കണ്ടെത്തലുകൾ നൽകുക

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

ഒരു കാരണം മാത്രമാണെങ്കിലും ടിക്കറ്റിൽ രണ്ട് കണ്ടെത്തലുകളും രേഖപ്പെടുത്തുക. അപ്പോൾ അടുത്ത ശ്രമം ഊഹത്തിൽ നിന്നല്ല, തെളിവിൽ നിന്ന് ആരംഭിക്കും.

അനുബന്ധ ലേഖനങ്ങൾ