ഒരു Linux ഗേറ്റ്വേയിൽ രണ്ട് OpenVPN ക്ലയന്റുകൾ: നയം വിഭജിക്കുക

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

കേർണൽ തീരുമാനിക്കുന്നു, ഡീമൺ അല്ല

ഫോർവേഡ് ചെയ്യുന്ന പാക്കറ്റ് LAN ഇന്റർഫേസിൽ എത്തുന്നു, റൂട്ടിംഗ് കോഡ് നിയമങ്ങളുടെ പട്ടിക മുൻഗണനാ ക്രമത്തിൽ വിലയിരുത്തുന്നു. സെലക്ടർ ആദ്യം ഒത്തുപോകുന്ന നിയമം ഒരു പട്ടികയ്ക്ക് പേരിടുന്നു, ആ പട്ടികയിലെ റൂട്ടുകൾ ഔട്ട്പുട്ട് ഉപകരണം തിരഞ്ഞെടുക്കുന്നു. പട്ടികയിൽ ഒത്തുപോകുന്ന റൂട്ട് ഇല്ലെങ്കിൽ, തിരയൽ അടുത്ത നിയമത്തിലേക്ക് തുടരുന്നു, ഈ വിശദാംശമാണ് പകുതി പൂർത്തിയായ സജ്ജീകരണം ഉച്ചത്തിലല്ല, നിശബ്ദമായി പരാജയപ്പെടാൻ കാരണം.

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

ഓരോ ഇൻസ്റ്റൻസിനും സ്വന്തം വിഭവ കൂട്ടം നൽകുക

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

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull സർവർ തള്ളുന്ന റൂട്ടുകളെ പ്രാദേശിക പട്ടികയ്ക്ക് പുറത്ത് നിർത്തുന്നു, നയ പട്ടികകൾ വ്യക്തമായിരിക്കേണ്ടപ്പോൾ നിങ്ങൾ ആഗ്രഹിക്കുന്നത് അതാണ്. ഒരു നിർദ്ദിഷ്ട സർവർ redirect-gateway ഓപ്ഷനും തള്ളുന്നുണ്ടോ, നിങ്ങളുടെ ക്ലയന്റ് പതിപ്പ് ഫിൽട്ടർ രൂപം പിന്തുണയ്ക്കുന്നുണ്ടോ എന്നത് ഊഹിക്കുന്നതിനുപകരം കൈപ്പുസ്തകത്തിൽ പരിശോധിക്കുന്നത് മൂല്യവത്താണ്.

മാട്രിക്സ് എഴുതുക: ഉറവിടം, പട്ടിക, ഉപകരണം

ഓരോ ക്ലയന്റ് ഗ്രൂപ്പിനും, ഉറവിട വിലാസം അനുസരിച്ച് പട്ടിക തിരഞ്ഞെടുക്കുന്ന ഒരു നിയമം ചേർക്കുക, തുടർന്ന് ഉദ്ദേശിച്ച പാത ആ പട്ടികയിൽ ഇടുക:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

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

ടണലിന്റെ സ്വന്തം ഗതാഗതം ക്ലയന്റ് ഗ്രൂപ്പിലില്ല

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

പ്രാദേശിക മാനേജ്മെന്റ് സെഷനും അടിസ്ഥാന പാളിയുടെ പാതയും നയ പട്ടികകൾക്ക് പുറത്ത് വ്യക്തമായി നിർത്തുക. ആ ഒഴിവുകൾ മാട്രിക്സിന് അരികിൽ എഴുതുക; അവ രൂപകൽപ്പനയുടെ ഭാഗമാണ്, ഒരു സംഭവവേളയിൽ വീണ്ടും കണ്ടെത്തേണ്ട പരിഹാരമല്ല.

പാത തിരഞ്ഞെടുക്കുന്നത് അത് അനുവദിക്കുന്നില്ല

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

ഉറവിട വിവർത്തനം മൂന്നാമത്തെ തീരുമാനമാണ്, അത് ഉറവിട ഗ്രൂപ്പിലേക്കും അത് യഥാർത്ഥത്തിൽ വഹിക്കുന്ന ടണൽ ഉപകരണത്തിലേക്കും പരിമിതപ്പെടുത്തണം. postrouting ചെയിൻ ശൂന്യമാക്കുന്നതിനുപകരം രണ്ട് ഇൻസ്റ്റൻസുകൾക്കായി സമർപ്പിത ചെയിൻ ചേർക്കുക, കാരണം ബന്ധമില്ലാത്ത സേവനങ്ങൾക്ക് അവിടെ എൻട്രികൾ ഉണ്ടാകാം, ശൂന്യമാക്കുന്നത് അവയെ നിശബ്ദമായി നീക്കം ചെയ്യുന്നു.

ഒരു ടണൽ വീഴുമ്പോൾ എന്ത് സംഭവിക്കുന്നു

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

ഓരോ ഉറവിട ഗ്രൂപ്പിൽ നിന്നും പുതിയ അഭ്യർത്ഥന അയച്ച് നാല് വസ്തുതകൾ രേഖപ്പെടുത്തുക: തിരഞ്ഞെടുത്ത പട്ടിക, ഔട്ട്പുട്ട് ഉപകരണം, വിവർത്തനം ചെയ്ത ഉറവിടം, മറുപടി അതേ പാതയിലൂടെ തിരികെ വന്നോ എന്നത്. തുടർന്ന് ഒരു ടണൽ താഴ്ത്തി ആവർത്തിക്കുക. ഇന്റർഫേസ് പട്ടികയിലെ രണ്ട് TUN ഉപകരണങ്ങൾ രണ്ട് ഡീമണുകളും ആരംഭിച്ചു എന്ന് തെളിയിക്കുന്നു; ഒരു പ്രത്യേക ക്ലയന്റ് ഏതാണ് ഉപയോഗിച്ചതെന്ന് അവ ഒന്നും പറയുന്നില്ല. ഒരു ടണൽ ഇല്ലാത്ത രണ്ടാമത്തെ ഓട്ടമാണ് നിങ്ങളുടെ ഫോൾബാക്ക് നിയമം ഉദ്ദേശിച്ചത് ചെയ്യുന്നുണ്ടോ എന്ന് കാണിക്കുന്നത്.