OpenVPN-ൽ മുൻകൂട്ടി സൃഷ്ടിച്ച tun: രണ്ട് ഉടമസ്ഥതാ മാതൃകകളുടെ താരതമ്യം

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

പേര് ബന്ധിപ്പിക്കലല്ല

dev tun1 OpenVPN നോട് ആ പേരുള്ള ഇന്റർഫേസ് ആവശ്യപ്പെടുന്നു, പരമ്പരാഗത യൂസർസ്പേസ് ബിൽഡുകൾ അത് തുറക്കാൻ ശ്രമിക്കും. പേര് സാധാരണ tun അല്ലെങ്കിൽ tap പാറ്റേൺ പിന്തുടരുന്നില്ലെങ്കിൽ, പ്രൊഫൈലിന് അനുയോജ്യമായ dev-type കൂടി വേണം, കാരണം തരം ഒരിക്കലും ഒരു സ്ട്രിംഗിൽ നിന്ന് അനുമാനിക്കുന്നില്ല. TAP ഉപകരണം മറ്റൊരു ലേബലുള്ള TUN ഉപകരണമല്ല: തെറ്റായത് ബന്ധിപ്പിച്ചാൽ ഒന്നുകിൽ ഉടൻ പരാജയപ്പെടും, അല്ലെങ്കിൽ ആരും പ്രതീക്ഷിക്കാത്ത ഫ്രെയിമുകൾ വഹിക്കുന്ന ഒരു ലിങ്ക് ഉണ്ടാകും. എല്ലാറ്റിനും മുൻപ് തരം പരിശോധിക്കുക, കാരണം തുടർന്നുള്ള ഓരോ പരിശോധനയും ഇരുവശവും അതിൽ യോജിക്കുന്നു എന്ന് അനുമാനിക്കുന്നു. അതിന് ശേഷം, പ്രക്രിയയ്ക്ക് ഉപകരണം യഥാർത്ഥത്തിൽ തുറക്കാൻ കഴിയുമോ എന്ന്, കേവലം കാണാൻ മാത്രമല്ല, ഉറപ്പാക്കുക.

dev tun1
dev-type tun

നെറ്റ്വർക്ക് ഇന്റർഫേസും /dev/net/tun ഉം വ്യത്യസ്ത വസ്തുക്കളാണ്: ഒന്ന് നെയിംസ്പേസിനുള്ളിലെ ലിങ്ക്, മറ്റൊന്ന് യൂസർസ്പേസ് പ്രോഗ്രാം ബന്ധിക്കാൻ ഉപയോഗിക്കുന്ന പ്രതീക ഉപകരണം. Linux TUN/TAP ഡോക്യുമെന്റേഷൻ ആ ബന്ധിപ്പിക്കൽ പാതയും സ്ഥിര ഉപകരണങ്ങളുടെ ഉടമസ്ഥതാ നിയമങ്ങളും വിവരിക്കുന്നു. ip link പ്രവർത്തിപ്പിക്കാൻ കഴിയുന്ന root ഷെൽ ഷെല്ലിന് അനുമതികളുണ്ടെന്ന് മാത്രം തെളിയിക്കുന്നു, ഡീമണിനുണ്ടെന്നല്ല. ഉപകരണ നോഡിന്റെ ഉടമസ്ഥത, സേവനത്തിന്റെ കഴിവുകളുടെ കൂട്ടം, അത് പ്രവർത്തിക്കുന്ന ഉപയോക്താവ് — എല്ലാം യോജിക്കണം, തുറക്കൽ വിജയിക്കുന്നതിന് മുൻപ്.

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

ലിങ്ക് ആരാണ് കോൺഫിഗർ ചെയ്യുന്നത്: രണ്ട് ഉടമസ്ഥതാ മാതൃകകൾ

ആദ്യ മാതൃകയിൽ OpenVPN കണക്ഷൻ ഉയർത്തുന്നതിന്റെ ഭാഗമായി വിലാസങ്ങളും റൂട്ടുകളും കോൺഫിഗർ ചെയ്യുന്നു. ഇതാണ് സ്ഥിരസ്ഥിതി സ്വഭാവം, ഒരു ഘടകം അവസ്ഥ സൃഷ്ടിച്ച് വീണ്ടും നീക്കം ചെയ്യുന്നതിനാൽ ഏറ്റവും എളുപ്പം ചിന്തിക്കാനാകുന്നതും. രണ്ടാം മാതൃകയിൽ ഒരു ബാഹ്യ മാനേജർ ഇന്റർഫേസിന്റെ ഉടമയാണ്, ifconfig-noexec OpenVPN നെ അതിന്റെ വിലാസ കോൺഫിഗറേഷൻ കമാൻഡുകൾ പ്രവർത്തിപ്പിക്കുന്നതിൽ നിന്ന് തടയുകയും പരാമീറ്ററുകൾ സ്ക്രിപ്റ്റുകൾക്ക് നൽകുകയും ചെയ്യുന്നു. അപ്പോൾ മാനേജർ ശരിയായ പ്രാദേശിക, പിയർ കോൺഫിഗറേഷൻ സ്വയം പ്രയോഗിക്കണം, ഇത് ഓപ്ഷന്റെ പേര് സൂചിപ്പിക്കുന്നതിനേക്കാൾ കൂടുതൽ ജോലിയാണ്. ഇവയിൽ നിന്ന് തിരഞ്ഞെടുക്കുന്നത് ലിങ്ക് ഉയർന്നിരിക്കുമ്പോൾ അത് ആർക്ക് മാറ്റാമെന്നുള്ള ചോദ്യമാണ്.

ifconfig-noexec വിലാസങ്ങൾ മാത്രം ഉൾക്കൊള്ളുന്നു: റൂട്ടിംഗ് പട്ടിക തൊട്ടുമുട്ടാതെ നിൽക്കുന്നു, റൂട്ട് കോൺഫിഗറേഷൻ route-noexec ന്റേതാണ്. രണ്ട് നിർദ്ദേശങ്ങളെയും വ്യത്യസ്ത ഉടമകളുള്ള വേറിട്ട നിയന്ത്രണങ്ങളായി കാണുക, കാരണം ഒന്ന് സജ്ജീകരിച്ച് മറ്റൊന്ന് അനുമാനിക്കുന്നത് പകുതി കോൺഫിഗർ ചെയ്ത ലിങ്കുകളുടെ സാധാരണ ഉറവിടമാണ്. ഓരോ പാളിക്കും കൃത്യമായി ഒരു ഉടമയെ തിരഞ്ഞെടുക്കുക, വിലാസങ്ങൾ ഒരിടത്തും റൂട്ടുകൾ ഒരിടത്തും. നെറ്റ്വർക്ക് മാനേജരും VPN സഹായിയും രണ്ടുപേരും വിലാസങ്ങൾ എഴുതുന്നത്, വിച്ഛേദനം മറുവശം ഇപ്പോഴും ആശ്രയിക്കുന്ന അവസ്ഥ മായ്ക്കുന്ന വിധമാണ്.

പ്രധാനമായ നെയിംസ്പേസിൽ നിന്ന് ഉപകരണം പരിശോധിക്കുക

VPN പ്രക്രിയ പ്രവർത്തിക്കുന്ന നെയിംസ്പേസിൽ നിന്ന് ഉപകരണം പരിശോധിക്കുക, നിങ്ങളുടെ ഷെൽ യാദൃച്ഛികമായി ഇരിക്കുന്നതിൽ നിന്നല്ല. താഴെയുള്ള രണ്ട് കമാൻഡുകളും വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു, ഹോസ്റ്റ് കണ്ടെയ്നർ കാണാത്ത ഒരു ഇന്റർഫേസ് കാണുമ്പോൾ വ്യത്യാസം പ്രകടമാകുന്നു. നൽകിയ ക്രമത്തിൽ അവ പ്രവർത്തിപ്പിക്കുക, കാരണം ലിങ്ക് ഉണ്ടോ ഇല്ലയോ എന്ന് അറിഞ്ഞ ശേഷം മാത്രമേ രണ്ടാമത്തേതിന് അർത്ഥമുള്ളൂ.

ip -details link show dev tun1
ip tuntap show

ആദ്യ കമാൻഡ് കർണൽ കാണുന്നതുപോലെ ലിങ്ക് അച്ചടിക്കുന്നു, ഫ്ലാഗുകളും ഇന്റർഫേസ് തരവും ഉൾപ്പെടെ, അങ്ങനെ ഇത് നിങ്ങൾ ഉദ്ദേശിച്ച ഉപകരണമാണെന്ന് ഉറപ്പാക്കുന്നു. രണ്ടാമത്തേത് സ്ഥിരമായ tun/tap എൻട്രികൾ ലിസ്റ്റ് ചെയ്യുന്നു, അവ ഒരു പ്രക്രിയയും പിടിച്ചുനിർത്താതെ നിലനിൽക്കുന്നു. തന്റെ നിശ്ചിത ഉടമയെ കാത്തിരിക്കുന്ന ഇന്റർഫേസ് മറ്റൊരു VPN ലേക്ക് ബന്ധിപ്പിച്ച ജീവനുള്ള ടണലിൽ നിന്ന് വ്യത്യസ്തമായ അവസ്ഥയാണ്, നിങ്ങളുടെ സ്വന്തം ബന്ധിപ്പിക്കൽ എന്തുകൊണ്ട് പരാജയപ്പെടുന്നു എന്ന് രണ്ടാമത്തേത് മാത്രം വിശദീകരിക്കുന്നു. എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് ഉപകരണം പിടിച്ചിരിക്കുന്ന പ്രക്രിയ കണ്ടെത്തുക, കാരണം സ്ഥിര എൻട്രിക്കും തിരക്കിലുള്ള ഇന്റർഫേസിനും വ്യത്യസ്ത പരിഹാരങ്ങളാണ്.

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

രണ്ട് തരം സ്ഥിരത

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

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

തുടക്കം മാത്രം പരിശോധിച്ചാൽ എന്ത് തകരും

ഉടമസ്ഥതാ കരാർ ആദ്യ പരീക്ഷയിൽ വിജയിച്ച് അവസാനത്തേതിൽ പരാജയപ്പെടാം, ഇത് തുടക്കം ഒറ്റയ്ക്ക് ദുർബലമായ പരിശോധനയാക്കുന്നു. പകരം രണ്ട് പരിവർത്തനങ്ങൾ നിരീക്ഷിക്കുക: ഒരു മൃദു പുനഃസജ്ജീകരണം, പൂർണ്ണ നിർത്തലും അതിന് ശേഷമുള്ള തുടക്കവും.

systemctl status openvpn-client@lab
ip -details link show dev tun1

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

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

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