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

ചുവടെയുള്ള താരതമ്യം പ്രോസസിൽ നിന്ന് പുറത്തേക്ക് നീങ്ങുന്നു, കാരണം ഏത് ഫയലാണ് പ്രാബല്യത്തിലുള്ളതെന്ന് അറിയാൻ പ്രോസസ് മാത്രമാണ് അധികാരം.

നിങ്ങൾ തിരുത്തിയ ഫയലും പ്രോസസ് വായിക്കുന്ന ഫയലും

unit-ൽ നിന്നും അത് സൃഷ്ടിച്ച കമാൻഡ് ലൈനിൽ നിന്നും തുടങ്ങുക. systemd ഹോസ്റ്റിൽ systemctl cat openvpn@server ExecStart വരി അച്ചടിക്കുന്നു, ഇൻസ്റ്റൻസ് unit സാധാരണയായി അതിന്റെ കോൺഫിഗറേഷൻ പാത ഇൻസ്റ്റൻസിന്റെ പേരിൽ നിന്ന് കണക്കാക്കുന്നു, അതിനാൽ openvpn@office എന്ന് ആരംഭിച്ച ഡീമൺ openvpn@server എന്ന് ആരംഭിച്ചതിൽ നിന്ന് വ്യത്യസ്ത ഫയൽ വായിക്കുന്നു. ഇത് പ്രവർത്തിക്കുന്ന പ്രോസസിന്റെ argv-മായി താരതമ്യം ചെയ്യുക. കോൺഫിഗറേഷൻ മാനേജ്മെന്റ് ടൂൾ മാറ്റം നഷ്ടപ്പെടുത്താനുള്ള മറ്റൊരു വഴി കൂട്ടിച്ചേർക്കുന്നു: unit ഒരിക്കലും പറയാത്ത ഒരിടത്ത് ശരിയായ ഫയൽ എഴുതാം, അപ്പോൾ വിജയകരമായ ഡിപ്ലോയ്മെന്റ് ഒന്നും ചെയ്യാത്തതുപോലെ തോന്നും.

സമയമുദ്രകൾ ഇത് വേഗത്തിൽ തീർപ്പാക്കുന്നു: ഫയൽ പ്രോസസിന്റെ ആരംഭ സമയത്തേക്കാൾ പുതിയതാണെങ്കിൽ, പ്രോസസിന് അത് വായിക്കാൻ കഴിഞ്ഞിട്ടില്ല. റൂട്ടറിന്റെ ഫേംവെയർ മൂന്നാമത്തെ സാഹചര്യം കൂട്ടുന്നു, കാരണം പല മോഡലുകളും ക്രമീകരണങ്ങൾ flash-ൽ സൂക്ഷിച്ച് ബൂട്ട് സമയത്ത് കോൺഫിഗറേഷൻ വീണ്ടും നിർമ്മിക്കുന്നു, ഇത് ഡിസ്കിലെ ഫയൽ തിരുത്തലിനെ പൂർണ്ണമായും തെറ്റായ പാളിയാക്കുന്നു.

സെർവർ എന്ത് തള്ളുന്നു, ക്ലയന്റ് എന്ത് ഇൻസ്റ്റാൾ ചെയ്യുന്നു

അയച്ച റൂട്ട് രണ്ട് ഫിൽട്ടറുകളിലൂടെ കടക്കണം. സെർവറിൽ അത് ലോഡ് ചെയ്ത കോൺഫിഗറേഷനിൽ ഉണ്ടായിരിക്കണം, കമന്റ് ചെയ്ത ബ്ലോക്കിലോ പേര് ഒത്തുപോകാത്ത ക്ലയന്റ്-നിർദ്ദിഷ്ട ഫയലിലോ അല്ല. ക്ലയന്റിൽ pull സജീവമായിരിക്കണം, ഒരു pull-filter-ഉം ആ ഓപ്ഷൻ വലിച്ചെറിയരുത്. verbosity 4-ൽ ബന്ധിപ്പിച്ച് ക്ലയന്റ് റിപ്പോർട്ട് ചെയ്യുന്ന അയച്ച ഓപ്ഷനുകൾ വായിക്കുക: റൂട്ട് ആ ലിസ്റ്റിലുണ്ടെങ്കിൽ സെർവർ തന്റെ ജോലി ചെയ്തു, ഇൻസ്റ്റാൾ ചെയ്യാതിരിക്കാൻ തീരുമാനിക്കുന്നത് ക്ലയന്റാണ്.

ക്ലയന്റ്-നിർദ്ദിഷ്ട ഫയലുകൾ ആശയക്കുഴപ്പത്തിന്റെ സാധാരണ ഉറവിടമാണ്. സർട്ടിഫിക്കറ്റിന്റെ common name അനുസരിച്ച് പേരിട്ട ഫയൽ ആ ക്ലയന്റിന് മാത്രം ഓപ്ഷനുകൾ തള്ളുന്നു, ഒരു അക്ഷരത്തിന്റെ വ്യത്യാസം തള്ളൽ നിശബ്ദമായി നിർത്തുന്നു, ഇരുവശത്തും പിശക് കാണില്ല. സെർവർ ബന്ധിപ്പിക്കുമ്പോൾ കണ്ട common name രേഖപ്പെടുത്തുന്നു, അതിനാൽ ആ മൂല്യം ഫയലിന്റെ പേരുമായി താരതമ്യം ചെയ്യുക, ക്ലയന്റിന്റെ പേരെന്ന് നിങ്ങൾ കരുതുന്നതുമായി അല്ല.

അയച്ച പ്രിഫിക്സും തിരികെയുള്ള റൂട്ടും വ്യത്യസ്ത പ്രശ്നങ്ങളാണ്

സ്വന്തം പ്രാദേശിക ഇന്റർനെറ്റ് പാത നിലനിർത്താൻ redirect-gateway മനഃപൂർവം അവഗണിക്കുന്ന ക്ലയന്റ് രണ്ടാമതൊരു, ബന്ധമില്ലാത്ത വിടവ് സൃഷ്ടിക്കുന്നു. സെർവറിന്റെ പ്രോബുകൾ ടണൽ വിലാസത്തിൽ എത്തുന്നു, മറുപടികൾ ഒരിക്കലും വരുന്നില്ല, കാരണം സെർവറിന്റെ ടണൽ IP-യിലേക്കുള്ള മറുപടി ക്ലയന്റിന്റെ സാധാരണ ഡിഫോൾട്ട് ഗേറ്റ്വേയിലൂടെ റൂട്ട് ചെയ്യപ്പെടുന്നു. ഇവിടെ അയച്ച സബ്നെറ്റ് റൂട്ട് കുറ്റക്കാരനല്ല; ഇല്ലാത്തത് സെർവറിന്റെ ടണൽ നെറ്റ്വർക്കിലേക്കുള്ള ട്രാഫിക് ടണൽ ഉപകരണത്തിലേക്ക് തിരികെ അയക്കുന്ന റൂട്ടാണ്.

ക്ലയന്റിൽ ആ റൂട്ട് ചേർക്കുന്നത് സെർവർ ആരംഭിക്കുന്ന പ്രോബുകൾക്കുള്ള മറുപടികൾ ശരിയാക്കുന്നു. അത് അയച്ച സബ്നെറ്റ് റൂട്ടിന് പകരമല്ല, നേരെ തിരിച്ചും ശരിയാണ്, കാരണം രണ്ടും വിപരീത ദിശകളെ വിവരിക്കുന്നു.

ഇരു അറ്റങ്ങളിലെയും പട്ടികകൾ താരതമ്യം ചെയ്യുക

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

മൂന്ന് ഐഡന്റിഫയറുകൾ ഒരുമിച്ച് സൂക്ഷിക്കുക: കോൺഫിഗറേഷൻ പാത, unit അല്ലെങ്കിൽ ഇൻസ്റ്റൻസിന്റെ പേര്, നിങ്ങൾ പരീക്ഷിച്ച ക്ലയന്റ് ഐഡന്റിറ്റി.

ഈ മൂന്നും അടുത്ത സംഭവത്തെ വീണ്ടുമൊരു അന്വേഷണത്തിന് പകരം അഞ്ച് മിനിറ്റ് പരിശോധനയാക്കുന്നു; ടണൽ മറ്റൊരാളുടെ പ്രശ്നമാകുമ്പോൾ സഹപ്രവർത്തകന് വേണ്ടതും ഇവ തന്നെ.

പുനരാരംഭത്തെ അതിജീവിക്കുന്ന റൂട്ട് പ്രശ്നം പലപ്പോഴും റൂട്ടിംഗ് പ്രശ്നമേ അല്ല; തകരാറ് നിങ്ങൾ തുടർച്ചയായി വായിക്കുന്ന പട്ടികയ്ക്ക് മുകളിലാണ്.

അനുബന്ധ ലേഖനങ്ങൾ