VPN പോർട്ട് നിശ്ശബ്ദമാണോ? ശ്രോതാവ്, ബൈൻഡ് വിലാസം അല്ലെങ്കിൽ ഹോസ്റ്റ് ഫയർവാൾ
നിർത്തിയ സേവനത്തിനും ഫയർവാളിന്റെ ഡ്രോപ്പിനും വ്യത്യസ്ത അറ്റകുറ്റപ്പണി വേണം. ആദ്യം ലോക്കൽ സോക്കറ്റ് പരിശോധിക്കുക, പിന്നീട് ഒരു അനുവദനീയമായ ബാഹ്യശ്രമം ലോഗുമായി ചേർത്തു വായിക്കുക.
VPN അതിന്റെ പോർട്ടിൽ ഒന്നും ഉത്തരം നൽകുന്നില്ല, രണ്ടു സാധ്യമായ കാരണങ്ങൾക്ക് വിപരീത അറ്റകുറ്റപ്പണി വേണം: ഒന്നുകിൽ ഒരു പ്രോസസും സോക്കറ്റ് തുറന്നിട്ടില്ല, അല്ലെങ്കിൽ സോക്കറ്റ് നിലനിൽക്കുന്നു, യന്ത്രങ്ങൾക്കിടയിൽ എന്തോ പാക്കറ്റുകൾ തടയുന്നു. ഒരു കമാൻഡ് ആ ചോദ്യത്തിന്റെ ആദ്യ പകുതി തീർപ്പാക്കുന്നു, അതുകൊണ്ടാണ് അത് ഏതെങ്കിലും ഫയർവാൾ നിയമം തൊടുന്നതിനു മുൻപ് വരുന്നത്. താഴെയുള്ള ക്രമം മറ്റൊരു ഊഹം ചേർക്കുന്നതിനു പകരം ഓരോ ഘട്ടത്തിലും ഒരു വിശദീകരണം നീക്കുന്നു. ഈ രണ്ടിനുമിടയിൽ ഊഹിക്കുന്നതാണ് പത്തു മിനിറ്റ് നീളുന്ന രോഗനിർണയത്തെ ഒരു വൈകുന്നേരമാക്കി മാറ്റുന്നത്.
നിങ്ങൾക്ക് സെർവറിൽ ലോഗിൻ ചെയ്യാൻ കഴിയും, ക്ലയന്റ് സ്കാനർ അല്ല, യഥാർത്ഥ പ്രൊഫൈൽ ആണ് എന്ന് കരുതുക. രണ്ടു ധാരണകളും പ്രധാനമാണ്, കാരണം പൊതുവായ ഒരു പ്രോബിന് പ്രോട്ടോക്കോളിന് സവിശേഷമായ ചോദ്യത്തിന് ഉത്തരം നൽകാനാവില്ല.
സോക്കറ്റ് ഉണ്ടോ എന്നു തന്നെ
സേവനം തന്നെക്കുറിച്ച് പറയുന്നതിൽ നിന്ന് തുടങ്ങുക: അത് ഉയർന്നുവന്നോ, കൂടുതൽ ഉപകാരപ്രദമായി, അതിന്റെ ആദ്യ സ്റ്റാർട്ടപ്പ് പിശക് എന്തായിരുന്നു. പാഴ്സ് പരാജയം, കാണാത്ത കീ അല്ലെങ്കിൽ ബൈൻഡ് പിശക് എന്നിവ ശ്രോതാവ് ഉണ്ടാകുന്നതു തന്നെ തടയുന്നു, പ്രോസസ് എത്ര നിശ്ശബ്ദമായി പുറത്തുപോകാമെന്നു പറയാനില്ല, സ്റ്റാറ്റസ് വരി അവ്യക്തമായി വായിക്കപ്പെടും. സജീവമാണെന്ന് റിപ്പോർട്ട് ചെയ്യുന്ന യൂണിറ്റ് അത്രയും മാത്രം തെളിവല്ല, കാരണം പ്രധാന പ്രോസസ് ജീവിച്ചിരിക്കുമ്പോഴും പോർട്ട് ബൈൻഡ് ചെയ്യേണ്ടിയിരുന്ന ഘടകം നേരത്തെ കീഴടങ്ങിയിരിക്കാം.
systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp
സോക്കറ്റ് പട്ടികയാണ് ബാക്കിയുള്ള രോഗനിർണയം നിൽക്കുന്ന വസ്തുത. പോർട്ട് മാത്രമല്ല, ലോക്കൽ വിലാസത്തിന്റെ കോളം വായിക്കുക, കാരണം ആ കോളത്തിലാണ് ലൂപ്പ്ബാക്ക് ബൈൻഡും തെറ്റായ ഇന്റർഫേസിലെ ബൈൻഡും കാണുന്നത്. 127.0.0.1-ൽ നിലനിൽക്കുന്ന ശ്രോതാവ് തികച്ചും പ്രവർത്തിക്കുന്നു, എന്നിട്ടും നിങ്ങളുടെ ലാപ്ടോപ്പിന് അദൃശ്യമാണ്.
ഏത് വിലാസത്തിലും ഏത് കുടുംബത്തിലുമാണ് സോക്കറ്റ് ഉത്തരം നൽകുന്നത്
രണ്ടു തെറ്റുകൾ ക്ലയന്റിൽ നിന്ന് ഒരുപോലെ തോന്നുന്നു, "എത്തിപ്പെടാനാവില്ല" എന്ന റിപ്പോർട്ടുകളിൽ ഏറെയും അവയാണ് വിശദീകരിക്കുന്നത്. ലൂപ്പ്ബാക്ക് വിലാസത്തിൽ ബൈൻഡ് ചെയ്ത സെർവർ മറ്റൊരു യന്ത്രത്തിൽ നിന്ന് ട്രാഫിക് സ്വീകരിക്കുന്നില്ല, IPv4 വിലാസത്തിൽ മാത്രം ബൈൻഡ് ചെയ്ത സെർവർ അതേ ഹോസ്റ്റിന്റെ IPv6 വിലാസം ഡയൽ ചെയ്യുന്ന ക്ലയന്റിന് ഒരിക്കലും ഉത്തരം നൽകുന്നുമില്ല. നയത്തെക്കുറിച്ച് എന്തെങ്കിലും അനുമാനിക്കുന്നതിനു മുൻപ് സോക്കറ്റ് പട്ടികയിലെ വിലാസവും ക്ലയന്റ് യഥാർത്ഥത്തിൽ ഡയൽ ചെയ്യുന്ന വിലാസവും അക്ഷരം തോറും താരതമ്യം ചെയ്യുക.
പട്ടിക ഒരു പോർട്ടിൽ ഒതുക്കുന്നത് ഹോസ്റ്റ് പല സേവനങ്ങൾ ഓടിക്കുമ്പോഴും വായനാക്ഷമമായി നിർത്തുന്നു. sport ഫിൽട്ടർ നിങ്ങൾ പരിശോധിക്കുന്ന ട്രാൻസ്പോർട്ടിനൊപ്പം പോർട്ട് എടുക്കുന്നു:
ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'
പ്രോട്ടോക്കോൾ കോളം മുഴുവൻ ഉത്തരവും മാറ്റുന്നു
സോക്കറ്റ് പട്ടിക പോർട്ടിനൊപ്പം പ്രോട്ടോക്കോൾ അനുസരിച്ചും സൂചികയാക്കുന്നു, അവ രണ്ടു സ്വതന്ത്ര എൻട്രികളാണ്. 1194-ൽ TCP-ക്ക് ഉത്തരം നൽകുന്ന സേവനം UDP 1194-ൽ എന്തെങ്കിലും കേൾക്കുന്നുണ്ടോ എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, ക്ലയന്റ് എപ്പോഴും അവയിലൊന്ന് മാത്രമേ ഉപയോഗിക്കൂ. സെർവർ കോൺഫിഗറേഷൻ ഏത് ട്രാൻസ്പോർട്ട് തിരഞ്ഞെടുക്കുന്നു, ക്ലയന്റ് പ്രൊഫൈൽ ഏതാണ് അയക്കുന്നത് എന്ന് ഉറപ്പാക്കി, പിന്നീട് അതേ വരി തിരയുക.
UDP-ക്ക് രണ്ടാമതൊരു മടക്കുണ്ട്: പ്രാമാണീകരിക്കാത്ത പ്രോബ് സേവനം ഉത്തരം നൽകേണ്ടിയിരിക്കുന്ന ഒരു പിശകല്ല. പോർട്ട് നിശ്ശബ്ദമാണെന്ന് റിപ്പോർട്ട് ചെയ്യുന്ന സ്കാനിംഗ് സേവനത്തിന്റെ ലഭ്യതയല്ല, അതിന്റെ സംയമനമാണ് അളന്നത്, അതിനാൽ യഥാർത്ഥ ക്ലയന്റും പ്രൊഫൈലും ഉപയോഗിച്ച് പരിശോധിക്കുക.
ഒരു ശ്രമം, നോക്കാൻ മൂന്നിടം
അനുവദിച്ച ക്ലയന്റിൽ നിന്ന് കൃത്യമായി ഒരു ശ്രമം നടത്തി സമയം സെക്കൻഡ് വരെ എഴുതിവയ്ക്കുക. പിന്നീട് ആ ഇടവേളയ്ക്കായി മൂന്നു സ്രോതസ്സുകൾ വായിക്കുക: ദാതാവിന്റെ നെറ്റ്വർക്ക് നിയമമോ കൺസോളോ, ഹോസ്റ്റിന്റെ ഫയർവാൾ കൗണ്ടറുകളോ ലോഗോ, സേവനത്തിന്റെ സ്വന്തം ലോഗും. ഒരിക്കൽ ഇതു ചെയ്യുന്നതാണ് മൂന്നു വിവരണങ്ങളെ താരതമ്യപ്പെടുത്താവുന്നതാക്കുന്നത്, ആരും സമയമുദ്ര രേഖപ്പെടുത്താത്ത ഒരു ശ്രമം ആവർത്തിക്കുന്നതിനേക്കാൾ ചെലവു കുറവുമാണ്.
രണ്ടു ഫലങ്ങളും വിപരീത ദിശകളിലേക്കാണ് വിരൽ ചൂണ്ടുന്നത്. ഒരു പാക്കറ്റും ഹോസ്റ്റിൽ എത്തിയിട്ടില്ലെങ്കിൽ, പാത അത് ഉപേക്ഷിക്കുകയാണ്, ശ്രോതാവ് അപ്രസക്തമാണ്. പാക്കറ്റ് സോക്കറ്റിൽ എത്തിയിട്ട് സേവനം അത് നിരസിച്ചെങ്കിൽ, പാത കുഴപ്പമില്ല, ഉത്തരം പ്രോട്ടോക്കോളിലും ക്രിപ്റ്റോഗ്രഫിയിലും ക്രെഡൻഷ്യലുകളിലുമാണ്. ഇതിനകം ഒരു കണക്ഷൻ സ്വീകരിച്ച സേവനത്തിനായി പോർട്ട് തുറക്കുന്നത് അടുത്ത രോഗനിർണയം എളുപ്പമല്ല, ബുദ്ധിമുട്ടാക്കുന്നു.
നിയമം മാറ്റുന്നതിനു മുൻപ് ഘട്ടത്തിന് പേരിടുക
ആരംഭിക്കുന്ന ചർച്ചയും പരാജയപ്പെടുന്ന പ്രാമാണീകരണവും ഒരു തകരാറാണ്, ഫോർവേഡിംഗ് നിലയ്ക്കുമ്പോൾ സ്ഥാപിക്കുന്ന ടണൽ തികച്ചും മറ്റൊന്നാണ്. ഘട്ടത്തിന് ആദ്യം പേരിടുന്നത് അറ്റകുറ്റപ്പണിയെ ഇടുങ്ങിയതായി നിർത്തുന്നു: ക്രെഡൻഷ്യലിന്റെ പ്രശ്നം ഫയർവാൾ നിയമം കൊണ്ട് തീരില്ല, ഡാറ്റാ പാതയുടെ പ്രശ്നം റീസ്റ്റാർട്ട് കൊണ്ട് തീരില്ല.
ചോദ്യത്തിന് ഉത്തരം നൽകുന്ന ഏറ്റവും ഇടുങ്ങിയ രോഗനിർണയം ഉപയോഗിക്കുക. അഡ്മിനിസ്ട്രേറ്ററുടെ നിയന്ത്രണത്തിൽ ഒരു പോർട്ടിൽ താൽക്കാലിക പാക്കറ്റ് നിരീക്ഷണം ന്യായമായ ഉപകരണമാണ്; മുഴുവൻ ഫയർവാളും ഓഫാക്കുന്നത് അല്ല, കാരണം ഫലം ആരോപിക്കാൻ കഴിയാത്തതാകും. ss-ന്റെ ഡോക്യുമെന്റേഷൻ മുകളിൽ ഉപയോഗിച്ച ഫിൽട്ടറുകൾ ഉൾക്കൊള്ളുന്നു, ഏതെങ്കിലും ക്യാപ്ചറിനേക്കാൾ വിലകുറഞ്ഞ ആദ്യ ചുവടാണത്. രണ്ടു ശാഖകളിൽ ഏതാണ് തെളിയിച്ചതെന്ന് രേഖപ്പെടുത്തുക, അടുത്ത സംഭവം ഒരു അറിയപ്പെടുന്ന ഉത്തരത്തിൽ നിന്ന് തുടങ്ങും.