ഹോസ്റ്റ് ഔട്ട്ബൗണ്ട് VPN ഓടിക്കുമ്പോൾ ലോക്കൽ SSH നിലനിർത്തുക

ഹോസ്റ്റ് ചെയ്യുന്ന ആപ്ലിക്കേഷനുവേണ്ടി ഒരു ചെറിയ Linux സെർവർ ഔട്ട്ബൗണ്ട് VPN ഓടിക്കുന്നു, അഡ്മിനിസ്ട്രേറ്റർക്ക് ഇപ്പോഴും അടുത്തുള്ള മേശയിൽ നിന്ന് SSH വഴി അതിൽ എത്തണം. ഇത് ന്യായമായ ആവശ്യമാണ്, സാധാരണയായി പോർട്ട് ഫോർവേഡിംഗോ പ്രൊവൈഡർ വിലാസമോ ടണലിൽ ഒരു ദ്വാരമോ ആവശ്യമില്ല. ആവശ്യമുള്ളത് ബോധപൂർവ്വം രൂപകൽപ്പന ചെയ്ത ഒരു മാനേജ്മെന്റ് പാതയാണ്, VPN ക്ലയന്റ് റൂട്ടിംഗ് ടേബിളിൽ ചെയ്തതിൽ നിന്ന് പാരമ്പര്യമായി ലഭിച്ചതല്ല.

താഴെയുള്ള ഘട്ടങ്ങൾ അഡ്മിനിസ്ട്രേറ്റർ അതേ LAN-ൽ ആണെന്ന് അനുമാനിക്കുന്നു.റിമോട്ട് അഡ്മിനിസ്ട്രേഷൻ വേറെ ഉത്തരമുള്ള വേറെ പ്രശ്നമാണ്.

അഡ്മിനിസ്ട്രേറ്റർമാർ ഉപയോഗിക്കുന്ന വിലാസത്തിലേക്ക് SSH ബൈൻഡ് ചെയ്യുക

ലിസണറിൽ നിന്ന് തുടങ്ങുക.ss -ltnp | grep :22 sshd എന്തിനോട് ബന്ധിപ്പിച്ചിരിക്കുന്നു എന്ന് കാണിക്കുന്നു, 0.0.0.0-ലെ ലിസണർ ടണൽ ഉൾപ്പെടെ ഓരോ ഇന്റർഫേസിൽ നിന്നും കണക്ഷനുകൾ സ്വീകരിക്കുന്നു. LAN വിലാസത്തിൽ ബൈൻഡ് ചെയ്യുന്നത് കൂടുതൽ ഇടുങ്ങിയതാണ്, ഉദ്ദേശ്യം ദൃശ്യമാക്കുന്നു:ListenAddress 192.168.10.20 എന്ന ഫയലിൽ sshd_config, തുടർന്ന് കോൺഫിഗറേഷൻ പരിശോധനയും റീലോഡും. ആ വിലാസത്തിലെ അക്ഷരത്തെറ്റ് വൈൽഡ്കാർഡിനേക്കാൾ ദൃശ്യമാണ്, കാരണം വിലാസം ഇല്ലാത്തപ്പോൾ sshd ആരംഭിക്കാൻ വിസമ്മതിക്കുന്നു.

ഹോസ്റ്റ് കീ പരിശോധനയും ഓരോ ഉപയോക്താവിന്റെയും ഓതന്റിക്കേഷനും ഉള്ളതുപോലെ തന്നെ നിലനിർത്തുക. “ഇത് ലോക്കൽ നെറ്റ്വർക്ക് മാത്രമാണ്” എന്നത് ഓതന്റിക്കേഷൻ രീതിയല്ല, റൂട്ട് ചെറുതായതിനാൽ കീ പരിശോധന ഒഴിവാക്കുന്ന മാനേജ്മെന്റ് ചാനൽ ദുരുപയോഗത്തിനായി കാത്തിരിക്കുന്ന ചാനലാണ്. DHCP റിസർവേഷനോ സ്റ്റാറ്റിക് വിലാസമോ ലക്ഷ്യത്തെ പ്രവചനീയമാക്കുന്നു, അതിനെ സെർവറിന്റെ പൊതു ഐഡന്റിറ്റിയാക്കാതെ.

LAN റൂട്ട് ടണലിന് പുറത്ത് നിലനിർത്തുക

192.168.10.0/24-ൽ വിലാസമുള്ള ഹോസ്റ്റിന് ആ പ്രിഫിക്സിന് ബന്ധിപ്പിച്ച റൂട്ട് ഉണ്ട്, അതേ ടേബിളിൽ കൂടുതൽ നിർദ്ദിഷ്ടമായ റൂട്ട് VPN-ന്റെ ഡിഫോൾട്ടിനെ തോൽപ്പിക്കുന്നു. അതുകൊണ്ടാണ് ടണൽ ഉയരുമ്പോൾ ലോക്കൽ SSH പലപ്പോഴും സ്വയം പ്രവർത്തിക്കുന്നത്. അനുമാനിക്കാതെ അത് പരിശോധിക്കുക:ip route get 192.168.10.50 കേർണൽ ഉപയോഗിക്കുന്ന ഇന്റർഫേസും സ്രോതസ്സ് വിലാസവും പേരെടുത്ത് പറയുന്നു, ഉത്തരം ടണലല്ല, LAN ഉപകരണമായിരിക്കണം. അഡ്മിനിസ്ട്രേറ്ററുടെ മെഷീനിൽ നിന്നും പരിശോധന ആവർത്തിക്കുക, കാരണം പാക്കറ്റുകൾ എത്തുമോയെന്ന് അതിന്റെ സ്വന്തം ടേബിളാണ് തീരുമാനിക്കുന്നത്. ഒരേ വയറിലുള്ള രണ്ട് ഹോസ്റ്റുകൾ ഏത് ദിശ എത്താനാകുമെന്നതിൽ യോജിക്കാതിരിക്കാം.

അനുമാനം രണ്ടിടത്ത് തകരുന്നു. നയാധിഷ്ഠിത റൂട്ടിംഗ് നിയമത്തിന് പ്രധാന ടേബിൾ നോക്കുന്നതിന് മുമ്പ് ഡിഫോൾട്ട് ടണലിലേക്ക് ചൂണ്ടുന്ന ടേബിളിലേക്ക് ട്രാഫിക് അയക്കാം. ലോക്ക്ഡൗൺ അല്ലെങ്കിൽ kill switch സവിശേഷതയുള്ള VPN ക്ലയന്റിന് ടണലിൽ പ്രവേശിക്കാത്ത ട്രാഫിക് തടയാനും കഴിയും, റൂട്ടിംഗ് ടേബിൾ എന്ത് പറഞ്ഞാലും.

റൂട്ട് ചെയ്ത മാനേജ്മെന്റ് VLAN-കളാണ് മറ്റൊരു കേസ്. അഡ്മിനിസ്ട്രേറ്റർ ലോക്കൽ റൗട്ടറിന് പിന്നിൽ 192.168.50.0/24-ൽ ഇരിക്കുന്നുവെങ്കിൽ, സെർവറിന് ആ പ്രിഫിക്സിന് 192.168.10.1 വഴി വ്യക്തമായ റൂട്ട് വേണം, ആ റൂട്ട് വീണ്ടും കണക്ട് ചെയ്യുന്നതിനെ അതിജീവിക്കണം. ഒഴിവാക്കൽ മാനേജ്മെന്റ് പ്രിഫിക്സിന് മാത്രമായി നിലനിർത്തുക; സ്വകാര്യ ശ്രേണികൾക്കുള്ള വിശാലമായ ഒഴിവാക്കൽ ടണലിന്റെ ഉദ്ദേശ്യം തകർക്കുന്നു.

ഫയർവാൾ ഒഴിവാക്കൽ നിയമത്തോളം ഇടുങ്ങിയതാക്കുക

ഹോസ്റ്റിൽ ഫയർവാൾ ഓടുന്നുണ്ടെങ്കിൽ, SSH മാനേജ്മെന്റ് സ്രോതസ്സിൽ നിന്ന് മാത്രം, LAN ഇന്റർഫേസിൽ മാത്രം അനുവദിക്കുക. 22 പോർട്ട് എവിടെനിന്നും അനുവദിക്കുന്ന നിയമം ആവശ്യത്തേക്കാൾ വിശാലമാണ്, അവലോകനത്തിൽ ന്യായീകരിക്കാൻ ബുദ്ധിമുട്ടാണ്. nftables ഹോസ്റ്റിൽ നിയമം ഇന്റർഫേസും സ്രോതസ്സും പൊരുത്തപ്പെട്ട ഇൻപുട്ട് ചെയിനിലാണ്; iptables ഹോസ്റ്റിൽ തുല്യമായത്-i ഒപ്പം-s എന്നിവയിലെ രണ്ട് പൊരുത്തങ്ങളുടെ ജോഡിയാണ്. നിയമത്തിന് അത് സേവിക്കുന്ന അഡ്മിനിസ്ട്രേറ്റർ ഗ്രൂപ്പിന്റെ കുറിപ്പ് ചേർക്കുക, അടുത്ത ഓഡിറ്റിന് 22 പോർട്ട് എന്തിന് തുറന്നിരിക്കുന്നു എന്ന് ഊഹിക്കേണ്ടിവരരുത്.

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

രണ്ട് അവസ്ഥകളും പരിശോധിക്കുക

പരിശോധന രണ്ടുതവണ നടത്തുക: ഒരിക്കൽ ടണൽ കണക്ട് ചെയ്തിരിക്കുമ്പോൾ, ഒരിക്കൽ വിച്ഛേദിച്ചിരിക്കുമ്പോൾ. ഓരോ അവസ്ഥയിലും ലിസണർ, റൂട്ട്, അഡ്മിനിസ്ട്രേറ്ററുടെ മെഷീനിൽ നിന്നുള്ള യഥാർത്ഥ SSH ലോഗിൻ എന്നിവ സ്ഥിരീകരിക്കുക. ടണൽ ഉയർന്നിരിക്കുമ്പോൾ മാത്രം പ്രവർത്തിക്കുന്ന പാത ലോക്കൽ മാനേജ്മെന്റ് പാതയല്ല; അത് യാദൃച്ഛികതയാണ്.

പിന്നീട് SSH സെഷൻ തുറന്നിരിക്കുമ്പോൾ ടണൽ റീസ്റ്റാർട്ട് ചെയ്യുക. അതിജീവിക്കുന്ന സെഷൻ റൂട്ടിംഗ് സ്ഥിരമാണെന്ന് തെളിയിക്കുന്നു; വീഴുന്ന സെഷൻ ക്ലയന്റ് വീണ്ടും കണക്ട് ചെയ്യുമ്പോൾ റൂട്ടുകളോ ഫിൽട്ടറുകളോ വീണ്ടും എഴുതുന്നു എന്ന് പറയുന്നു, അത് സംഭവത്തിന് മുമ്പ് അറിയുന്നതാണ് നല്ലത്, സമയത്തല്ല.

പരിശോധിച്ച സ്രോതസ്സ് വിലാസം രേഖപ്പെടുത്തുക, കാരണം 192.168.10.50-നായി എഴുതിയ നിയമം അഡ്മിനിസ്ട്രേറ്ററുടെ ലാപ്ടോപ്പ് മറ്റൊരു സബ്നെറ്റിലേക്ക് മാറുമ്പോൾ നിശ്ശബ്ദമായി പരാജയപ്പെടുന്നു.

വീണ്ടെടുപ്പ് പാത runbook-ൽ എഴുതുക

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

രേഖയിൽ രണ്ട് റോളുകളും വെവ്വേറെ നിലനിർത്തുക: അടുത്തുള്ള അഡ്മിനിസ്ട്രേറ്റർക്കുള്ള ലോക്കൽ SSH, ആപ്ലിക്കേഷന്റെ ട്രാഫിക്കിനുള്ള ഔട്ട്ബൗണ്ട് ടണൽ. ആ റോളുകൾ എഴുതിയിട്ടുണ്ടെങ്കിൽ, ഭാവിയിൽ അവയിലൊന്നിലെ മാറ്റം പരിശോധിക്കാൻ വ്യക്തമായ സ്ഥലമുണ്ട്, അടുത്ത വ്യക്തിക്ക് VPN-ഉള്ള സെർവർ ഇപ്പോഴും അതിന്റെ LAN വിലാസത്തിൽ പ്രതികരിക്കുന്നതെന്തുകൊണ്ടെന്ന് വീണ്ടും കണ്ടെത്തേണ്ടതില്ല.