VPN വീണ്ടും ബന്ധിപ്പിച്ചു, പക്ഷേ ആപ്പ് സെഷൻ ഇപ്പോഴും പരാജയപ്പെടുന്നു

ടണൽ തിരികെ വരുന്നു, ക്ലയന്റ് ബന്ധിപ്പിച്ചതായി പറയുന്നു, എന്നാൽ ബ്രൗസർ വിച്ഛേദത്തിനു മുൻപ് ലോഡ് ചെയ്തിരുന്ന പേജിൽ ഇപ്പോഴും കറങ്ങുന്നു. VPN വീണ്ടും ബന്ധിപ്പിക്കൽ ഒരു വഴി പുനഃസ്ഥാപിക്കുന്നു, ആപ്പുകളും ദൂരവശവും പഴയ വഴിയിൽ സ്വരൂപിച്ച ബന്ധനാവസ്ഥ പുനഃസ്ഥാപിക്കുന്നില്ല. ഇവ പരിഹരിക്കാനുള്ള രണ്ട് വ്യത്യസ്ത കാര്യങ്ങളാണ്, ഇവ കൂട്ടിക്കലർത്തുന്നത് കാരണമില്ലാതെ VPN ക്രമീകരണങ്ങളിലേക്ക് തിരികെ അയയ്ക്കും.

ഒരു പരിശോധന ഇവയെ വ്യക്തമായി വേർതിരിക്കുന്നു, അതിന് പത്ത് സെക്കൻഡ് മതി. പഴയ അഭ്യർത്ഥന തൂങ്ങിനിൽക്കുമ്പോൾ അതേ ലക്ഷ്യത്തിലേക്ക് പുതിയ അഭ്യർത്ഥന അയയ്ക്കൂ.

വീണ്ടും ബന്ധിപ്പിക്കലിൽ എന്ത് നിലനിൽക്കുന്നു, എന്ത് നിലനിൽക്കുന്നില്ല

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

ചില ക്ലയന്റുകൾ വീണ്ടും ബന്ധിപ്പിക്കുമ്പോൾ പഴയ ബന്ധങ്ങൾ വലിച്ചെറിയുന്ന ഒരു ഹുക്ക് ചേർക്കുന്നു, മിക്കതും ചേർക്കുന്നില്ല. ഇവിടെയുള്ള സ്വഭാവം ക്ലയന്റ്, പ്ലാറ്റ്ഫോം, പതിപ്പ് എന്നിവയനുസരിച്ച് മാറുന്നു.

ദൂരവശം നിങ്ങളെയും മറന്നു

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

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

പുതിയ അഭ്യർത്ഥനയാണ് ഇവയെ വേർതിരിക്കുന്ന പരിശോധന

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

പരിശോധനയിൽ നേരിട്ടുള്ള ട്രാഫിക്കിന്റെ ഏതെങ്കിലും തടയൽ അതിന്റെ സ്ഥാനത്ത് നിർത്തൂ. ആകസ്മികമായ ഒരു ബദൽ വഴിയിലൂടെ വിജയിക്കുന്ന അഭ്യർത്ഥന ടണലിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല.

പഴയതല്ല, പുതിയ ബന്ധം കൊണ്ട് ഉറപ്പാക്കൂ

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

ss -tanp | grep -E ':(443|8443)'
curl -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 https://intranet.example.com/
conntrack -L 2>/dev/null | grep 8443
dig +short intranet.example.com

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

തടസ്സത്തിന്റെ സമയം, വീണ്ടും ബന്ധിപ്പിച്ച സമയം, പഴയതും പുതിയതുമായ അഭ്യർത്ഥനകൾ തമ്മിലുള്ള വ്യത്യാസം എന്നിവ രേഖപ്പെടുത്തൂ. ആ രേഖ അവ്യക്തമായ പരാതിയെ ആരെങ്കിലും നടപടിയെടുക്കാവുന്ന റിപ്പോർട്ടാക്കി മാറ്റുന്നു.