OpenVPN എൻജിൻ അതോ Tunnelblick അതോ: Mac VPN സെഷൻ ആരുടേതാണ്?

Homebrew ഒരു OpenVPN പ്രോഗ്രാം ഇൻസ്റ്റാൾ ചെയ്യുന്നു; Tunnelblick ഒന്നോ അതിലധികമോ എൻജിനുകൾ പ്രവർത്തിപ്പിക്കുന്ന ഒരു മാനേജർ ഇൻസ്റ്റാൾ ചെയ്യുന്നു. ഇവ വ്യത്യസ്ത പാളികളാണ്, ഉപയോഗപ്രദമായ ചോദ്യം ടെർമിനൽ ഉപയോഗിക്കാൻ നിങ്ങൾക്ക് ഇഷ്ടമാണോ എന്നതല്ല. കോൺഫിഗറേഷൻ, DNS മാറ്റങ്ങൾ, ക്രെഡൻഷ്യൽ അഭ്യർത്ഥന, സെഷൻ അവസാനിക്കുമ്പോഴുള്ള വൃത്തിയാക്കൽ എന്നിവ ആരുടേതാണ് എന്നതാണ്. ഈ പാളികൾക്ക് ഒരൊറ്റ ഉടമ ഉണ്ടായിരിക്കുന്നതാണ് സെറ്റപ്പ് പ്രവചനാതീതമാക്കുന്നത്.

താഴെയുള്ള അഞ്ച് പരിശോധനകൾ ക്രമത്തിൽ ചെയ്യുക. രണ്ട് ഉടമകളുള്ള ആദ്യത്തെ പരിശോധനയാണ്, ആളുകൾ OpenVPN-നെത്തന്നെ കുറ്റപ്പെടുത്തുന്ന വിചിത്രമായ പകുതി-ബന്ധിത അവസ്ഥകൾ സൃഷ്ടിക്കുന്നത്. ഓരോ പരിശോധനയും അത് തീരുമാനിക്കുന്ന തെളിവിനെ പേരിടുന്നു.

ആദ്യ പരിശോധന: ഏത് OpenVPN ബൈനറിയാണ് യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്നത്

ബന്ധിപ്പിച്ചിരിക്കുമ്പോൾ pgrep -fl openvpn പ്രവർത്തിപ്പിച്ച് മുഴുവൻ കമാൻഡ് ലൈനും വായിക്കുക. ആദ്യ പാതയാണ് യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്ന എൻജിൻ. Apple Silicon-ൽ Homebrew ഇൻസ്റ്റാളേഷൻ സാധാരണയായി /opt/homebrew-ന് കീഴിലാണ്, Intel Mac /usr/local ഉപയോഗിക്കുന്നു, Tunnelblick തന്റെ സ്വന്തം ആപ്ലിക്കേഷൻ ബണ്ടിലിനുള്ളിൽ നിന്നാണ് എൻജിൻ പ്രവർത്തിപ്പിക്കുന്നത്.

Tunnelblick എൻജിനുകൾ ബണ്ടിൽ ചെയ്ത് ഒരു കോൺഫിഗറേഷന് അവയിൽ ഒന്ന് തിരഞ്ഞെടുക്കാൻ അനുവദിക്കുന്നു. Homebrew ഫോർമുല അപ്ഡേറ്റ് ചെയ്യുന്നത് സ്വതന്ത്ര ബൈനറിയെ മാറ്റുന്നു, Tunnelblick പ്രൊഫൈൽ ആരംഭിക്കുന്ന എൻജിനെയല്ല. സ്വഭാവ വ്യത്യാസം വിശദീകരിക്കാൻ പതിപ്പുകൾ താരതമ്യം ചെയ്യുന്നെങ്കിൽ, പാക്കേജ് മാനേജറിലെ എൻജിനെയല്ല, പ്രോസസ് പട്ടികയിലെ എൻജിനെ താരതമ്യം ചെയ്യുക. പതിപ്പ് സ്ട്രിംഗ് മാത്രം ആ എൻജിൻ ഏത് പ്രൊഫൈൽ ലോഡ് ചെയ്തുവെന്ന് പറയില്ല.

പകർത്തിയ പ്രൊഫൈൽ വ്യത്യസ്ത ഫയലുകൾ വായിക്കുമ്പോഴും രണ്ട് എൻജിനുകളെ ഒരുപോലെ കാണിക്കാം. കമാൻഡ് ലൈനിലെ പ്രൊഫൈൽ പാത പ്രവർത്തിക്കുന്ന പ്രോസസ് ഏത് കോൺഫിഗറേഷൻ ലോഡ് ചെയ്തുവെന്ന് പറയുന്നു; എഡിറ്ററിൽ തുറന്ന പ്രൊഫൈൽ തെളിവല്ല. സ്വഭാവം താരതമ്യം ചെയ്യുന്നതിന് മുമ്പ് ആ പാത താരതമ്യം ചെയ്യുക.

രണ്ടാം പരിശോധന: DNS-ഉം റൂട്ടുകളും ആരാണ് മാറ്റുന്നത്

എൻജിന് OpenVPN-ന്റെ സ്വന്തം up, down നിർദ്ദേശങ്ങൾ പ്രവർത്തിപ്പിക്കാം, പക്ഷേ അതേ ലൈഫ് സൈക്കിൾ മാനേജർക്ക് അവകാശപ്പെട്ടതായിരിക്കാം. Tunnelblick-ന്റെ നെയിം സർവർ ക്രമീകരണങ്ങൾ അതിന്റെ സാധാരണ കണക്ഷൻ, വിച്ഛേദ സ്ക്രിപ്റ്റുകൾ നിയന്ത്രിക്കുന്നു, ആ സംയോജനം സജീവമായിരിക്കുമ്പോൾ പ്രൊഫൈലിലെ മത്സര നിർദ്ദേശങ്ങൾ അവഗണിക്കപ്പെടാം.

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

ആദ്യ കണക്ഷന് മുമ്പ് ഏത് പാളിക്കാണ് DNS എന്ന് തീരുമാനിച്ച്, രണ്ടും വെക്കുന്നതിന് പകരം തോൽക്കുന്ന നിർദ്ദേശം നീക്കം ചെയ്യുക. റൂട്ട് മാറ്റങ്ങളും അതേ നിയമം പിന്തുടരുന്നു: ഒരു ഉടമ, കോൺഫിഗറേഷനിൽ ദൃശ്യമാകുന്ന, രേഖപ്പെടുത്തിയ പുനഃസ്ഥാപന പാതയോടെ.

മൂന്നാം പരിശോധന: ക്രെഡൻഷ്യലുകൾ എവിടെ നിന്ന് വരുന്നു

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

പ്രൊഫൈലിന്റെ ക്രെഡൻഷ്യൽ ഉറവിടം പട്ടികപ്പെടുത്തുക: ക്ലയന്റ് സർട്ടിഫിക്കറ്റും കീയും, ഉപയോക്തൃനാമവും പാസ്വേഡ് അഭ്യർത്ഥനയും, അല്ലെങ്കിൽ ബാഹ്യ സഹായി നൽകുന്ന ടോക്കൺ. തുടർന്ന് കണക്ഷൻ റീബൂട്ടിനെ അതിജീവിക്കേണ്ടതാണെങ്കിൽ, തിരഞ്ഞെടുത്ത ഉടമയ്ക്ക് മനുഷ്യനില്ലാതെ ആ ഉറവിടത്തിൽ എത്താനാകുമെന്ന് ഉറപ്പാക്കുക.

നാലാം പരിശോധന: പ്രോസസ് ആരാണ് ആരംഭിക്കുന്നത്, മേൽനോട്ടം വഹിക്കുന്നത്, നിർത്തുന്നത്

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

Tunnelblick ഉടമയായി തുടരുകയാണെങ്കിൽ, രണ്ടാമതൊരു എൻജിൻ ആരംഭിക്കുന്നതിന് പകരം അതിന്റെ പിന്തുണയുള്ള നിയന്ത്രണങ്ങൾ ഉപയോഗിക്കുക. Homebrew ബൈനറി പകർത്തിയ പ്രൊഫൈലോടെ, നിലവിലുള്ള Tunnelblick സെഷനോട് കൽപ്പിക്കുന്നതിന് പകരം സ്വന്തം കോൺഫിഗറേഷനും സംയോജന സന്ദർഭവുമുള്ള സ്വതന്ത്ര കണക്ഷൻ തുറക്കുന്നു.

ഏത് ഉടമയെ തിരഞ്ഞെടുത്താലും, ഉറക്കം, നെറ്റ്വർക്ക് മാറ്റം, ലോഗൗട്ട് എന്നിവയിൽ എന്ത് സംഭവിക്കുമെന്ന് നിർവചിക്കുക. മാനേജർ സാധാരണയായി ആ സംഭവങ്ങൾ കൈകാര്യം ചെയ്യുന്നു; വെറും പ്രോസസ് സാധാരണയായി ചെയ്യുന്നില്ല, ഫലമായുണ്ടാകുന്ന പഴയ റൂട്ടോ റിസോൾവറോ സെർവർ തകരാറായി തെറ്റായി വായിക്കപ്പെടുന്നു.

അഞ്ചാം പരിശോധന: കൈമാറ്റം എങ്ങനെ പരിശോധിക്കുന്നു

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

സ്വതന്ത്ര എൻജിനിലേക്ക് കൈമാറ്റത്തിന് പ്രൊഫൈൽ പാത, ബൈനറി പാത, മേൽനോട്ടക്കാരൻ, DNS ഉടമ, ക്രെഡൻഷ്യൽ ഉറവിടം എന്നിവ രേഖപ്പെടുത്തുക. തുടർന്ന് ആ ക്രമത്തിൽ സ്വകാര്യ വിഭവം, പൊതു ഇന്റർനെറ്റ് പാത, വൃത്തിയായ വിച്ഛേദം എന്നിവ പരിശോധിക്കുക. വിച്ഛേദത്തിന് ശേഷം DNS-ഉം റൂട്ടുകളും അവശേഷിക്കുന്നുവെങ്കിൽ, പുതിയ ഉടമ പൂർത്തിയായിട്ടില്ല.

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

പാക്കേജിംഗ് സെർവർ അനുയോജ്യത തീരുമാനിക്കുന്നില്ല. സേവനത്തിന്റെ സ്വന്തം ക്ലയന്റ് ആവശ്യകതകൾ പരിശോധിച്ച്, അതിന്റെ മാനേജ്മെന്റ് നൽകാൻ ഉദ്ദേശിക്കുമ്പോൾ മാത്രം എൻജിൻ മാത്രം തിരഞ്ഞെടുക്കുക.