നിങ്ങൾ ss -lntup Access Server ഹോസ്റ്റിൽ പ്രവർത്തിപ്പിക്കുന്നു, പ്രതീക്ഷിച്ചതിന്റെ ഇരട്ടി നീളമുള്ള പട്ടിക ലഭിക്കുന്നു. പകുതി എൻട്രികൾ സെറ്റപ്പ് സമയത്ത് ആരും പരാമർശിക്കാത്ത ഡീമൺ രൂപത്തിലുള്ള പോർട്ടുകളാണ്. പ്രതികരണം 443 അല്ലെങ്കിൽ 1194 അല്ലാത്ത എല്ലാം അടയ്ക്കുക എന്നതാണ്, അങ്ങനെയാണ് ആളുകൾ സ്വന്തം ക്ലയന്റ് പോർട്ടൽ തകർക്കുന്നത്.

Access Server ഒരു ശ്രോതാവല്ല. ഇത് ഒരു VPN സേവനം, വെബ് സേവനം, ക്ലസ്റ്റർ പങ്കാളി എന്നിവയാണ്, നിങ്ങൾ എത്ര TCP ഡീമണുകൾ കോൺഫിഗർ ചെയ്തു എന്നതിനെ ആശ്രയിച്ച് അധിക ഡീമൺ-നിർദ്ദിഷ്ട പോർട്ടുകളും ഫയർവാൾ റീഡയറക്ഷനുകളും ഇത് സൃഷ്ടിച്ചേക്കാം.

പട്ടിക ക്രമത്തിൽ പരിശോധിക്കുക: സോക്കറ്റുകൾ വായിക്കുക, പരിചിതമായവ മാപ്പ് ചെയ്യുക, ബാക്കിയുള്ളവ ഉടമയും ബൈൻഡും അനുസരിച്ച് വർഗ്ഗീകരിക്കുക, തുടർന്ന് അവ യഥാർത്ഥത്തിൽ എന്താണ് പ്രസിദ്ധീകരിക്കുന്നതെന്ന് പരിശോധിക്കുക.

ഒരു വായന-മാത്ര കമാൻഡിൽ തുടങ്ങുക

sudo ss -lntup കേൾക്കുന്ന ഓരോ സോക്കറ്റിനും ട്രാൻസ്പോർട്ട്, പ്രാദേശിക വിലാസം, പോർട്ട്, ഉടമ പ്രോസസ്സ് എന്നിവ നൽകുന്നു. ഫ്ലാഗുകൾ പ്രധാനമാണ്: -l കേൾക്കൽ, -n സംഖ്യാപരം, -t TCP, -u UDP, -p പ്രോസസ്സ്. root ഇല്ലാതെ സോക്കറ്റുകൾ ലഭിക്കും, പ്രോസസ്സ് നാമങ്ങൾ ലഭിക്കില്ല, വർഗ്ഗീകരണത്തിന് കൃത്യമായി ആ കോളം വേണം.

അഭിപ്രായം രൂപപ്പെടുത്തുന്നതിന് മുൻപ് ഓരോ വരിക്കും നാല് ഫീൽഡുകൾ രേഖപ്പെടുത്തുക: പ്രോട്ടോക്കോൾ, ബൈൻഡ് വിലാസം, പോർട്ട്, കമാൻഡ്. Access Server പതിപ്പും കോൺഫിഗർ ചെയ്ത ഡീമൺ എണ്ണവും ആ പട്ടികയ്ക്കൊപ്പം സൂക്ഷിക്കുക, രണ്ടും പ്രതീക്ഷ മാറ്റുന്നു.

ഒരുപോലെ കാണുന്ന രണ്ട് വരികൾ ഒരുപോലെയല്ല. ഒരേ നമ്പറിലെ TCP, UDP വെവ്വേറെ എക്സ്പോഷറുള്ള വെവ്വേറെ സോക്കറ്റുകളാണ്, കൂടാതെ 0.0.0.0 ഉം :: ഉം വെവ്വേറെ വിലാസ കുടുംബങ്ങൾക്കുള്ള വെവ്വേറെ ബൈൻഡുകളാണ്. 127.0.0.1 എന്നതിലേക്ക് മാത്രം ബന്ധിപ്പിച്ച സേവനം മറ്റൊരു ഹോസ്റ്റിൽ നിന്ന് നേരിട്ട് എത്താൻ കഴിയില്ല, എങ്കിലും പ്രാദേശിക റീഡയറക്ട് അത് ഇപ്പോഴും പ്രസിദ്ധീകരിച്ചേക്കാം.

നിങ്ങൾ തിരിച്ചറിയേണ്ട ശ്രോതാക്കൾ

ഈ സ്ഥിരസ്ഥിതികൾ മിക്ക വിന്യാസങ്ങളെയും ഉൾക്കൊള്ളുന്നു, താരതമ്യത്തിന് അടിസ്ഥാനം നൽകുന്നു. ഇവ സ്ഥിരസ്ഥിതികളാണ്, പൂർണ്ണ അനുമതി പട്ടികയല്ല.

SocketRole to confirm
UDP 1194OpenVPN UDP tunnel listener
TCP 443OpenVPN TCP listener, optionally forwarded to the web service
TCP 943Admin and client web interfaces, and cluster control in Access Server 3.0 and later
TCP 945Cluster control in older configurations that predate the move to 943

അതിനപ്പുറമുള്ള എല്ലാത്തിനും വിശദീകരണം വേണം, ഊഹമല്ല. ഉൽപ്പന്നം സ്വയം ഇൻസ്റ്റാൾ ചെയ്യുന്ന ഘടകങ്ങളുടെ പ്രാദേശിക-മാത്ര ശ്രോതാക്കളെ പലപ്പോഴും കാണാം. ഓർമ്മയിലുള്ള പോർട്ട് നമ്പറിന് പകരം PID-യും സേവന കോൺഫിഗറേഷനും ഉപയോഗിച്ച് അവ സ്ഥിരീകരിക്കുക, അപരിചിതമെന്ന കാരണത്താൽ മാത്രം അജ്ഞാത പോർട്ടിനെ ശത്രുവായി കാണരുത്.

പരിചിത ജോടിക്ക് പുറത്തുള്ള സോക്കറ്റും സ്വയമേവ അവശിഷ്ടമല്ല. ഒന്നിലധികം TCP ഡീമണുകൾ കോൺഫിഗർ ചെയ്താൽ, Access Server ഓരോ ഡീമണിനും ശ്രോതാക്കൾ സൃഷ്ടിച്ച് ട്രാഫിക് അവയിലേക്ക് റീഡയറക്ട് ചെയ്യുന്നു, അതിനാൽ അവയുടെ എണ്ണവും പോർട്ട് മൂല്യങ്ങളും ആ കോൺഫിഗറേഷനെ പിന്തുടരുന്നു.

എന്തെങ്കിലും അടയ്ക്കുന്നതിന് മുൻപ് വർഗ്ഗീകരിക്കുക

ഓരോ അനിശ്ചിത വരിക്കും ഈ ക്രമത്തിൽ മൂന്ന് ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുക.

  1. ഉടമയും ലക്ഷ്യവും. PID-യെ ഒരു യൂണിറ്റുമായോ പ്രോസസ്സുമായോ ചേർത്ത് ആ സേവനത്തിന്റെ കോൺഫിഗറേഷൻ വായിക്കുക. ഉടമയെ പേരിടാൻ കഴിയില്ലെങ്കിൽ, സോക്കറ്റിനെക്കുറിച്ച് എന്തെങ്കിലും തീരുമാനിക്കാൻ നിങ്ങൾ തയ്യാറല്ല.
  2. ബൈൻഡ് പരിധി. Loopback നാമസ്ഥലത്തിന് പ്രാദേശികമാണ്. വൈൽഡ്കാർഡ് ബൈൻഡ് റൂട്ടിംഗ്, ഹോസ്റ്റ് ഫിൽട്ടറിംഗ്, ഏതെങ്കിലും ക്ലൗഡ് തല നിയമങ്ങൾ അനുവദിച്ചാൽ മാത്രമേ എത്താൻ കഴിയൂ, അതിനാൽ ബൈൻഡ് വിലാസം ആവശ്യമാണ്, പക്ഷേ മതിയാകില്ല. IPv4, IPv6 എന്നിവ പ്രത്യേക തീരുമാനങ്ങളായി പരിശോധിക്കുക.
  3. പ്രസിദ്ധീകരിച്ച പാത. സേവന ഫോർവേഡിംഗ്, ഡീമൺ-നിർദ്ദിഷ്ട റീഡയറക്ടുകൾ, ബാഹ്യ പ്രോക്സി, ഫലപ്രദമായ ഫയർവാൾ നയം എന്നിവ തിരയുക. ആളുകൾ ഒഴിവാക്കുന്ന ഘട്ടം ഇതാണ്, നിരുപദ്രവകരമെന്ന് തോന്നുന്ന ബാക്ക്എൻഡ് പോർട്ടിനെ എത്താവുന്ന അഡ്മിനിസ്ട്രേറ്റീവ് പാതയാക്കി മാറ്റുന്നതും ഇതാണ്.

അതേ ചോദ്യം ഹോസ്റ്റിന് പുറത്തുനിന്ന് വ്യത്യസ്തമായി വായിക്കപ്പെടുന്നു. ഹോസ്റ്റ് ഫയർവാൾ നിയമമില്ലാത്ത പോർട്ട് ക്ലൗഡ് സുരക്ഷാ ഗ്രൂപ്പ് ഇപ്പോഴും അടച്ചേക്കാം, അനുവദിക്കുന്ന ഹോസ്റ്റ് നിയമമുള്ള പോർട്ട് എത്താൻ കഴിയാത്തതാകാം, കാരണം അങ്ങോട്ട് ഒന്നും റൂട്ട് ചെയ്യുന്നില്ല. പട്ടികയുടെ നിഗമനം എഴുതുന്നതിന് മുൻപ് രണ്ടറ്റവും നോക്കുക.

പ്രസിദ്ധീകരിച്ച പാത സോക്കറ്റ് പട്ടികയിൽ നിന്ന് വ്യത്യസ്തമാകുന്നിടം

Access Server-ന്റെ സ്വന്തം ഡോക്യുമെന്റേഷൻ ഏറ്റവും കൂടുതൽ ആശയക്കുഴപ്പമുണ്ടാക്കുന്ന കേസ് ഉൾക്കൊള്ളുന്നു: നിരവധി TCP ഡീമണുകൾ പ്രവർത്തിക്കുമ്പോൾ, മുൻവശത്തെ പോർട്ട് ഡീമൺ-നിർദ്ദിഷ്ട പോർട്ടുകളിലേക്ക് ഫോർവേഡ് ചെയ്യുന്നു, ദൃശ്യമായ ക്രമീകരണം സോക്കറ്റ് പട്ടികയുമായി പൊരുത്തപ്പെടുന്നത് നിർത്തുന്നു. വെബ് ഇന്റർഫേസ് ഫിൽട്ടറിംഗ് ട്യൂട്ടോറിയൽ ആ നിയമങ്ങളും, വ്യക്തമായ പോർട്ടിന് മാത്രം എഴുതിയ ഫിൽട്ടർ റീഡയറക്ട് ചെയ്ത പാത പൂർണ്ണമായി വിട്ടുപോകാനുള്ള കാരണവും വിശദീകരിക്കുന്നു.

ക്ലസ്റ്റർ നിയന്ത്രണം പതിപ്പ് പ്രധാനമാകുന്ന രണ്ടാമത്തെ സ്ഥലമാണ്. 3.0 മുതൽ ഇത് 943 പങ്കിടുന്നു; പഴയ ക്ലസ്റ്റർ കോൺഫിഗറേഷനുകൾ 945 ഉപയോഗിച്ചു. പതിപ്പ് പരിശോധിക്കാതെ അവയിലൊന്ന് തുറക്കുകയോ തടയുകയോ ചെയ്താൽ വൃത്തിയായി കാണപ്പെടുന്ന, പക്ഷേ തെറ്റായ പട്ടിക ഉണ്ടാകും.

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

ഏതെങ്കിലും മാറ്റത്തിന് ശേഷം സ്ഥിരീകരിക്കുക

പിന്തുണയുള്ള കോൺഫിഗറേഷൻ ഉടമയിലൂടെ ശ്രോതാ ക്രമീകരണങ്ങൾ മാറ്റുക, അത് ചെയ്യുമ്പോൾ റിക്കവറി കൺസോൾ തുറന്നിടുക. ദൂരെയുള്ള ഹോസ്റ്റിലെ വെബ് ഇന്റർഫേസിലേക്കുള്ള അഡ്മിനിസ്ട്രേറ്റീവ് പ്രവേശനം നഷ്ടപ്പെടുന്നത് നിങ്ങൾ ഇപ്പോൾ പ്രവർത്തനരഹിതമാക്കിയ VPN വഴി വീണ്ടെടുക്കാൻ കഴിയില്ല.

തുടർന്ന് ഒരു വിന്യാസത്തിന് സാധാരണ ആവശ്യമായ നാല് കാര്യങ്ങൾ സ്ഥിരീകരിക്കുക: VPN ക്ലയന്റ് കണക്റ്റ് ചെയ്യുന്നു, ക്ലയന്റ് പോർട്ടൽ ലോഡ് ചെയ്യുന്നു, അഡ്മിനിസ്ട്രേറ്റീവ് പ്രവേശനം പ്രവർത്തിക്കുന്നു, ഒന്നിലധികം നോഡുകൾ പ്രവർത്തിപ്പിക്കുകയാണെങ്കിൽ ക്ലസ്റ്റർ ആശയവിനിമയം ഇപ്പോഴും പ്രവർത്തിക്കുന്നു. VPN മാത്രമുള്ള പരിശോധന പോർട്ടൽ തകർന്നിരിക്കുമ്പോഴും സുഖമായി വിജയിക്കുന്നു.

ഓരോ സേവനത്തിനും അനുവദിച്ച പാത എഴുതി അവസാനിപ്പിക്കുക: ഏത് സോക്കറ്റ്, ഏത് ബൈൻഡ്, ഏത് ഫോർവേഡിംഗ് നിയമം, ഏത് നെറ്റ്വർക്ക് നിയന്ത്രണം. ആ രേഖയാണ് ഉപയോഗപ്രദമായ സുരക്ഷാ ഔട്ട്പുട്ട്. കുറഞ്ഞ സോക്കറ്റ് എണ്ണമല്ല, ആരും തിരിച്ചറിയൽ പൂർത്തിയാക്കാത്ത ശ്രോതാക്കളെ അടയ്ക്കുന്ന കൂട്ട റീസെറ്റും അല്ല.

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