ഒരു ഉറവിട-പോർട്ട് നിയമം നിങ്ങളുടെ ഒരു SSH പാതയെ തകർക്കുന്നത് എന്തുകൊണ്ട്

ഒരേ ഹോസ്റ്റിൽ രണ്ട് മാനേജ്മെന്റ് എൻട്രികൾ, ഒരു സേവന പോർട്ട്, രണ്ടിനെയും സഹായിക്കേണ്ടിയിരുന്ന ഒരു നയ നിയമം. നിയമം ഉറവിട പോർട്ട് 22-മായി പൊരുത്തപ്പെടുന്നു, WAN സ്ഥിരസ്ഥിതി മാത്രം അറിയുന്ന പട്ടികയിലേക്ക് തിരയൽ അയയ്ക്കുന്നു, കൂടാതെ നേരിട്ടുള്ള എൻട്രി പ്രവർത്തിക്കുമ്പോൾ VPN എൻട്രി പുതിയ ലോഗിനുകൾക്ക് മറുപടി നൽകുന്നത് നിർത്തുന്നു. സെലക്ടർ ശരിയായി വായിച്ചാൽ ഇതിലൊന്നും നിഗൂഢതയില്ല. ഉറവിട പോർട്ട് ഒരു സേവനത്തെ തിരിച്ചറിയുന്നു, ഒരു കണക്ഷൻ വന്ന പാതയെയല്ല.

രണ്ട് എൻട്രികൾ, ഒരു സേവന പോർട്ട്

ഹോസ്റ്റിന് LAN വശത്തുള്ള വിലാസവും VPN വിലാസവുമുണ്ട്, sshd രണ്ടിലും കേൾക്കുന്നു. അതിനാൽ നേരിട്ടുള്ള സെഷനും ടണൽ സെഷനും സേവന പോർട്ട് പങ്കിടുന്നു, ഏത് ലോക്കൽ വിലാസം കണക്ഷൻ സ്വീകരിക്കുന്നു എന്നതിൽ മാത്രം വ്യത്യാസപ്പെടുന്നു.

ആ വ്യത്യാസം മറുപടി പാത തിരഞ്ഞെടുക്കാൻ മതി, പോർട്ട് അടിസ്ഥാനമാക്കിയ നിയമം കളയുന്നത് കൃത്യമായി ആ വ്യത്യാസമാണ്. രണ്ട് സെഷനുകളും ഉറവിട പോർട്ട് 22 ഉള്ള മറുപടികൾ സൃഷ്ടിക്കുന്നു, അതിനാൽ ആ പോർട്ടുമായി പൊരുത്തപ്പെടുന്ന നിയമത്തിന് അവയെ വേർതിരിക്കാനാവില്ല. അത് രണ്ട് തിരയലുകളും ഒരേ പട്ടികയിലേക്ക് അയയ്ക്കുന്നു, അവയിലൊന്നിന് യോജിക്കാത്ത ഒരു മറുപടി ലഭിക്കുന്നു. യഥാർത്ഥത്തിൽ വ്യത്യാസമുള്ള ഗുണത്തോട് പൊരുത്തപ്പെടുകയാണ് പരിഹാരം.

ഓരോ എൻട്രിക്കും സ്വന്തം പോർട്ട് നൽകുന്നതും പ്രവർത്തിക്കും, അതിനെ ഒരു ആവശ്യകതയായി കാണുന്നത് SSH-ന്റെ സ്വഭാവമല്ല, ഡിസൈൻ തിരഞ്ഞെടുപ്പാണ്.

നിയമം വായിക്കുക, പിന്നെ പട്ടിക

നയ നിയമം ഒരു ക്രമീകരിച്ച സെലക്ടറാണ്, ഉപയോഗയോഗ്യമായ മറുപടി നൽകുന്ന ആദ്യത്തേത് തിരയൽ അവസാനിപ്പിക്കുന്നു. പട്ടിക ക്രമത്തിൽ വായിച്ച് ഏത് നിയമത്തിന് വിജയിക്കാമെന്ന് ശ്രദ്ധിക്കുക.

പിന്നെ ആ നിയമം ചൂണ്ടിക്കാണിക്കുന്ന പട്ടിക വായിക്കുക, കാരണം വിജയകരമായി പരിഹരിക്കപ്പെടുന്ന നിയമം ഉപയോഗപ്രദമായി പരിഹരിക്കപ്പെടുന്ന നിയമമല്ല. സ്ഥിരസ്ഥിതി റൂട്ട് മാത്രമുള്ള ഒരു പട്ടിക VPN-ൽ നിന്നുള്ള മറുപടിയെ WAN ഇന്റർഫേസിലൂടെ പുറത്തേക്ക് അയയ്ക്കുന്നു. പിന്നീടുള്ള പട്ടികയിലെ കൂടുതൽ നിർദ്ദിഷ്ട റൂട്ട് ഒരിക്കലും പരിശോധിക്കപ്പെടുന്നില്ല, അതുകൊണ്ടാണ് രണ്ടാമത്തെ പട്ടിക ചേർക്കുന്നത് പലപ്പോഴും ഒന്നും മാറ്റാത്തത്. പരിശോധിക്കേണ്ടത് തിരഞ്ഞെടുത്ത പട്ടികയാണ്.

ip -4 rule show
ip route show table 100
ip route show table main

ഈ രണ്ട് ഔട്ട്പുട്ടുകളും ഒരുമിച്ച് ഫലം വിശദീകരിക്കുന്നു; ഓരോന്നും ഒറ്റയ്ക്ക് തെറ്റായ നിഗമനത്തിലേക്ക് ക്ഷണിക്കുന്നു.

നിയമം നിങ്ങൾ ഉദ്ദേശിക്കുന്ന ഒഴുക്കിലേക്ക് പരിമിതപ്പെടുത്തുക

രണ്ട് എൻട്രികളെ വേർതിരിക്കുന്ന ഗുണം ലോക്കൽ ഉറവിട വിലാസമാണ്. ആ വിലാസവുമായി പൊരുത്തപ്പെടുന്ന നിയമം ടണൽ സെഷനുകൾ മാത്രം സ്വകാര്യ പട്ടികയിലേക്ക് അയയ്ക്കുന്നു, നേരിട്ടുള്ള സെഷനുകൾ പ്രധാന പട്ടികയിൽ നിർത്തുന്നു.

ആ നിയമം സ്വകാര്യ റൂട്ടും ആ സബ്നെറ്റിന്റെ തിരിച്ചുവരവ് പാതയും ഉള്ള ഒരു പട്ടികയുമായി ജോടിയാക്കണം. രണ്ടിനെയും ഹോസ്റ്റിലെ എല്ലാ സേവനങ്ങളിലേക്കല്ല, മാനേജ്മെന്റ് ട്രാഫിക്കിലേക്ക് പരിമിതപ്പെടുത്തുക. ആ വിലാസത്തിൽ നിന്നുള്ള എല്ലാ ട്രാഫിക്കും പിടിക്കുന്ന നിയമം ഹോസ്റ്റ് അവിടെ നിന്ന് അയയ്ക്കുന്ന മറ്റെല്ലാം കൂടി വഴിതിരിച്ചുവിടും. ഇവിടെ ഇടുങ്ങിയത് മിടുക്കനെ തോൽപ്പിക്കുന്നു, കാരണം അടുത്ത വ്യക്തിക്ക് അത് വായിക്കേണ്ടതുണ്ട്.

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

രണ്ട് എൻട്രികളും ഒരു ലോക്കൽ വിലാസത്തിലേക്ക് വിവർത്തനം ചെയ്താൽ ആ വേർതിരിവ് അപ്രത്യക്ഷമാകും, ഡിസൈനിന് പകരം കണക്ഷൻ ബോധ്യമുള്ള അവസ്ഥ വേണം.

ലിസണർ, അനുമതി, മറുപടി തിരഞ്ഞെടുപ്പ് എന്നിവ വേർതിരിച്ച് നിർത്തുക

സെഷൻ പ്രവർത്തിക്കാൻ മൂന്ന് വേറിട്ട കാര്യങ്ങൾ ശരിയായിരിക്കണം: വിലാസം നിലവിലുണ്ട്, സേവനം അതിൽ കേൾക്കുന്നു, മറുപടി തിരിച്ചുള്ള വഴി കണ്ടെത്തുന്നു. റൂട്ട് മാറ്റം മൂന്നാമത്തേത് മാത്രം ശരിയാക്കുന്നു.

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

നിങ്ങൾ മാറ്റുന്ന പാതയെ ആശ്രയിക്കാത്ത ഒരു വീണ്ടെടുപ്പ് ചാനൽ നിലനിർത്തുക, കാരണം ഇവിടത്തെ തെറ്റ് പരിഹാരത്തെത്തന്നെ പൂട്ടിയിടുന്നു.

പഴയതല്ല, പുതിയ ഒരു സെഷൻ ഉപയോഗിച്ച് ഇത് തെളിയിക്കുക

സ്ഥാപിതമായ ടെർമിനൽ ഒന്നും തെളിയിക്കുന്നില്ല, കാരണം അത് മാറ്റത്തിന് മുമ്പ് പ്രവേശിപ്പിക്കപ്പെട്ടതാണ്. ഓരോ ഉദ്ദേശിച്ച എൻട്രിയിലൂടെയും പുതിയ സെഷൻ തുറക്കുക.

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

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