രണ്ട് OpenVPN സെർവറുകളിലെ ക്ലയന്റുകൾക്ക് പരസ്പരം എത്താനാകുമോ?

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

കെട്ടുകഥ: ഒരു അക്കൗണ്ട് പട്ടിക, ഒരു നെറ്റ്വർക്ക്

പ്രാമാണീകരണവും പ്രാപ്യതയും കൂട്ടിക്കലരുന്നു കാരണം രണ്ടും സെർവർ കോൺഫിഗറേഷനിൽ കഴിയുന്നു. രണ്ട് ഗേറ്റ്‍വേകളിൽ ഏതിലും ലോഗിൻ ചെയ്യാവുന്ന ഉപയോക്താവ് പുറത്തുനിന്ന് രണ്ട് വാതിലുകളുള്ള ഒരു സിസ്റ്റത്തിലെ ഉപയോക്താവായി കാണപ്പെടുന്നു. അകത്ത്, ഓരോ സെർവറും സ്വന്തം പൂളിൽനിന്ന് വിലാസങ്ങൾ നൽകുന്നു, താൻ അവസാനിപ്പിക്കുന്ന ക്ലയന്റുകൾക്കുമാത്രം റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നു. അതിനാൽ ഗേറ്റ്‍വേ A യിലെ ക്ലയന്റ് ഗേറ്റ്‍വേ B യിലെ ക്ലയന്റിന് പാക്കറ്റ് അയയ്ക്കുമ്പോൾ സ്വന്തം സെർവർ ഒരിക്കലും കേട്ടിട്ടില്ലാത്ത ഒരു ലക്ഷ്യസ്ഥാനം ആവശ്യപ്പെടുന്നു. പാക്കറ്റ് A യുടെ സ്ഥിര റൂട്ടിലേക്ക് പോയി, ടണൽ വിട്ട്, അത് അനുവദിക്കാൻ ഒരിക്കലും ആവശ്യപ്പെടാത്ത ഒരു ഫയർവാളിൽ എത്തുന്നു.

അതിനാൽ രണ്ടാമതൊരു സെർവർ ചേർക്കുന്നത് റിഡണ്ടൻസിയോ കണ്ടെത്തലോ പങ്കിട്ട ബ്രോഡ്കാസ്റ്റ് ഡൊമെയ്നോ ചേർക്കുന്നില്ല. ഒരു പ്ലാൻ ആവശ്യമുള്ള റൂട്ട് ചെയ്ത നെറ്റ്വർക്ക് ചേർക്കുന്നു, പ്ലാൻ വിലാസനിർണ്ണയത്തിൽ തുടങ്ങുന്നു.

ഓരോ ഗേറ്റ്‍വേക്കും സ്വന്തം പൂളും ട്രാൻസിറ്റ് വിലാസവും നൽകുക

മറ്റൊന്നുമായി ഒത്തുപോകാൻ പാടില്ലാത്ത രണ്ട് ശ്രേണികൾ, കൂടാതെ ഹോസ്റ്റുകൾക്കിടയിലെ ഒരു ചെറിയ ട്രാൻസിറ്റ് ലിങ്ക്, ഇത്രയുമാണ് മുഴുവൻ വിലാസ പ്ലാനും. നിങ്ങൾ നിയന്ത്രിക്കുന്ന സ്വകാര്യ സെഗ്മെന്റിൽ ട്രാൻസിറ്റ് നിർത്തുക, ഏതെങ്കിലും സെർവർ ലീസ് നൽകുന്നതിന് മുമ്പ് സംഖ്യകൾ എഴുതിവയ്ക്കുക.

പ്രൊഫൈലുകൾ ഒരുപോലെ ഇരിക്കാൻ രണ്ട് സെർവറുകൾക്കും ഒരേ പൂൾ നൽകാനുള്ള പ്രലോഭനത്തെ ചെറുക്കുക. പങ്കിട്ട ശ്രേണിയിലുള്ള ഏതെങ്കിലും വിലാസം ഇപ്പോൾ രണ്ട് ഹോസ്റ്റുകളിൽ ആർക്കാണെന്ന് കെർണൽ റൂട്ടിന് പറയാനാകില്ല, അതിനാൽ റൂട്ടിംഗ് പട്ടിക ഒരു ഗേറ്റ്‍വേയെ ചൂണ്ടും, ക്ലയന്റ് മറ്റൊന്നിൽ ബന്ധിപ്പിച്ചിരിക്കാം. ഇന്റർഫേസ് പേരുകൾ പ്രാദേശിക സമ്പ്രദായങ്ങളാണ്, പങ്കിട്ട അവസ്ഥയല്ല. ഇവിടെ രണ്ട് ഹോസ്റ്റുകളും ടണൽ ഉപകരണത്തെ tun0 എന്നും ട്രാൻസിറ്റ് ലിങ്കിനെ transit0 എന്നും വിളിക്കുന്നു, അത് കുഴപ്പമില്ല കാരണം ഏത് പാക്കറ്റും ആ പേരുകൾ വഹിക്കുന്നില്ല.

ഇരുവശത്തും റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്യുക

ഓരോ ഗേറ്റ്‍വേക്കും ട്രാൻസിറ്റ് വിലാസത്തിലൂടെ മറ്റേതിന്റെ പൂളിലേക്ക് ഒരു റൂട്ട് വേണം, ഏതെങ്കിലും ഒന്ന് ഹോപ്പായി പ്രവർത്തിക്കാൻ ഫോർവേഡിംഗ് ഓണായിരിക്കണം. ആദ്യം നിലവിലെ പട്ടിക സ്ഥിരീകരിക്കുക, പിന്നീട് എൻട്രി ചേർത്ത്, റീകണക്ട് ഹൂക്കിനു പകരം ഹോസ്റ്റിന്റെ നെറ്റ്വർക്ക് മാനേജർ വഴി അത് സ്ഥിരമാക്കുക.

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

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

ഉടമസ്ഥാവകാശം വ്യാജമാക്കാതെ ക്ലയന്റ് റൂട്ട് പുഷ് ചെയ്യുക

ക്ലയന്റുകൾക്ക് വിദൂര പൂളിലേക്ക് ഒരു റൂട്ട് വേണം, അല്ലെങ്കിൽ അവരുടെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം പാക്കറ്റ് സ്ഥിര ഗേറ്റ്‍വേയിലേക്ക് അയയ്ക്കും, ടണൽ അത് ഒരിക്കലും കാണില്ല. സെർവർ കോൺഫിഗറേഷൻ അത് എത്തിക്കാനുള്ള സ്വാഭാവിക സ്ഥലമാണ്.

push "route 10.64.20.0 255.255.255.0"

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

ഒരു അഭ്യർത്ഥന തെളിയിക്കുക, മറ്റൊന്ന് നിരസിക്കുക

യഥാർത്ഥ പ്രവർത്തനം തിരഞ്ഞെടുക്കുക, ഉദാഹരണത്തിന് 10.64.10.21 ലെ ക്ലയന്റിൽനിന്ന് 10.64.20.37 ലെ സേവനത്തിലേക്കുള്ള HTTPS, രണ്ട് ഹോസ്റ്റുകളിലും കൃത്യമായി അത് അനുവദിക്കുക. ഓരോ ഫയർവാളും അതിന്റെ ഇൻബൗണ്ട് വശത്ത് അഭ്യർത്ഥനയും റിട്ടേൺ വശത്ത് ട്രാക്ക് ചെയ്ത മറുപടിയും സ്വീകരിക്കുന്നു; ലക്ഷ്യസ്ഥാനത്തിന്റെ സ്വന്തം സേവന നയം അത് ഇപ്പോഴും സ്വീകരിക്കണം.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

പരസ്പര റൂട്ടുകൾ ഉള്ളപ്പോൾ സോഴ്സ് NAT ആവശ്യമില്ല, ഇവിടെ സക്രിയമായി ഹാനികരമാണ്: സോഴ്സ് വിവർത്തനം ചെയ്യുന്നത് ഏത് ക്ലയന്റാണ് അഭ്യർത്ഥന നടത്തിയതെന്ന് മറയ്ക്കുകയും ലക്ഷ്യഭാഗത്തെ സോഴ്സ് അടിസ്ഥാന നയത്തെ തോൽപ്പിക്കുകയും ചെയ്യുന്നു. ഇന്റർനെറ്റ് എഗ്രസ്സിനുള്ള നിലവിലെ masquerade നിയമം ഈ വഴിയും പിടിക്കുന്നില്ലെന്ന് പരിശോധിക്കുക. പിന്നീട് നിരസിക്കൽ പരിശോധിക്കുക. പൂൾ B യിൽ പ്രാദേശികമായി തുടരേണ്ട സേവനം പൂൾ A യിൽനിന്ന് എത്താനാകാത്തതായി തുടരണം, ഒരേ ഗേറ്റ്‍വേയിലെ ക്ലയന്റ് ജോഡികളും പരിശോധിക്കണം, കാരണം ഇപ്പോൾ മാറ്റിയ ഫോർവേഡിംഗ് നയം അവർക്കും ബാധകമാണ്.

മാനസിക മാതൃകയിലേക്ക് ഒരു തിരുത്തുകൂടി: ട്രാൻസിറ്റ് ലിങ്ക് ഡീക്രിപ്റ്റ് ചെയ്ത ആന്തരിക പാക്കറ്റുകൾ വഹിക്കുന്നു, അതിനാൽ അത് സ്വകാര്യ ഉറപ്പല്ല, വിശ്വാസ അതിർത്തിയാണ്. നിങ്ങൾ നിയന്ത്രിക്കാത്ത നെറ്റ്വർക്ക് അത് കടന്നുപോകുന്നുവെങ്കിൽ, ആ ഹോപ്പിനെ അംഗീകൃത എൻക്രിപ്റ്റ് ചെയ്ത ടണൽ കൊണ്ട് സംരക്ഷിച്ച് അതിന്റെ യഥാർത്ഥ ടോപ്പോളജിയിലൂടെ റൂട്ട് ചെയ്യുക. എൻഡ്-ടു-എൻഡ് TLS ഇപ്പോഴും ആപ്ലിക്കേഷനെ സ്വയം പ്രാമാണീകരിക്കുന്നു, അതുകൊണ്ട് ആന്തരിക സേവനം അത് തുടർന്നും ഉപയോഗിക്കണം.