macOS-ൽ OpenVPN TAP: ഡീബഗ് ചെയ്യുന്നതിന് മുമ്പ് ക്ലയന്റ് പരിശോധിക്കുക

പഴയ പ്രൊഫൈൽ ഒരു ആധുനിക Mac-ൽ എത്തുന്നു, ക്ലയന്റ് അത് ഒരു പരാതിയുമില്ലാതെ ഇറക്കുമതി ചെയ്യുന്നു, ബന്ധം വിച്ഛേദിക്കുന്നു അല്ലെങ്കിൽ ഒരിക്കലും ട്രാഫിക് കടന്നുപോകുന്നില്ല. സർട്ടിഫിക്കറ്റുകൾക്കായി ഒരു ഉച്ചയ്ക്ക് മുഴുവൻ ചെലവാക്കുന്നതിന് മുമ്പ് പ്രൊഫൈലിലെ ഉപകരണ വരി വായിക്കുക. അതിൽ dev tap എന്ന് എഴുതിയിട്ടുണ്ടെങ്കിൽ, നിങ്ങൾ ക്ലയന്റിനോട് Ethernet ശൈലിയിലുള്ള ഇന്റർഫേസ് ആവശ്യപ്പെടുകയാണ്, macOS-ൽ ഇത്തരം സെഷനുകളിൽ ഭൂരിഭാഗവും അവസാനിക്കുന്നത് ഈ അഭ്യർത്ഥനയിലാണ്.

ഘട്ടം 1: പ്രൊഫൈൽ യഥാർത്ഥത്തിൽ TAP ആവശ്യപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കുക

പ്രൊഫൈലുകൾ പേരുമാറ്റുകയും പൊതിയുകയും വീണ്ടും കയറ്റുമതി ചെയ്യുകയും ചെയ്യുന്നു, അതിനാൽ നിങ്ങൾ യഥാർത്ഥത്തിൽ ഇറക്കുമതി ചെയ്ത ഫയൽ പരിശോധിക്കുക. ഉപകരണ നിർദ്ദേശവും അതിനെ മറികടക്കാവുന്ന ഏതെങ്കിലും include-ഉം തിരയുക. മിക്ക കേസുകളിലും ഔട്ട്പുട്ടിന്റെ രണ്ട് വരികൾ ചോദ്യം തീർക്കുന്നു. dev-ഉം dev-type-ഉം ഒരുമിച്ച് വന്നാൽ പിന്നീടുള്ള നിർദ്ദേശം വിജയിക്കുന്നു, പകർത്തിയ പ്രൊഫൈൽ മറച്ചുവയ്ക്കുന്നത് അത്തരം വിശദാംശമാണ്.

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

ഫയലിൽ dev tap അല്ലെങ്കിൽ dev tap0 ഉണ്ടെങ്കിൽ, ക്ലയന്റ് TAP ഇന്റർഫേസ് നടപ്പാക്കണം. dev tun ഉണ്ടെങ്കിൽ, ഈ ലേഖനത്തിന്റെ ബാക്കി ബാധകമല്ല, തകരാർ മറ്റൊരിടത്താണ്.

ക്ലയന്റിന്റെ പേരും പതിപ്പും, macOS പതിപ്പും, പ്രൊഫൈൽ എവിടെ നിന്ന് വന്നു എന്നതും എഴുതിവയ്ക്കുക. ഈ മൂന്ന് വസ്തുതകളാണ് താഴെയുള്ള രണ്ട് വഴികളിൽ ഏതാണ് സാധ്യമെന്ന് നിർണ്ണയിക്കുന്നത്.

ഘട്ടം 2: ഉപകരണ മോഡ് യഥാർത്ഥത്തിൽ എന്താണ് മാറ്റുന്നതെന്ന് അറിയുക

TUN ഇന്റർഫേസ് IP പാക്കറ്റുകൾ കൊണ്ടുപോകുന്നു. ക്ലയന്റ് ഒരു IP ഇണയ്ക്ക് അയച്ച പാക്കറ്റുകൾ വായിക്കുകയും എഴുതുകയും ചെയ്യുന്നു, ഓപ്പറേറ്റിംഗ് സിസ്റ്റം അവയെ മറ്റേതൊരു ഇന്റർഫേസ് പോലെ റൂട്ട് ചെയ്യുന്നു.

TAP ഇന്റർഫേസ് Ethernet ഫ്രെയിമുകൾ കൊണ്ടുപോകുന്നു, അതിൽ ബ്രോഡ്കാസ്റ്റും ARP-ഉം ഉൾപ്പെടുന്നു. ഇതാണ് ബ്രിഡ്ജ് ചെയ്ത സെർവറിന് DHCP വഴി വിലാസങ്ങൾ വിതരണം ചെയ്യാനും ക്ലയന്റിന് ഉറക്കെ വിളിച്ച് ഉപകരണങ്ങൾ കണ്ടെത്താനും അനുവദിക്കുന്നത്, അതുകൊണ്ടാണ് ചില പഴയ രൂപകൽപ്പനകൾ ഇതിനെ ആശ്രയിക്കുന്നത്.

വില അതാണ്: TAP-ന് സിസ്റ്റത്തിന് ഒരു Ethernet ഇന്റർഫേസ് അവതരിപ്പിക്കുന്ന ഡ്രൈവർ വേണം. പഴയ Mac TAP ഡ്രൈവറുകൾ ആശ്രയിച്ചിരുന്ന കെർണൽ എക്സ്റ്റൻഷൻ മോഡൽ Apple ഒഴിവാക്കി, അതിന്റെ പകരം API ഉപയോഗിക്കാൻ ഒരിക്കലും അപ്ഡേറ്റ് ചെയ്യാത്ത ക്ലയന്റുകളിൽ അത് മാന്ത്രികമായി പ്രത്യക്ഷപ്പെടുന്നില്ല. പ്ലാറ്റ്ഫോം കഴിവും വിതരണം ചെയ്ത ഉൽപ്പന്നവും രണ്ട് വ്യത്യസ്ത കാര്യങ്ങളാണ്.

ഘട്ടം 3: അനുയോജ്യമായ ക്ലയന്റും മാറ്റവും തമ്മിൽ തിരഞ്ഞെടുക്കുക

രണ്ട് സത്യസന്ധമായ വഴികളുണ്ട്. ആദ്യത്തേത്, നിങ്ങളുടെ macOS പതിപ്പിനും ഹാർഡ്വെയറിനും വേണ്ട TAP ക്രമീകരണം പിന്തുണയ്ക്കുന്നുവെന്ന് പ്രസാധകൻ പ്രഖ്യാപിക്കുന്ന ക്ലയന്റ്. നാല് വർഷം മുമ്പത്തെ ഫോറം പോസ്റ്റല്ല, ആർക്കൈവ് ചെയ്ത ഇൻസ്റ്റാളറുമല്ല: നിലവിലെ പ്രഖ്യാപനവും ഒരു പരീക്ഷണ കണക്ഷനും.

രണ്ടാമത്തേത് സേവനം TUN-ലേക്ക് മാറ്റുന്നതാണ്, അത് ക്ലയന്റ് മാറ്റം പോലെ തന്നെ സെർവർ മാറ്റവുമാണ്. റൂട്ട് ചെയ്ത ടോപ്പോളജി, വിലാസ കൂട്ടം, ദൂര നെറ്റ്വർക്കുകൾക്കുള്ള തള്ളിയ റൂട്ടുകൾ, ആ നെറ്റ്വർക്കുകളിൽ നിന്ന് കൂട്ടത്തിലേക്കുള്ള മടക്കവഴി എന്നിവ വേണം.

പ്രവർത്തിക്കാത്തത്, നിങ്ങളുടെ പ്രാദേശിക പകർപ്പിൽ tap tun ആക്കി മാറ്റി പ്രതീക്ഷിക്കുന്നതാണ്. സെർവർ ഇപ്പോഴും ബ്രിഡ്ജ് ചെയ്യുന്നു, ക്ലയന്റ് ഇപ്പോൾ IP സംസാരിക്കുന്നു, ഒന്നും ഒത്തുപോകുന്നില്ല.

ഘട്ടം 4: പ്രവർത്തിക്കുന്ന സേവനം മാറ്റുന്നതിന് മുമ്പ് വസ്തുതകൾ ശേഖരിക്കുക

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

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

അവയുടെ ഉത്തരങ്ങളാണ് നിങ്ങൾ ഇന്ന് ഉച്ചയ്ക്ക് ക്ലയന്റ് പ്രശ്നം പരിഹരിക്കുന്നുണ്ടോ അതോ അടുത്ത ആഴ്ച നെറ്റ്വർക്ക് മാറ്റം ആസൂത്രണം ചെയ്യുന്നുണ്ടോ എന്ന് നിർണ്ണയിക്കുന്നത്.

ഘട്ടം 5: രണ്ട് അറ്റങ്ങളിൽ നിന്നും മാറ്റം പരിശോധിക്കുക

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

പിന്നീട് മുമ്പ് Ethernet സ്വഭാവത്തെ ആശ്രയിച്ചിരുന്നത് പരീക്ഷിക്കുക. ഒരു ആപ്പ് ബ്രോഡ്കാസ്റ്റിലൂടെ ഉപകരണങ്ങൾ കണ്ടെത്തിയിരുന്നെങ്കിൽ, റൂട്ട് ചെയ്ത ടണലിലൂടെ അവയെ കണ്ടെത്തില്ല, ക്ലയന്റ് കോൺഫിഗറേഷൻ എത്രയൊക്കെ മാറ്റിയാലും അത് തിരികെ വരില്ല. ആ ആപ്പിന് അറിയപ്പെടുന്ന ഒരു വിലാസം, പ്രാദേശിക സഹായ ഹോസ്റ്റ്, അല്ലെങ്കിൽ വേറെ കണ്ടെത്തൽ രീതി വേണം.

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

എന്നിട്ടും പരാജയപ്പെട്ടാൽ, ആദ്യ പിശക് വായിക്കുക

ഇന്റർഫേസ് സൃഷ്ടിക്കാൻ കഴിയാത്ത ക്ലയന്റ് അത് തന്റെ ലോഗിൽ പറയുന്നു, സാധാരണയായി ആദ്യ വരികളിൽ. അത് സൃഷ്ടിച്ചിട്ട് പിന്നീട് പ്രാമാണീകരണത്തിൽ പരാജയപ്പെടുന്ന ക്ലയന്റ് ഉപകരണ ചോദ്യം വളരെ മുമ്പേ കടന്നിരിക്കുന്നു, TAP-ന്റെ പിന്നാലെ പോകുന്നത് സെഷൻ പാഴാക്കുന്നു.

പകരം തെളിയിക്കുന്നതുവരെ യഥാർത്ഥ പ്രൊഫൈലും പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷനും സൂക്ഷിക്കുക. ക്ലയന്റ് മാറ്റം തിരികെയാക്കുന്നത് വേഗമാണ്; ആരോ ഊഹത്തിൽ പൊളിച്ച ബ്രിഡ്ജ് നെറ്റ്വർക്ക് വീണ്ടും കെട്ടുന്നത് അത്ര വേഗമല്ല.