ഒരു Pi, രണ്ട് OpenVPN ഇൻസ്റ്റൻസുകൾ: ഓരോ യൂണിറ്റും വായിക്കുന്നത്
ഒരു Pi-യിലെ രണ്ട് OpenVPN ഡീമണുകൾ വ്യത്യസ്ത കോൺഫിഗ് ഫയലുകൾ വായിച്ച് വ്യത്യസ്ത ഹൂക്കുകളിലൂടെ പുറത്തുപോകുന്നു. ഓരോ ഇൻസ്റ്റൻസും മാപ്പ് ചെയ്ത ശേഷം പേലോഡ് പാത വെവ്വേറെ പരിശോധിക്കുക.
പ്രൊഫൈൽ തൊടുന്നതിന് മുമ്പ് OpenVPN പ്രോസസുകൾ എണ്ണുക. റോമിംഗ് ഉപയോക്താക്കളെ സ്വീകരിക്കുകയും അതേ സമയം അപ്സ്ട്രീം സേവനത്തിലേക്ക് ഡയൽ ചെയ്യുകയും ചെയ്യുന്ന Pi രണ്ട് ഡീമണുകൾ പ്രവർത്തിപ്പിക്കുന്നു, അവയിൽ ഓരോന്നും നിങ്ങൾ നൽകിയ ഇൻസ്റ്റൻസ് പേര് തിരഞ്ഞെടുക്കുന്ന കോൺഫിഗ് ഫയൽ വായിക്കുന്നു. പാക്കേജ് ടെംപ്ലേറ്റുകൾ പിന്നീട് ഓരോ ഡീമണിനും സ്വന്തം പ്രവർത്തന ഡയറക്ടറിയും സ്വന്തം റൺടൈം സ്റ്റാറ്റസ് ഫയലും സ്വന്തം ടണൽ ഉപകരണവും നൽകുന്നു. ഈ വിഭജനം തെറ്റാക്കിയാൽ, പ്രവർത്തിക്കുന്ന പ്രോസസ് ഒരിക്കലും തുറക്കാത്ത ഫയലിലെ ശരിയായ ക്രമീകരണം മാറ്റാൻ ഒരു വൈകുന്നേരം ചെലവാക്കും.
ഓരോ ഇൻസ്റ്റൻസ് പേരും സ്വന്തം ഫയൽ തിരഞ്ഞെടുക്കുന്നു
OpenVPN 2.6-നൊപ്പം വരുന്ന യൂണിറ്റ് ഫയലുകളിൽ, സ്റ്റാർട്ട് ആർഗ്യുമെന്റുകളിൽ @ ചിഹ്നത്തിന് ശേഷമുള്ള ടെക്സ്റ്റ് കൊണ്ട് നിറയ്ക്കുന്ന ഇൻസ്റ്റൻസ് പ്ലേസ്ഹോൾഡർ അടങ്ങിയിരിക്കുന്നു. സെർവർ ടെംപ്ലേറ്റ് സെർവർ കോൺഫിഗ് ഡയറക്ടറിയിൽ നിന്ന് പ്രവർത്തിച്ച് അവിടെയുള്ള %i.conf-നെതിരെ അതിന്റെ ആർഗ്യുമെന്റ് പരിഹരിക്കുന്നു, ക്ലയന്റ് ടെംപ്ലേറ്റ് ക്ലയന്റ് ഡയറക്ടറിയിൽ നിന്ന് അതേ കാര്യം ചെയ്യുന്നു. അതിനാൽ [email protected] സെർവർ ഡയറക്ടറിയിലെ admits.conf വായിക്കുന്നു, [email protected] ക്ലയന്റ് ഡയറക്ടറിയിലെ uplink.conf വായിക്കുന്നു, ആ പേരുകളിൽ ഒന്നിനും മറ്റേ ഡയറക്ടറിയിൽ യാതൊരു അർത്ഥവുമില്ല.
പാക്കേജ് അപ്സ്ട്രീം ഡിഫോൾട്ടുകൾ നിലനിർത്തി എന്ന് അനുമാനിക്കാതെ, യന്ത്രത്തിൽ തന്നെ മാപ്പിംഗ് സ്ഥിരീകരിക്കുക. ഡിസ്ട്രിബ്യൂഷന്റെ drop-in പ്രവർത്തന ഡയറക്ടറിയോ കോൺഫിഗ് ആർഗ്യുമെന്റോ പൂർണ്ണമായി മാറ്റാൻ അനുവദനീയമാണ്.
systemctl cat [email protected]
systemctl cat [email protected]ആ ഔട്ട്പുട്ടിലെ WorkingDirectory വരിയും കോൺഫിഗ് ആർഗ്യുമെന്റും വായിക്കുക, ഏത് ഫയൽ ലോഡ് ചെയ്യുന്നു എന്ന് തീരുമാനിക്കുന്നത് പ്രവർത്തനക്ഷമമാക്കിയ യൂണിറ്റ് മാത്രമാണ്. ExecStart-ലേക്ക് --config ചേർക്കുന്ന drop-in, ടെംപ്ലേറ്റ് പാത ശരിയായി തോന്നിയാലും ടെംപ്ലേറ്റിനെ തോൽപ്പിക്കുന്നു. പ്രാദേശിക ഓവർറൈഡ് നിലവിലുണ്ടോ എന്ന് അറിയാൻ ഫ്രാഗ്മെന്റിന്റെയും drop-in-ന്റെയും പാതകൾ ചോദിക്കുക. രണ്ട് റോളുകളും ഒരു ഫയലിലേക്ക് പരിഹരിക്കുന്നുവെങ്കിൽ, ഒരു പ്രോസസ് സെർവറും ക്ലയന്റും ആകാൻ ശ്രമിക്കുന്നു, ആ ഫയലിലെ പിന്നീടുള്ള ഓപ്ഷൻ നിശബ്ദമായി വിജയിക്കുന്നു.
പ്രാദേശിക ഗതാഗതവും ഫോർവേഡ് ചെയ്ത പേലോഡും വ്യത്യസ്ത ഹൂക്കുകളിൽ എത്തുന്നു
ഓരോ റോമിംഗ് ഉപയോക്താവിലേക്കുമുള്ള സെർവറിന്റെ എൻക്രിപ്റ്റ് ചെയ്ത കണക്ഷൻ Pi-യിൽ തന്നെ സൃഷ്ടിക്കപ്പെടുന്നു, അതിനാൽ അതിന്റെ പുറം മറുപടികൾ പ്രാദേശിക ഔട്ട്പുട്ട് ഹൂക്കിലൂടെ പുറത്തുപോകുന്നു. ക്ലയന്റിന്റെ അപ്സ്ട്രീം പിയറിലേക്കുള്ള കണക്ഷനും പ്രാദേശികമായി സൃഷ്ടിച്ച ഔട്ട്പുട്ടാണ്, അത് ദൂരെയുള്ള നെറ്റ്വർക്കിൽ എത്തിയാലും. ഫോർവേഡ് ചെയ്യുന്ന പേലോഡ് മൂന്നാം വിഭാഗമാണ്, പാക്കറ്റിന് പുറത്തുപോകുന്ന ഉപകരണം ഇതിനകം തിരഞ്ഞെടുത്തതിന് ശേഷം മാത്രമേ കേർണൽ അത് പൊരുത്തപ്പെടുത്തൂ.
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
ഫോർവേഡ് ചെയിനിനുള്ളിൽ പുറത്തുപോകുന്ന ഇന്റർഫേസുമായി പൊരുത്തപ്പെടുന്ന നിയമത്തിന്, റൂട്ടിംഗ് ഇതിനകം ആ ഇന്റർഫേസിന് നൽകിയ പാക്കറ്റ് അനുവദിക്കാനോ ഉപേക്ഷിക്കാനോ കഴിയും, പക്ഷേ അത് ഒരിക്കലും ഇന്റർഫേസ് തിരഞ്ഞെടുക്കുന്നില്ല. ഒരു ഹോസ്റ്റ് ഒരു ടണൽ അവസാനിപ്പിച്ച് മറ്റൊന്ന് ആരംഭിക്കുമ്പോൾ, ഉപയോക്തൃ പേലോഡ് അപ്സ്ട്രീം ടണലിലേക്ക് അയക്കുന്ന നയവും Pi-യുടെ സ്വന്തം എൻക്രിപ്റ്റ് ചെയ്ത മറുപടികളെ സംരക്ഷിക്കുന്ന നയവും രണ്ട് വെവ്വേറെ തീരുമാനങ്ങളാണ്. അവ യാദൃശ്ചികമായി ഒരേ ഭൗതിക NIC-ൽ എത്തുന്നു, അതുകൊണ്ടാണ് അവ കൂട്ടിക്കുഴയുന്നത്.
ആ വ്യത്യാസം സാധാരണമായ പകുതി-പരാജയം വിശദീകരിക്കുന്നു. ഉപയോക്താക്കൾ കണക്ട് ചെയ്യുന്നു, ഹാൻഡ്ഷേക്ക് പൂർത്തിയാകുന്നു, എന്നിട്ടും അവരുടെ ട്രാഫിക് തെറ്റായ വഴിയിലൂടെ പുറത്തുപോകുന്നു, കാരണം ഹാൻഡ്ഷേക്ക് പ്രാദേശികവും പേലോഡ് ഫോർവേഡും ആയിരുന്നു, രണ്ടിൽ ഒന്ന് മാത്രമാണ് പരിശോധിച്ചത്.
ഇറക്കുമതി ചെയ്ത റൂട്ട് നിങ്ങളുടെ ഉപയോക്താക്കൾക്കുള്ള മറുപടികളെ വിഴുങ്ങാം
ക്ലയന്റ് പ്രൊഫൈലിന്റെ സുരക്ഷാ ക്രമീകരണം, അപ്സ്ട്രീമിന് Pi-യുടെ റൂട്ടിംഗ് ടേബിളിലേക്ക് എന്ത് push ചെയ്യാമെന്ന് തീരുമാനിക്കുന്നു, വിശാലമായ റീഡയറക്ട് ആണ് പ്രവർത്തിക്കുന്ന ഇരട്ട-റോൾ ഹോസ്റ്റിനെ തകർന്നതാക്കുന്ന ഓപ്ഷൻ. push ചെയ്ത റൂട്ട് റോമിംഗ് ഉപയോക്താക്കളുടെ പൊതു വിലാസങ്ങൾ ഉൾക്കൊള്ളുന്നുവെങ്കിൽ, സെർവർ അവർക്കായി സൃഷ്ടിക്കുന്ന മറുപടികൾ അണ്ടർലേ വഴി പുറത്തുപോകുന്നതിന് പകരം പുതിയ റൂട്ട് പിന്തുടർന്ന് അപ്സ്ട്രീം ടണലിൽ പ്രവേശിച്ചേക്കാം. ദാതാവിലേക്കുള്ള ടണൽ ഇപ്പോഴും പ്രവർത്തിക്കുന്നു എന്ന് ഉറപ്പാക്കി അവിടെ നിർത്തുന്നത് സാധാരണമാണ്, കാരണം ആ ട്രാഫിക് ടണലിന്റെ സ്വന്തം ഗതാഗതമാണ്, ബാക്കിയെല്ലാം തെറ്റായി പെരുമാറുമ്പോഴും അത് ഒഴുകിക്കൊണ്ടിരിക്കുന്നു.
ഉറവിടത്തെയോ mark-നെയോ അടിസ്ഥാനമാക്കിയുള്ള നയമാണ് രണ്ട് സ്ട്രീമുകളെ വേർതിരിച്ച് നിർത്തുന്ന വഴി. OpenVPN-ന്റെ Linux mark ഓപ്ഷൻ ഡീമണിന്റെ സ്വന്തം എൻക്രിപ്റ്റ് ചെയ്ത പാക്കറ്റുകൾക്ക് ഫയർവാൾ mark അടയാളപ്പെടുത്തുന്നു, ഒരു റൂട്ടിംഗ് നിയമത്തിന് അത് സമർപ്പിത ടേബിളിലേക്ക് അയക്കാം. സെർവറിന്റെ പുറം മറുപടികൾ എപ്പോഴും ഒരു അണ്ടർലേ വിലാസത്തിൽ നിന്ന് പുറത്തുപോകുമ്പോൾ ഉറവിട വിലാസങ്ങളും അത്രതന്നെ നന്നായി പ്രവർത്തിക്കുന്നു. രണ്ട് സമീപനങ്ങൾക്കും അത് തിരഞ്ഞെടുക്കുന്ന ടേബിളിൽ സാധുവായ റൂട്ടുകളും ദാതാവിന്റെ endpoint-ന് ഒരു ഒഴിവും ആവശ്യമാണ്, അല്ലെങ്കിൽ ടണൽ തന്നെ ഉയരില്ല.
ഏതെങ്കിലും നിയമം എഴുതുന്നതിന് മുമ്പ്, ഒരു മറുപടി യഥാർത്ഥത്തിൽ ഏത് പാതയിലൂടെ പോകുമെന്ന് കേർണലിനോട് ചോദിക്കുക. താഴെയുള്ള വിലാസങ്ങൾ Pi-യുടെ അണ്ടർലേ വിലാസത്തിനും ഒരു റോമിംഗ് ഉപയോക്താവിന്റെ പൊതു വിലാസത്തിനും ഉള്ള പ്ലേസ്ഹോൾഡറുകളാണ്.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10വിഭജനം പരിശോധിച്ച്, പിന്നീട് ഓരോ റോളും വെവ്വേറെ നിർത്തുക
മൂന്ന് പ്രവാഹങ്ങളും വെവ്വേറെ പരിശോധിക്കുക, കാരണം വിജയിക്കുന്ന ഹാൻഡ്ഷേക്ക് മറ്റ് രണ്ടിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. പുതിയ ഇൻബൗണ്ട് കണക്ഷൻ സ്വീകരിക്കുക, അനുവദനീയമായ ഒരു ആപ്ലിക്കേഷൻ അപ്സ്ട്രീം എക്സിറ്റിലൂടെ അയക്കുക, രണ്ട് പ്രോസസുകളും ഇപ്പോഴും അവരുടെ പിയറുകളിൽ എത്തുന്നുവെന്ന് സ്ഥിരീകരിക്കുക.
തുടർന്ന് ക്ലയന്റ് റോൾ നിർത്തി സെർവർ റോൾ എന്ത് നിലനിർത്തുന്നു എന്ന് നിരീക്ഷിക്കുക. ഒരു ഇൻസ്റ്റൻസിനായി ഉദ്ദേശിച്ചതും രണ്ടിനും ബാധകമായതുമായ ഒരു റൂട്ട് അല്ലെങ്കിൽ mark നിയമം കണ്ടെത്താനുള്ള ഏറ്റവും ചെലവുകുറഞ്ഞ വഴിയാണിത്.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerക്ലയന്റ് റോൾ താഴെയിരിക്കുമ്പോൾ ലിസണർ ഇപ്പോഴും ബൈൻഡ് ചെയ്തിരിക്കുന്നതും ടണൽ ഉപകരണം ഇപ്പോഴും നിലവിലുള്ളതും ലോഗിൽ പുതിയ പിശകുകൾ ഇല്ലാത്തതും നിങ്ങൾ കാണാൻ ആഗ്രഹിക്കുന്നു. ക്ലയന്റ് നിർത്തുന്നത് നിലവിലുള്ള ഉപയോക്താക്കളിലേക്കുള്ള സെർവറിന്റെ മറുപടികളും മുറിച്ചാൽ, രണ്ട് റോളുകളും അവയിൽ ഒന്നിൽ മാത്രം പരിമിതപ്പെടുത്തേണ്ട എന്തോ പങ്കിടുന്നു. ഓരോ മാറ്റവും ഏത് ഇൻസ്റ്റൻസിനെയും ഏത് കോൺഫിഗ് ഫയലിനെയും ഏത് പ്രവാഹ ഉടമയെയും സ്പർശിച്ചു എന്ന് രേഖപ്പെടുത്തുക, അല്ലെങ്കിൽ ഈ ഹോസ്റ്റ് അടുത്തതായി ഡീബഗ് ചെയ്യുന്ന ആൾ അതേ കണ്ടെത്തൽ പൂജ്യത്തിൽ നിന്ന് ആവർത്തിക്കും.