ഒരു OpenVPN ക്ലയന്റിന് SSH വഴി മറ്റൊന്നിലേക്ക് എത്താൻ അനുവദിക്കുക, പൂൾ തുറക്കാതെ

ഒരു ക്ലയന്റ് മറ്റൊരു ക്ലയന്റിന്റെ SSH സേവനത്തിലേക്ക് എത്തണം, പൂളിന്റെ ബാക്കി ഭാഗം ഇന്നത്തെപ്പോലെ വേർതിരിച്ചിട്ടിരിക്കണം. പ്രലോഭിപ്പിക്കുന്ന സ്വിച്ച് client-to-client ആണ്, അത് എല്ലാവർക്കും ഒരുമിച്ച് സഹകക്ഷി പ്രവേശനം ഓൺ ചെയ്യുകയും തീരുമാനം കേർണലിന് പകരം OpenVPN ന് നൽകുകയും ചെയ്യുന്നു. ഇടുങ്ങിയ മറുപടി ആ സ്വിച്ച് ഓഫ് ആയി നിർത്തി, സെർവറിന്റെ സ്വന്തം റൗട്ടിംഗും ഫയർവാളും കൃത്യമായി ഒരു പ്രവാഹം വഹിക്കാൻ അനുവദിക്കുന്നു.

നിയമത്തിന്റെ പാഠത്തേക്കാൾ സംവിധാനം പ്രധാനമാണ്, കാരണം രണ്ട് സമീപനങ്ങളും പാക്കറ്റ് വ്യത്യസ്ത സ്ഥലങ്ങളിൽ വയ്ക്കുന്നു. ഏതാണ് തിരഞ്ഞെടുത്തതെന്ന് അറിയുന്നത് ഒന്നും ചെയ്യാത്തതുപോലെ തോന്നുന്ന നിയമത്തെയും അതില്ലാതെ ബന്ധിപ്പിക്കുന്ന സഹകക്ഷിയെയും വിശദീകരിക്കുന്നു.

client-to-client പാക്കറ്റ് എങ്ങോട്ട് നീക്കുന്നു

client-to-client ഓണായിരിക്കുമ്പോൾ സെർവർ സഹകക്ഷിയുടെ പാക്കറ്റ് ടണൽ ഉപകരണത്തിൽ നിന്ന് വീണ്ടും പുറത്തേക്ക് അയക്കാതെ അകത്തുനിന്നുതന്നെ കടത്തിവിടുന്നു, അതിനാൽ പാക്കറ്റ് ഒരിക്കലും കേർണലിന്റെ ഫോർവേഡിംഗ് പാതയിൽ എത്തുന്നില്ല. ഇത് സൗകര്യപ്രദമാണ്, കൂടാതെ നിങ്ങളുടെ ഫയർവാൾ നിരീക്ഷിക്കേണ്ട പ്രവാഹം ഒരിക്കലും കാണുന്നില്ല എന്നും അർത്ഥം. ഓപ്ഷൻ ഓഫ് ആയി വച്ചാൽ സെർവർ പാക്കറ്റ് അതേ ഇന്റർഫേസിലൂടെ വീണ്ടും പുറത്തേക്ക് അയക്കുന്നു, ഇത് അതിനെ netfilter-ന്റെ മുന്നിൽ എത്തിക്കുന്നു. അതേ ഇന്റർഫേസ് അകത്തേക്ക്, അതേ പുറത്തേക്ക്, കൂടാതെ FORWARD ശൃംഖലയ്ക്ക് വോട്ടുണ്ട്.

കൈമാറ്റം വ്യക്തമാണ്: ഒരു നയ പോയിന്റ് നേടുന്നു, ഷോർട്ട്കട്ട് നിങ്ങൾക്കുവേണ്ടി ചെയ്തിരുന്ന റൗട്ടിംഗും ഫോർവേഡിംഗും നിങ്ങൾ ഏൽക്കുന്നു. ആ ജോലി ഒരു പ്രവാഹത്തിന് ചെറുതാണ്, നിങ്ങൾ ചേർക്കുന്ന ഓരോ അപവാദത്തോടും വളരുന്നു. അപവാദങ്ങൾ ഇപ്പോൾ തന്നെ എണ്ണുക, കാരണം സഹകക്ഷികൾക്കിടയിലുള്ള നയം യഥാർത്ഥത്തിൽ ജീവിക്കുന്നത് നിയമസംഹിതയിലാണ്.

സഹകക്ഷിയുടെ പാക്കറ്റ് യഥാർത്ഥത്തിൽ സഞ്ചരിക്കുന്ന പാത

Linux Community OpenVPN 2.6 സേവനം, DCO-യ്ക്ക് പകരം ഉപയോക്തൃ സ്ഥലത്ത് TUN പ്രോസസ്സിംഗ്, സബ്നെറ്റ് ടോപ്പോളജി, tun0, ക്ലയന്റ് A 10.44.0.21-ൽ, ക്ലയന്റ് B 10.44.0.37-ൽ എന്നിവയുള്ള 10.44.0.0/24 പൂൾ എന്ന് കരുതുക. സബ്നെറ്റ് ടോപ്പോളജിയിൽ A-യ്ക്ക് ലഭിച്ച വിലാസവും നെറ്റ്മാസ്കും ഇതിനകം പൂൾ ഉൾക്കൊള്ളുന്നു, അതിനാൽ A അധികമായി തള്ളിയ റൂട്ട് കൂടാതെ പാക്കറ്റ് ടണൽ ഉപകരണത്തിലേക്ക് അയക്കുന്നു. A-യിലെ യഥാർത്ഥ റൂട്ട് പരിശോധിക്കുക, അനുമാനിക്കരുത്.

സെർവറിൽ പാക്കറ്റ് B-യ്ക്ക് വിലാസം നൽകി വരുന്നു, അത് പ്രാദേശിക വിലാസമല്ല, അതിനാൽ അത് കടത്തിവിടുന്നു. ഇത് സംഭവിക്കാൻ IPv4 ഫോർവേഡിംഗ് ഓണായിരിക്കണം, റൂട്ട് തിരയൽ പാക്കറ്റ് വീണ്ടും tun0 വഴി പുറത്തേക്ക് അയക്കണം. അതിനാൽ ഫയർവാൾ ഇരുവശത്തും ഒരേ ഇന്റർഫേസുള്ള ഫോർവേഡ് ചെയ്ത പ്രവാഹം കാണുന്നു, ഇതാണ് മിക്ക നിയമസംഹിതകളും വിട്ടുപോകുന്ന സൂക്ഷ്മത. ഇവിടെ ഉറവിട പരിഭാഷ ആവശ്യമില്ല, A-യുടെ വിലാസം അക്ഷതമായി സൂക്ഷിക്കുന്നതാണ് B-യ്ക്ക് അതിന്റെ സ്വന്തം ഉറവിടാധിഷ്ഠിത നിയമം പ്രയോഗിക്കാൻ അനുവദിക്കുന്നത്.

സെർവറിൽ രണ്ട് നിയമങ്ങൾ, ഈ ക്രമത്തിൽ

മൂന്ന് നിയമങ്ങൾ മുഴുവൻ അനുമതിയും വഹിക്കുന്നു: ഫോർവേഡിംഗ്, ജോടി അപവാദം, ടണൽ ജോടിക്കുള്ള സ്ഥിരസ്ഥിതി ഡ്രോപ്പ്. സ്വീകാര്യതാ നിയമം ജോടിയെയും സേവനത്തെയും പേരിടുന്നു, അതിനാൽ അനുമതി വളരുന്ന പൂളിലും നിലനിൽക്കുന്നു. ടണൽ-മുതൽ-ടണൽ ട്രാഫിക്കിനുള്ള ഏതെങ്കിലും പൊതു നിരാകരണത്തിന് മുമ്പ് അത് വയ്ക്കുക, കാരണം ആദ്യ പൊരുത്തമാണ് വിജയിക്കുന്നത്:

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROP

ആ കമാൻഡുകൾ ഉദാഹരണങ്ങളാണ്, നിങ്ങളുടെ ഹോസ്റ്റ് നിയമങ്ങൾ സൂക്ഷിക്കാൻ ഉപയോഗിക്കുന്ന സംവിധാനത്തിന്റെ ഭാഗമാണ്; പ്രവർത്തനസമയത്ത് ചേർത്ത നിയമം അടുത്ത ബൂട്ടിൽ അപ്രത്യക്ഷമാകും. അവസ്ഥയുള്ള നിയമമാണ് B-യുടെ മറുപടികളും TCP ഹാൻഡ്ഷേക്കും രണ്ടാമത്തെ, പ്രതിബിംബിത സ്വീകാര്യത കൂടാതെ തിരികെ വരാൻ അനുവദിക്കുന്നത്.

പിന്നീട് നിയമങ്ങളുടെ പട്ടികയല്ല, കൗണ്ടറുകൾ പരിശോധിക്കുക, കാരണം ഒരിക്കലും പൊരുത്തപ്പെടാത്ത നിയമം പ്രവർത്തിക്കുന്നതുപോലെ തോന്നും. കൗണ്ടറുകൾ പൂജ്യത്തിൽ നിന്നാൽ, പാക്കറ്റ് നിങ്ങൾ കരുതുന്ന പാതയിലൂടെ പോകുന്നില്ല.

B ഇനിയും എന്ത് അനുവദിക്കണം

SSH സേവനം B ആണ് പ്രവർത്തിപ്പിക്കുന്നത്, അതിനാൽ ടണൽ വിലാസത്തിൽ എന്തെങ്കിലും കേൾക്കുന്നുണ്ടോ, അതിന്റെ സ്വന്തം ഹോസ്റ്റ് ഫയർവാൾ ഉറവിടം സ്വീകരിക്കുന്നുണ്ടോ എന്ന് B തീരുമാനിക്കുന്നു. സെർവറിലെ നെറ്റ്വർക്ക് അനുമതി B-യിലെ ഏതെങ്കിലും അക്കൗണ്ടിനുള്ള അനുമതിയല്ല, ഹോസ്റ്റ് കീ പരിശോധനയും ഉപയോക്തൃ പ്രാമാണീകരണവും മറ്റെവിടെനിന്ന് വന്നാലും ബാധകമാണ്.

ആദ്യം പോസിറ്റീവ് സന്ദർഭം പരിശോധിക്കുക: A-യിൽ നിന്ന് B-യുടെ ടണൽ വിലാസത്തിലേക്ക് പുതിയ SSH കണക്ഷൻ, പ്രതീക്ഷിച്ച ഹോസ്റ്റ് കീയോടെ സ്വീകരിക്കപ്പെടണം. പിന്നീട് മറ്റൊരു സഹകക്ഷിയെയോ മറ്റൊരു പോർട്ടിനെയോ പരിശോധിച്ച് അത് നിരസിക്കപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കുക, കാരണം നിശ്ശബ്ദമായി എല്ലാം അനുവദിക്കുന്ന അനുമതി അത് പ്രധാനമാകുന്നതുവരെ പ്രവർത്തിക്കുന്നതിൽ നിന്ന് വേർതിരിക്കാനാവില്ല. ആ പരിശോധനയുടെ രണ്ട് പകുതികളും ആവശ്യമാണ്, രണ്ടാമത്തേതാണ് ആളുകൾ ഒഴിവാക്കുന്നത്.

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