ഒരു Linux ഹോസ്റ്റിൽ രണ്ട് OpenVPN ടണലുകൾ: റൂട്ട് ആരുടേതാണ്?

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

രണ്ടാം ലിങ്ക് ചെയ്യേണ്ട ജോലിയിൽ നിന്ന് തുടങ്ങുക

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

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

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

ആദ്യ കമാൻഡ് പ്രവർത്തിക്കുന്ന ഇൻസ്റ്റൻസുകൾ ലിസ്റ്റ് ചെയ്യുന്നു, മാനേജർക്ക് പുറത്ത് കൈകൊണ്ട് ആരംഭിച്ചവയും ഉൾപ്പെടെ. രണ്ടാമത്തേത് നിലവിലെ ഡിഫോൾട്ട് ക്ലെയിം പ്രിന്റ് ചെയ്യുന്നു, അതാണ് പിന്നീട് നിങ്ങൾ വിശദീകരിക്കേണ്ട അവസ്ഥ.

ഓവർലാപ്പ് ചെയ്യുന്ന പൂളുകൾ റൂട്ടിംഗിന് മുമ്പേ തകരുന്നു

രണ്ട് സർവറുകൾ ഒരേ 10.8.0.0/24-ൽ നിന്ന് വിലാസങ്ങൾ സന്തോഷത്തോടെ അനുവദിക്കും. അപ്പോൾ ക്ലയന്റ് ഒരു പ്രിഫിക്സിനുള്ളിൽ രണ്ട് ഇന്റർഫേസുകൾ കൈവശം വയ്ക്കുന്നു, ഏത് ലക്ഷ്യം ഏതിന് സ്വന്തമെന്ന് പറയാൻ ഒന്നുമില്ല, ഫലമായുണ്ടാകുന്ന സ്വഭാവം റൂട്ടിംഗ് തകരാറായി തോന്നുന്നു, എന്നാൽ യഥാർത്ഥത്തിൽ അത് നമ്പറിംഗ് തകരാറാണ്. ഒരു പൂൾ പുനർനമ്പർ ചെയ്യാൻ ഒരു കോൺഫിഗറേഷൻ എഡിറ്റ് ചെലവാകും; തുടർന്നുള്ള ഓരോ റൂട്ടിംഗ് വഴിത്തിരിവും ഒരു വാരാന്ത്യം ചെലവാകും. അതിന് റൂട്ട് ചേർക്കുന്നതിന് മുമ്പ് പൂൾ പരിശോധിക്കുക.

പ്രാദേശിക LAN-ഉം നോക്കുക. ഒരു ടണൽ തുറന്നുകാണിക്കുന്ന 192.168.1.0/24 നമ്പറുള്ള വീട്ടു LAN-ഉം അതേ ആശയക്കുഴപ്പം സൃഷ്ടിക്കുന്നു, ലക്ഷണം കണക്ഷൻ ഒരിക്കലും പൂർത്തിയാകാതെ പരിഹരിക്കപ്പെടുന്ന ഹോസ്റ്റ്നെയിമാണ്. റൂട്ടുകൾ പ്രിന്റ് ചെയ്യുന്നതുവരെ അത് പേര് പരിഹരിക്കൽ തകരാറായി തോന്നും.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

ക്ലയന്റ് തൊടുന്നതിന് മുമ്പ് രണ്ട് ഔട്ട്പുട്ടുകളും രണ്ട് സർവർ കോൺഫിഗറേഷനുകളുമായി താരതമ്യം ചെയ്യുക. പ്രിഫിക്സുകൾ ഒന്നിനൊന്ന് മേലേക്കിട്ടാൽ, നിർത്തി പുനർനമ്പർ ചെയ്യുക, എത്ര തവണ റീസ്റ്റാർട്ട് ചെയ്താലും അവ വേർപെടുത്തില്ല.

ഓരോ പ്രൊഫൈലിനും സ്വന്തം യൂണിറ്റും ഓരോ പ്രിഫിക്സിനും ഉടമയും നൽകുക

ഓരോ പ്രൊഫൈലിനും സ്വന്തം ഇൻസ്റ്റൻസ് നാമവും സ്വന്തം കോൺഫിഗറേഷൻ ഫയലും ലഭിക്കുന്നു, അതിനാൽ office എന്ന ഇൻസ്റ്റൻസ് office.conf ലോഡ് ചെയ്യുന്നു, lab എന്നത് lab.conf ലോഡ് ചെയ്യുന്നു. ഡയറക്ടറി ലിസ്റ്റിംഗ് വിശ്വസിക്കുന്നതിന് പകരം സർവീസ് മാനേജർ വഴി ആ മാപ്പിംഗ് സ്ഥിരീകരിക്കുക, കാരണം drop-in ഏത് ഫയൽ ലോഡ് ചെയ്യുന്നു എന്ന് മാറ്റാം. മാപ്പിംഗ് തെറ്റായാൽ നിങ്ങൾ പ്രവർത്തിക്കാത്ത പ്രൊഫൈൽ ട്യൂൺ ചെയ്യുകയാണ്.

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

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

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

മാർക്കുകൾ മറുപടികളെ അവ വന്ന ഇന്റർഫേസിൽ നിലനിർത്തുന്നു

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

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

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

മറ്റൊന്ന് ചേർക്കുന്നതിന് മുമ്പ് നിലവിലുള്ള നിയമങ്ങൾ വായിക്കുക. ഇരട്ടി മുൻഗണനകളും മറന്ന പട്ടികകളുമാണ് ഒരു മാർക്ക് നയം തീർത്തും ഫലമില്ലാത്തതായി തോന്നുന്ന സാധാരണ കാരണം.

ഒരു ലിങ്ക് നിർത്തി വേർതിരിവ് തെളിയിക്കുക

രണ്ട് ടണലുകളും ഉയർന്നിരിക്കുമ്പോൾ ഓരോ ഇന്റർഫേസിന്റെയും വിലാസം, ഓരോ ടണലിന് പിന്നിലുള്ള ഒരു ഹോസ്റ്റിലേക്കുള്ള റൂട്ട്, ബന്ധമില്ലാത്ത ഒരു ലക്ഷ്യം സ്വീകരിക്കുന്ന വഴി എന്നിവ രേഖപ്പെടുത്തുക. ഒരു പട്ടിക വായിക്കുന്നതിന് പകരം കെർണലിനോട് ലുക്കപ്പ് ആവശ്യപ്പെടുക, കാരണം ഒരു പട്ടിക ഒരിക്കലും അന്തിമ തീരുമാനം കാണിക്കുന്നില്ല.

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

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