ഒരു OpenVPN ഹബ്, മൂന്ന് LAN: വിലാസ പ്ലാനും iroute ഫയലുകളും

മൂന്ന് സ്വകാര്യ LAN-കൾക്ക് മറ്റുള്ളവയുടെ ആന്തരിക ഘടന അറിയാതെ തന്നെ ഒരു ഹബ്ബിൽ കൂടാം, കൂടാതെ മുഴുവൻ രൂപകൽപ്പനയും നാല് ചെറിയ കോൺഫിഗറേഷൻ തീരുമാനങ്ങളിൽ നിൽക്കുന്നു. ഇത് പ്രവർത്തിപ്പിക്കുന്നത് വിചിത്രമായ ഒരു പ്രോട്ടോക്കോൾ സവിശേഷതയല്ല, മറിച്ച് ആരും ഊഹിക്കേണ്ട ആവശ്യമില്ലാത്ത ഒരു വിലാസ പ്ലാനും, ഏത് ശാഖയാണ് ഏത് പ്രിഫിക്സ് സ്വന്തമാക്കുന്നതെന്ന് ഹബ്ബിനോട് പറയുന്ന ക്ലയന്റ്-തിരിച്ചുള്ള റൂട്ടുകളുമാണ്. ഇവയിൽ ഒന്ന് തെറ്റിയാലും ടണൽ ഉയരും, അതാണ് പരാജയത്തെ ആശയക്കുഴപ്പമാക്കുന്നത്.

ഘട്ടങ്ങൾ ക്രമത്തിൽ ചെയ്യുക. ഓരോ ഘട്ടവും മുൻ ഘട്ടത്തിലെ പ്ലാനിനെ ആശ്രയിച്ചിരിക്കുന്നു, ഒന്നിനും പുതിയ സർട്ടിഫിക്കറ്റ് അതോറിറ്റി ആവശ്യമില്ല.

ആരും ഊഹിക്കേണ്ട ആവശ്യമില്ലാത്ത ഒരു പ്ലാനിൽ നിന്ന് തുടങ്ങുക

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

ഒരു ഉദാഹരണ പ്ലാൻ പൂളിനെ മൂന്ന് LAN-കളിൽ നിന്ന് വളരെ അകലെ നിർത്തുന്നു. നിങ്ങളുടേത് വ്യത്യസ്തമായിരിക്കും, ഏക കർശന നിയമം രണ്ട് ശ്രേണികളും ഓവർലാപ്പ് ചെയ്യരുത് എന്നതാണ്.

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

ശാഖകൾ എവിടെയാണെന്ന് ഹബ്ബിന്റെ കേണലിനോട് പറയുക

ഹബ്ബിന് ഓരോ ശാഖയ്ക്കും രണ്ട് വിവരങ്ങൾ വേണം: പ്രിഫിക്സ് ടണൽ ഉപകരണത്തിലേക്ക് അയയ്ക്കുന്ന കേണൽ റൂട്ട്, ഒപ്പം iroute എൻട്രി, അതായത് ഏത് ക്ലയന്റാണ് അത് സ്വന്തമാക്കുന്നതെന്ന് OpenVPN പ്രോസസ്സിനോട് പറയുന്ന എൻട്രി. കേവലം കേണൽ റൂട്ട് പാക്കറ്റുകൾ ടണലിലെത്തിച്ച് അവിടെ നിർത്തുന്നു, കാരണം ഡീമൺ ഏത് പിയർ അവ സ്വീകരിക്കണമെന്ന് ഇപ്പോഴും തീരുമാനിക്കണം. കേവലം iroute എൻട്രി ആ പാക്കറ്റുകളെ പിന്തുടരാൻ റൂട്ടില്ലാതെ കേണലിൽ ഉപേക്ഷിക്കുന്നു. രണ്ട് വരികളും ഡീമൺ യഥാർത്ഥത്തിൽ ലോഡ് ചെയ്യുന്ന കോൺഫിഗറേഷനിൽ ഉള്ളതാണ്, മറ്റെന്തെങ്കിലും ഡീബഗ് ചെയ്യുന്നതിന് മുമ്പ് അത് പരിശോധിക്കേണ്ടതാണ്.

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

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

ഓരോ ശാഖയ്ക്കും ആവശ്യമായ റൂട്ടുകൾ നൽകുക

ഓരോ ശാഖയ്ക്കും മറ്റ് ശാഖകളിലേക്കും ഹബ്ബിന്റെ LAN-ലേക്കും റൂട്ടുകൾ വേണം, സ്വന്തം ബന്ധിപ്പിച്ച LAN-ലേക്ക് റൂട്ട് വേണ്ട. റിമോട്ട് പ്രിഫിക്സുകൾ ഓരോ റൂട്ടറിലും ഒട്ടിക്കുന്നതിന് പകരം ഹബ്ബിൽ നിന്ന് തള്ളുക, അങ്ങനെ നാലാമത്തെ സൈറ്റ് പിന്നീട് നാല് മാറ്റങ്ങൾക്ക് പകരം ഒരു പുതിയ ക്ലയന്റ്-തിരിച്ചുള്ള ഫയൽ മാത്രമായിരിക്കും. ക്ലയന്റ്-തിരിച്ചുള്ള ഫയലിൽ iroute വരിയുമുണ്ട്, അത് ഉടമസ്ഥതയും പ്രഖ്യാപനവും ഒരേ സ്ഥലത്ത് നിർത്തുന്നു. സർവറിന്റെ പ്രിവിലേജ് മാതൃകയ്ക്കനുസരിച്ച് ഡയറക്ടറിയും അതിലെ ഫയലുകളും വായിക്കാവുന്നതാക്കുക, അല്ലെങ്കിൽ തിരയൽ സന്ദേശമില്ലാതെ പരാജയപ്പെടും.

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

നാലാമത്തെ സൈറ്റും അതേ മാതൃക പിന്തുടരുന്നു: വ്യത്യസ്തമായ ഒരു പ്രാമാണീകരിച്ച പേര്, സ്വന്തമാക്കിയ പ്രിഫിക്സ്, ഹബ്ബിലെ കേണൽ റൂട്ട്, iroute എൻട്രി, അതിലേക്ക് എത്താൻ അനുവദിക്കപ്പെട്ട സൈറ്റുകളിലേക്ക് മാത്രമുള്ള പ്രഖ്യാപനങ്ങൾ.

പൂർത്തിയായി എന്ന് പറയുന്നതിന് മുമ്പ് രണ്ട് ദിശകളിലും പരീക്ഷിക്കുക

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

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

പ്ലാൻ, ക്ലയന്റ്-തിരിച്ചുള്ള ഫയലുകൾ, ഫയർവാൾ നിയമങ്ങൾ എന്നിവ ഒരൊറ്റ രേഖയായി രേഖപ്പെടുത്തുക, കാരണം അടുത്ത സൈറ്റ് കൂട്ടിച്ചേർക്കൽ അവയുടെ അടിസ്ഥാനത്തിൽ വിലയിരുത്തപ്പെടും.

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