OpenVPN-ന്റെ "File exists" റൂട്ടിൽ ഫയൽ പ്രശ്നമല്ല
സന്ദേശം ഫയൽ സിസ്റ്റത്തിൽ നിന്നല്ല, കെർണലിന്റെ റൂട്ട് പട്ടികയിൽ നിന്നാണ് വരുന്നത്. LAN നയം മാറ്റുന്നതിന് മുൻപ് ഇതിനകം പ്രിഫിക്സ് ഉള്ള എൻട്രി വായിക്കുക.
സന്ദേശം പ്രത്യക്ഷപ്പെടുന്നിടത്ത് നിന്ന് തുടങ്ങുക. ഒരു ക്ലയന്റ് കണക്റ്റ് ചെയ്യുന്നു, ടണൽ ഉയരുന്നു, തുടർന്ന് ലോഗ് റിപ്പോർട്ട് ചെയ്യുന്നത് Linux-ന്റെ റൂട്ട് ചേർക്കൽ കമാൻഡ് File exists-നൊപ്പം പരാജയപ്പെട്ടു എന്നാണ്. ആ വാക്യത്തിൽ സർട്ടിഫിക്കറ്റ്, കീ അല്ലെങ്കിൽ കോൺഫിഗറേഷൻ ഫയൽ എന്നിവയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, വാക്കുകൾ അങ്ങനെ സൂചിപ്പിക്കുന്നുവെങ്കിലും. കെർണൽ തന്റെ റൂട്ടിംഗ് പട്ടിക വിവരിക്കുകയാണ്, നിങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യാൻ ആവശ്യപ്പെട്ട പ്രിഫിക്സിന് ഇതിനകം ഒരു എൻട്രിയുണ്ട്.
ക്ലയന്റിന്റെ സ്വന്തം ക്രമം പിന്തുടരുക: എന്താണ് അഭ്യർത്ഥിച്ചത്, പട്ടികയിൽ ഇതിനകം എന്തുണ്ടായിരുന്നു, ആ എൻട്രി അവിടെ ആരാണ് വെച്ചത്, അതിനുശേഷം മാത്രം എന്താണ് മാറ്റേണ്ടത്. ഓരോ ഘട്ടവും ഒരു സാധ്യതയുള്ള ഉടമയെ ഒഴിവാക്കുന്നു.
ക്ലയന്റ് യഥാർത്ഥത്തിൽ ആവശ്യപ്പെട്ടത്
പരാജയത്തിന് മുൻപ്, ചേർക്കാൻ ഉദ്ദേശിക്കുന്ന റൂട്ട് ക്ലയന്റ് രേഖപ്പെടുത്തുന്നു, സാധാരണയായി ലക്ഷ്യം, നെറ്റ്മാസ്ക്, ഗേറ്റ്വേ, ചിലപ്പോൾ മെട്രിക് അല്ലെങ്കിൽ പട്ടിക എന്നിവയായി. ആ വരിയാണ് അഭ്യർത്ഥന. തുടർന്നുള്ള പിശക് കെർണലിന്റെ ഉത്തരമാണ്, രണ്ടും ഒപ്പം വായിക്കണം.
journalctl -u openvpn-client@office -b --no-pager | grep -nE 'route|File exists'
openvpn --config /etc/openvpn/client/office.ovpn --verb 4 --log /tmp/ovpn.log
റൂട്ട് സഹായിയുടെ പൂജ്യമല്ലാത്ത എക്സിറ്റ് സ്റ്റാറ്റസ് അതിന് താഴെയുള്ള ടെക്സ്റ്റിനെക്കാൾ കുറഞ്ഞ വിവരം നൽകുന്നു, കാരണം വ്യത്യസ്ത കെർണൽ പ്രതികരണങ്ങൾ പൂജ്യമല്ലാത്ത സ്റ്റാറ്റസ് നൽകുന്നു. കൃത്യമായ സന്ദേശം സൂക്ഷിക്കുക; നിലവിലുള്ള എൻട്രിയും എത്തിച്ചേരാനാകാത്ത ഗേറ്റ്വേയും തമ്മിലുള്ള വ്യത്യാസം അടുത്ത ഏത് വിഭാഗങ്ങൾ ബാധകമെന്ന് തീരുമാനിക്കുന്നു.
നിലവിലുള്ള റൂട്ട് വായിക്കുക, വിലാസം മാത്രമല്ല
പട്ടികയിൽ അതേ ഡോട്ട് ചതുർഭാഗം തിരയുന്നത് പര്യാപ്തമല്ല. ഒരു റൂട്ട് ഒബ്ജക്ട് അതിന്റെ വിലാസ കുടുംബം, പട്ടിക, ലക്ഷ്യ പ്രിഫിക്സ്, മെട്രിക്, പ്രോട്ടോക്കോൾ, ഔട്ട്പുട്ട് ഉപകരണം എന്നിവയാൽ തിരിച്ചറിയപ്പെടുന്നു, പ്രിഫിക്സ് പങ്കിടുന്ന എൻട്രികൾ ആ ഗുണങ്ങൾ വ്യത്യസ്തമാകുമ്പോൾ നിയമപരമായി ഒരുമിച്ച് നിലനിൽക്കാം. കൂട്ടിയിടിക്കുന്നത് മുഴുവൻ ഒബ്ജക്ടാണ്, ടെക്സ്റ്റല്ല.
ip -4 route show table all | grep -F '10.40.'
ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5
അവസാന കമാൻഡ് ആദ്യ രണ്ടിൽ നിന്ന് വ്യത്യസ്തമായ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: എന്താണ് നിലവിലുള്ളത് എന്നല്ല, ആ ലക്ഷ്യത്തിനായി കെർണൽ ഇപ്പോൾ ഏത് എൻട്രി തിരഞ്ഞെടുക്കുമെന്നതാണ്. രണ്ട് കാഴ്ചപ്പാടുകളും ഉപകാരപ്രദമാണ്, ഏതെങ്കിലും നിഗമനത്തിലെത്തുന്നതിന് മുൻപ് താരതമ്യം ചെയ്യാൻ തക്കവണ്ണം അവ പലപ്പോഴും വ്യത്യാസപ്പെടുന്നു. അവ തമ്മിലുള്ള പൊരുത്തക്കേടാണ് രസകരമായ കേസ്, റൗണ്ടിംഗ് പിശകല്ല.
പരാജയപ്പെട്ട അഭ്യർത്ഥനയ്ക്കൊപ്പം പ്രിഫിക്സ്, പട്ടിക, മെട്രിക്, ഉപകരണം എന്നിവ രേഖപ്പെടുത്തുക. നിലവിലുള്ള എൻട്രിക്ക് അതേ ഗുണങ്ങളും അതേ അടുത്ത ഹോപ്പും ഉണ്ടെങ്കിൽ, നിങ്ങൾക്ക് റൂട്ടിംഗ് പ്രശ്നമല്ല, ഇരട്ടിച്ച നിർദ്ദേശമാണ്.
പ്രിഫിക്സിന് ഉണ്ടാകാവുന്ന നാല് ഉടമകൾ
കണക്റ്റ് ചെയ്ത റൂട്ടുകൾ അനുവദിച്ച വിലാസത്തിൽ നിന്ന് വരുന്നു, ആ വിലാസം ഉള്ളപ്പോഴെല്ലാം സിസ്റ്റം അവ വീണ്ടും സൃഷ്ടിക്കുന്നു. DHCP ക്ലയന്റോ കണക്ഷൻ മാനേജറോ സ്വന്തം ജീവിതചക്രത്തിന്റെ ഭാഗമായി റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നു. മറ്റൊരു VPN ക്ലയന്റ് ഇതിനകം അതേ പ്രിഫിക്സ് വഹിച്ചേക്കാം. കൂടാതെ ഒരു പ്രാദേശിക ഹുക്കോ സ്ക്രിപ്റ്റോ മറ്റൊന്നും അറിയാത്ത ഒന്ന് ചേർക്കാം.
ഓരോ ഉടമയ്ക്കും വ്യത്യസ്ത തിരുത്ത് വേണം. കണക്റ്റ് ചെയ്ത റൂട്ട് നിങ്ങൾക്ക് ഇല്ലാതാക്കാനുള്ളതല്ല; അത് നീക്കുന്നത് ടണൽ ഉപയോഗയോഗ്യമാകുന്നതിന് മുൻപ് പ്രാദേശിക പ്രവേശനം തകർക്കാം, കെർണൽ അത് തിരികെ വെക്കും. മാനേജറുടെ ഉടമസ്ഥതയിലുള്ള റൂട്ട് ആ മാനേജറിലൂടെ മാറ്റണം, അടുത്ത വീണ്ടും കണക്ഷൻ റദ്ദാക്കുന്ന കൈകൊണ്ടുള്ള ip route del കൊണ്ടല്ല.
നിലനിർത്തിയ ഇന്റർഫേസ് അതേ ആശയക്കുഴപ്പം എളുപ്പമാക്കുന്നു. ടണൽ ഉപകരണം വീണ്ടും കണക്ഷനിൽ നിന്ന് അതിജീവിക്കുമ്പോൾ, ഇഷ്ടാനുസൃത സെറ്റപ്പ് കോഡ് ഇൻസ്റ്റാൾ ചെയ്ത റൂട്ടുകൾ രണ്ടാം റണ്ണിലും നിലനിൽക്കാം, അതിനാൽ വൃത്തിയുള്ള അവസ്ഥ കരുതുന്ന സ്ക്രിപ്റ്റ് രണ്ടാം തവണ പരാജയപ്പെടുകയും ആദ്യ തവണ പ്രവർത്തിക്കുകയും ചെയ്യുന്നു. പഴയ എൻട്രി ബോധപൂർവം മായ്ക്കുകയോ സെറ്റപ്പ് കോഡ് ഐഡംപൊട്ടന്റ് ആക്കുകയോ ചെയ്യുക.
block-local മറ്റൊരു ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു
ഒരു പ്രൊഫൈൽ എല്ലാ ട്രാഫിക്കും ടണലിലൂടെ അയക്കുമ്പോൾ, പ്രാദേശിക നെറ്റ്വർക്കിന് എന്ത് സംഭവിക്കുമെന്ന് ക്ലയന്റ് തീരുമാനിക്കണം. block-local ഫ്ലാഗ് പ്രാദേശിക LAN ടണലിലൂടെ റൂട്ട് ചെയ്ത് ആ തീരുമാനം മാറ്റുന്നു, അതേസമയം LAN ഗേറ്റ്വേയ്ക്കുള്ള രേഖപ്പെടുത്തിയ ഒഴിവാക്കൽ നിലനിർത്തുന്നു; ഇത് എത്തിച്ചേരാനുള്ള കഴിവിൽ ദൃശ്യമായ പ്രത്യാഘാതങ്ങളുള്ള ട്രാഫിക് നയ തിരഞ്ഞെടുപ്പാണ്.
റൂട്ട് ചേർക്കൽ എന്തുകൊണ്ട് നിലവിലുള്ള-എൻട്രി പിശക് തിരികെ നൽകി എന്ന് ഇത് വിശദീകരിക്കുന്നില്ല, അതിനെ സാർവത്രിക പരിഹാരമായി സ്വീകരിക്കുന്നത് യഥാർത്ഥ സംഘർഷത്തെ നയമാറ്റത്തിന് പിന്നിൽ ഒളിപ്പിക്കുന്നു. പ്രൊഫൈൽ എഡിറ്റിന് ശേഷം നിങ്ങളുടെ പ്രാദേശിക വിഭവങ്ങൾ എത്തിച്ചേരാനാകാത്തതായാൽ, ഈ ഫ്ലാഗ് ആദ്യം പരിശോധിക്കേണ്ട കാര്യങ്ങളിലൊന്നാണ്; റൂട്ട് ചേർക്കൽ പരാജയപ്പെട്ടാൽ, ഇത് ഉത്തരമല്ല.
ഏത് ലക്ഷ്യങ്ങൾ പ്രാദേശികമായി തുടരും എന്നതിനെക്കുറിച്ചുള്ള തീരുമാനമായി ഇതിനെ കാണുക, ബോധപൂർവം എടുത്ത് എഴുതിവെക്കുക. ലോഗ് ആശങ്കാജനകമായി തോന്നുമ്പോൾ പരീക്ഷിക്കാനുള്ള സ്വിച്ചല്ല ഇത്.
ലൂപ്പ് അടയ്ക്കുക: ഇരട്ടിപ്പ് അതിന്റെ ഉറവിടത്തിൽ നീക്കുക
ഏത് ഉടമയാണ് എൻട്രി കൈവശം വെക്കുന്നതെന്ന് അറിഞ്ഞാൽ, നിർദ്ദേശം നിർവചിച്ചിരിക്കുന്നിടത്ത് നിന്ന് ഇരട്ടിച്ച നിർദ്ദേശം നീക്കുക. അത് പ്രൊഫൈലിലെ route വരിയോ സർവറിൽ നിന്നുള്ള push-ഓ ഇനി പ്രവർത്തിപ്പിക്കേണ്ട ആവശ്യമില്ലാത്ത ഹുക്കോ ആകാം.
ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5
journalctl -u openvpn-client@office -b --no-pager | tail -n 15
തുടർന്ന് വീണ്ടും കണക്റ്റ് ചെയ്ത് മൂന്ന് കാര്യങ്ങൾ ഉറപ്പാക്കുക: ടണൽ ഉയരുന്നു, ഉദ്ദേശിച്ച ലക്ഷ്യം നിങ്ങൾ ആഗ്രഹിച്ച വഴിയിലേക്ക് പരിഹരിക്കപ്പെടുന്നു, പരാജയം അതിന്റെ സ്ഥാനത്ത് പുതിയത് വരാതെ അപ്രത്യക്ഷമാകുന്നു. തെറ്റായി തിരഞ്ഞെടുത്ത വഴിയുള്ള വ്യക്തമായ ലോഗ് പരിഹാരമല്ല.
പ്രിഫിക്സ് ഒരു വശത്ത് പ്രാദേശിക LAN-ഉം മറുവശത്ത് വിദൂര നെറ്റ്വർക്കും അർത്ഥമാക്കുന്നുവെങ്കിൽ, പ്രശ്നം ഇരട്ടിപ്പല്ല വിലാസ ഓവർലാപ്പാണ്, എത്ര മായ്ച്ചാലും രണ്ട് അർത്ഥങ്ങളും ഒരേസമയം ശരിയാകില്ല. ആ കേസിന് രണ്ട് നെറ്റ്വർക്കുകളിൽ ഒന്നിന് മറ്റൊരു പ്ലാൻ വേണം. ഏതെങ്കിലും തൊടുന്നതിന് മുൻപ് ഏത് വശം പുനർനമ്പർ ചെയ്യുമെന്ന് തീരുമാനിക്കുക.