ഒന്നും പ്രവർത്തിക്കാതിരിക്കുമ്പോൾ VPN ബന്ധിപ്പിച്ചതായി തോന്നാമെന്തുകൊണ്ട്

നിങ്ങളുടെ ക്ലയന്റ് ബന്ധിപ്പിച്ചു എന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു, അതേസമയം ഇന്റർഫേസ് മുകളിലുണ്ട്, ബ്രൗസർ സമയം തീരുന്നു, ഈ മൂന്ന് പ്രസ്താവനകളിൽ ഒന്നും തെറ്റല്ല. ബന്ധിപ്പിച്ചു എന്നത് നിങ്ങൾ ആവശ്യപ്പെട്ട പേജുമായി യാതൊരു ബന്ധവുമില്ലാത്ത ഒരു പാളിയെ വിവരിക്കുന്നു. ഏത് പാളിയാണ് റിപ്പോർട്ട് ചെയ്യുന്നതെന്ന് തീരുമാനിക്കാൻ ഒരു പുതിയ അഭ്യർത്ഥനയും ട്രാഫിക് നീങ്ങിയത് തെളിയിക്കുന്ന കൗണ്ടറിലേക്ക് ഒരു നോട്ടവും വേണം. പുനരാരംഭം ആ തെളിവ് വലിച്ചെറിഞ്ഞ് നിങ്ങൾ നിരീക്ഷിക്കാൻ ശ്രമിച്ച വ്യവസ്ഥകൾ വീണ്ടും നിർമ്മിക്കുന്നു.

ബന്ധിപ്പിച്ചു എന്ന് വിളിക്കുന്ന മൂന്ന് വ്യത്യസ്ത കാര്യങ്ങൾ

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

അതിനാൽ പച്ച ഐക്കണും മരിച്ച ടണലും വൈരുദ്ധ്യമല്ല, പൊരുത്തപ്പെടുന്നവയാണ്; അവ വ്യത്യസ്ത വസ്തുക്കളെക്കുറിച്ച് റിപ്പോർട്ട് ചെയ്യുന്നു. ഈ പരാജയം വീണ്ടും വീണ്ടും ക്ലയന്റ് ബഗ് എന്ന് തെറ്റായി രോഗനിർണയം ചെയ്യപ്പെടുന്നതിന്റെ മുഴുവൻ കാരണം അതാണ്.

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

ഏത് കൗണ്ടറാണ് പാക്കറ്റുകൾ നീങ്ങിയത് തെളിയിക്കുന്നത്

IPsec-ൽ IKE അസോസിയേഷനും CHILD അസോസിയേഷനും വെവ്വേറെ വസ്തുക്കളാണ്, ഈ ചോദ്യത്തിന് ഉത്തരം നൽകുന്ന കൗണ്ടറുകൾ child-ന് മാത്രമാണുള്ളത്. child പട്ടികപ്പെടുത്തുക, പാക്കറ്റുകൾ ഇരു ദിശകളിലും കൂടുന്നുണ്ടോ എന്ന് നോക്കുക, അത് അപ്ലിക്കേഷൻ ചെയ്യാൻ ശ്രമിക്കുന്നതുമായി താരതമ്യം ചെയ്യുക. പൂജ്യത്തിൽ ഇൻസ്റ്റാൾ ചെയ്ത അസോസിയേഷൻ, അപ്ലിക്കേഷൻ ഇപ്പോഴും പരാജയപ്പെടുമ്പോൾ കൂടുന്ന അസോസിയേഷനിൽ നിന്ന് വ്യത്യസ്തമായ കണ്ടെത്തലാണ്; ആദ്യത്തേത് ട്രാഫിക് തിരഞ്ഞെടുക്കുന്നില്ല എന്നർത്ഥം, രണ്ടാമത്തേത് അത് നീങ്ങുന്നു, തകരാർ കൂടുതൽ മുന്നിലാണ് എന്നർത്ഥം. കൗണ്ടറുകൾ രണ്ടുതവണ വായിക്കുക, കുറച്ച് സെക്കൻഡുകളുടെ ഇടവേളയിൽ, കാരണം ഒരു സാമ്പിൾ പ്രവണത കാണിക്കാനാവില്ല.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

പൂജ്യം കൗണ്ടറുകൾ തിരഞ്ഞെടുപ്പിലേക്ക് ചൂണ്ടുന്നു: റൂട്ടിംഗ്, നയം, പാക്കറ്റ് പുറപ്പെട്ട നാമസ്ഥലം, അല്ലെങ്കിൽ ക്ലയന്റ് ഒരിക്കലും ബന്ധിപ്പിക്കാത്ത ഇന്റർഫേസ്. കൂടുന്ന കൗണ്ടറുകൾ ടണലിൽ നിന്ന് അകലെ ചൂണ്ടുന്നു, അതിനാൽ വിദൂര അറ്റത്തെ ഫോർവേഡിംഗ്, നാമ പരിഹാരം, മടങ്ങിവരവ് പാത, ലക്ഷ്യ സേവനം എന്ന ക്രമത്തിൽ തുടരുക. വെവ്വേറെ child വസ്തു ഇല്ലാത്ത പ്രോട്ടോക്കോൾ അതേ തെളിവ് സ്വന്തം പദങ്ങളിൽ വെളിപ്പെടുത്തുന്നു, അതിനാൽ IPsec പദാവലി കടം വാങ്ങുന്നതിന് പകരം സഹപ്രവർത്തകന്റെ അവസ്ഥയെയും പാക്കറ്റ് എണ്ണത്തെയും കുറിച്ച് അത് റിപ്പോർട്ട് ചെയ്യുന്നത് ഉപയോഗിക്കുക. വായനയുടെ രൂപം അത് ഉണ്ടാക്കിയ ഉപകരണത്തേക്കാൾ പ്രധാനമാണ്.

കൗണ്ടറുകൾ നീങ്ങിയ ശേഷം തകരാർ എവിടെയാണ്

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

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

പൊതു റിസോൾവർ വഴി പരിഹരിക്കപ്പെടുന്നതും എന്നാൽ ടണൽ റിസോൾവർ വഴി അല്ലാത്തതുമായ ഒരു നാമം DNS പാത തകർന്നു എന്നർത്ഥം, രണ്ടിലൂടെയും പരിഹരിക്കപ്പെട്ടിട്ടും ബ്രൗസറിൽ സമയം തീരുന്ന നാമം മടങ്ങിവരവ് പാതയെയോ സേവനത്തെയോ ചൂണ്ടുന്നു. വിലാസം വഴിയുള്ള ping വിജയിച്ചിട്ടും അപ്ലിക്കേഷൻ വിസമ്മതിക്കുന്നുവെങ്കിൽ, നെറ്റ്‌വർക്ക് അഭ്യർത്ഥന എത്തിച്ചു, സേവനം അത് നിരസിച്ചു, അത് പൂർണ്ണമായും പിന്നീടുള്ള ഘട്ടമാണ്.

ട്രിഗർ രേഖപ്പെടുത്തുക, പിന്നീട് ഒരു കാര്യം മാറ്റുക

പരാജയത്തിന് മുമ്പ് എന്ത് സംഭവിച്ചു എന്ന് രേഖപ്പെടുത്തുക: കുറച്ച് നിഷ്ക്രിയത, നെറ്റ്‌വർക്ക് മാറ്റം, കീ പുതുക്കൽ, വീണ്ടും തുടങ്ങിയ ലാപ്‌ടോപ്പ്, അല്ലെങ്കിൽ പുനഃസ്ഥാപിച്ച സിസ്റ്റം. ഇവ വ്യത്യസ്ത സംവിധാനങ്ങൾ സൃഷ്ടിക്കുന്നു, സാധാരണയായി പുനഃസ്ഥാപിച്ച സിസ്റ്റം മാത്രം സ്വയം നന്നാക്കുന്നു, അതാണ് നിങ്ങൾക്ക് ഒന്നും പഠിപ്പിക്കാത്ത സന്ദർഭം. പുനരാരംഭം സംഭവങ്ങളുടെ ക്രമം നീക്കം ചെയ്ത് പിന്നീട് കാരണം മറയ്ക്കാൻ മതിയായ അടുത്ത വ്യവസ്ഥകൾ വീണ്ടും സൃഷ്ടിക്കുന്നു. ട്രിഗർ ഇപ്പോഴും പുനർനിർമ്മിക്കാനാവുമ്പോൾ തന്നെ അത് എഴുതിവയ്ക്കുക.

പിന്നീട് ഒരു പിന്തുണയുള്ള തിരുത്ത് ചെയ്ത് യഥാർത്ഥ അഭ്യർത്ഥന പരാജയം ഉണ്ടാക്കിയ ട്രിഗറിനൊപ്പം ആവർത്തിക്കുക. നിഷ്ക്രിയത പുനർനിർമ്മിക്കാൻ ഏറ്റവും എളുപ്പമുള്ള ട്രിഗറാണ്, അതിനാൽ തിരുത്ത് ലക്ഷണത്തെയല്ല, സംവിധാനത്തെയാണ് അഭിസംബോധന ചെയ്തത് എന്നതിന്റെ ഏറ്റവും വേഗതയുള്ള സ്ഥിരീകരണമാണത്.

നിങ്ങൾ റിപ്പോർട്ട് ചെയ്യാൻ ആഗ്രഹിക്കുന്നത്, അയക്കാൻ ഉദ്ദേശിച്ച ട്രാഫിക് എത്താൻ ഉദ്ദേശിച്ച സേവനത്തിൽ എത്തി എന്നതിന്റെ തെളിവാണ്. പച്ചയാകുന്ന ഐക്കൺ, ലോഡ് ചെയ്യുന്ന കാഷെ പേജ്, നീങ്ങുന്ന കൗണ്ടർ എന്നിവയെല്ലാം ഉദ്ദേശിച്ച ലക്ഷ്യത്തിലേക്കുള്ള ഒരു പൂർത്തിയായ അഭ്യർത്ഥനയേക്കാൾ കുറച്ചേ തെളിയിക്കുന്നുള്ളൂ. അഭ്യർത്ഥന, കൗണ്ടർ വായന, ട്രിഗർ എന്നിവ ഒരുമിച്ച് സൂക്ഷിക്കുക, അടുത്തയാൾക്ക് തിരുത്തിനെ യാദൃച്ഛികതയിൽ നിന്ന് വേർതിരിക്കാൻ കഴിയും.