സെർവറോ ക്ലയന്റോ: ഇരട്ട പങ്കുള്ള Pi യിൽ ഏത് OpenVPN യൂണിറ്റ്

ഒരു Pi യിൽ രണ്ട് OpenVPN പ്രോസസ്സുകൾ പ്രവർത്തിക്കുന്നു, അത് ഒരേ സമയം റോമിംഗ് ഉപയോക്താക്കളെ സ്വീകരിക്കുകയും മുകളിലെ ദാതാവിനെ എത്തിച്ചേരുകയും ചെയ്യുന്നു, ഹാർഡ്വെയർ അല്ലാതെ അവർ ഒന്നും പങ്കിടുന്നുമില്ല. ഒന്ന് വരുന്ന ടണലുകൾക്കായി കേൾക്കുന്നു, മറ്റൊന്ന് പുറത്തേക്ക് ഡയൽ ചെയ്യുന്നു. ഓരോന്നും സ്വന്തം ഡയറക്ടറി വായിക്കുന്നു, ഓരോന്നിനും സ്വന്തം പരാജയ രീതിയുണ്ട്. തെറ്റായത് പുനരാരംഭിക്കുന്നതാണ് ക്ലയന്റ് പരിഹാരം പകരം ശ്രോതാവിനെ കുലുക്കുന്ന ഏറ്റവും സാധാരണ വഴി.

യൂണിറ്റിന്റെ പേര് അത് ലോഡ് ചെയ്യുന്ന ഡയറക്ടറിയുമായി ഒത്തുനോക്കുക

Upstream 2.6 രണ്ട് ടെംപ്ലേറ്റ് യൂണിറ്റുകൾ നൽകുന്നു, [email protected], [email protected]. സെർവർ ടെംപ്ലേറ്റ് /etc/openvpn/server ൽ ആരംഭിക്കുകയും അവിടെ നിന്ന് %i.conf ലോഡ് ചെയ്യുകയും ചെയ്യുന്നു. ക്ലയന്റ് ടെംപ്ലേറ്റ് /etc/openvpn/client ൽ ആരംഭിക്കുന്നു. roaming എന്ന പേരുള്ള ഇൻസ്റ്റൻസ് ഒരേ സമയം രണ്ടിടത്തും നിലനിൽക്കാം, സെർവറായും ക്ലയന്റായും, പരസ്പരബന്ധമില്ലാത്ത രണ്ട് കോൺഫിഗറേഷനുകളോടെ, സ്ട്രിംഗ് അല്ലാതെ അവയ്ക്കിടയിൽ ഒരു ബന്ധവുമില്ലാതെ.

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

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

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

പാക്കറ്റിന്റെ ദിശ കൊണ്ട് തീരുമാനിക്കുക, ഇന്റർഫേസിന്റെ പേര് കൊണ്ടല്ല

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

ആ വ്യത്യാസം ഒരു നിയമം എവിടെ പെടുന്നു എന്ന് പറയുന്നു. ഫോർവേഡിംഗ് ശൃംഖലയ്ക്കുള്ളിലെ ഒരു ഇന്റർഫേസുമായി പൊരുത്തപ്പെടുന്ന നിയമം റൗട്ടിംഗ് ഇതിനകം തിരഞ്ഞെടുത്ത ട്രാഫിക്കിന് മാത്രം അനുമതി നൽകുന്നു; അത് ഒരിക്കലും പാത തിരഞ്ഞെടുക്കുന്നില്ല. റോമിംഗ് ഉപയോക്താവിന്റെ പാക്കറ്റുകൾ തെറ്റായ വഴിയിലൂടെ പുറത്തുപോകുമ്പോൾ, പരിശോധിക്കേണ്ട ശൃംഖല forward ആണ്, output അല്ല.

സിദ്ധാന്തം പറയുന്നതിന് മുമ്പ് സോക്കറ്റുകൾ നോക്കുക. udp/1194 ലേക്ക് ബന്ധിച്ച സെർവർ ഒരു കേൾക്കുന്ന സോക്കറ്റ് കാണിക്കുന്നു. ക്ലയന്റ് ദാതാവിന്റെ വിലാസവുമായുള്ള ബന്ധം കാണിക്കുന്നു, കേൾക്കുന്ന ഒന്നും ഇല്ല.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

ഒരു ഇൻസ്റ്റൻസിന്റെ ഡിഫോൾട്ട് റൂട്ട് മറ്റൊന്നിന്റെ മറുപടികൾ പിടിച്ചെടുക്കാം

മുകളിലെ ക്ലയന്റ് തള്ളുന്ന redirect-gateway മെഷീനിലെ മറ്റെല്ലാത്തിനോടും മത്സരിക്കുന്ന ഒരു ഡിഫോൾട്ട് റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്യുന്നു, സെർവർ റോമിംഗ് ഉപയോക്താക്കൾക്ക് അയക്കുന്ന മറുപടികൾ ഉൾപ്പെടെ. ടണൽ എത്തിച്ചേരാവുന്നതായി തുടരാൻ OpenVPN സ്വന്തം സഹപ്രവർത്തക വിലാസത്തിന് ഒരു അപവാദം നൽകുന്നു, പക്ഷേ ആ അപവാദം ഹോട്ടൽ നെറ്റ്വർക്കിലിരിക്കുന്ന ഒരു ഫോണിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

രോഗലക്ഷണം സാധാരണയായി അസമമാണ്. ഹാൻഡ്ഷേക്ക് പൂർത്തിയാകുന്നു, ക്ലയന്റ് കണക്റ്റ് ചെയ്തതായി റിപ്പോർട്ട് ചെയ്യുന്നു, ആദ്യ മറുപടി പാക്കറ്റിന് ശേഷം ട്രാഫിക് മരിക്കുന്നു. ഉറവിടാധിഷ്ഠിത പോളിസി റൗട്ടിംഗ്, അല്ലെങ്കിൽ --mark ഉപയോഗിച്ച് സെർവർ ഇൻസ്റ്റൻസിൽ വെച്ച പാക്കറ്റ് മാർക്ക്, രണ്ട് പ്രവാഹങ്ങളെ വേർതിരിച്ച് നിർത്തുന്നു; അവയിൽ ഒന്നും ഒറ്റയ്ക്ക് പൂർണ്ണ നിയമക്കൂട്ടമല്ല, രണ്ടിനും അവർ തിരഞ്ഞെടുക്കുന്ന പട്ടികയിൽ സാധുവായ റൂട്ടുകൾ വേണം.

ടണലിന്റെ അവസ്ഥയ്ക്ക് പകരം പ്രാദേശിക തീരുമാനം പരിശോധിക്കുക, കാരണം OpenVPN പാക്കറ്റ് കാണുന്നതിന് മുമ്പ് കേർണൽ ഉറവിടവും ഇന്റർഫേസും തിരഞ്ഞെടുക്കുന്നു.

ip route get 203.0.113.44
ip rule show

ഒരു പങ്ക് പുനരാരംഭിച്ച് മറ്റൊന്ന് അതിജീവിച്ചു എന്ന് തെളിയിക്കുക

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

മാറ്റത്തിന് മുമ്പ് നിർത്തൽ വ്യവസ്ഥ എഴുതുക: മുകളിലെ ടണൽ നഷ്ടപ്പെടുന്നത് റോമിംഗ് ഉപയോക്താക്കളെ തടയുന്നുണ്ടോ, അതോ Pi യുടെ സ്വന്തം മുകളിലേക്കുള്ള ലിങ്കിലേക്ക് മടങ്ങുന്നുണ്ടോ? DNS-നും IPv6-നും വ്യക്തമായ ഉത്തരം വേണം, കാരണം തള്ളിയ റിസോൾവർ അതിനെ ഉപയോഗപ്രദമാക്കിയ റൂട്ടിനെക്കാൾ കൂടുതൽ കാലം ജീവിക്കാറുണ്ട്.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

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