TCP റീസെറ്റ് നിങ്ങളുടെ VPN ബ്ലോക്ക് ചെയ്യപ്പെടുന്നു എന്ന് തെളിയിക്കുന്നില്ല

ക്ലയന്റ് ലോഗിൽ “കണക്ഷൻ റീസെറ്റ് ചെയ്തു, വീണ്ടും ആരംഭിക്കുന്നു” എന്ന് പ്രത്യക്ഷപ്പെടുന്നു, തീരുമാനം തെളിവിന് മുമ്പ് എത്തുന്നു. നെറ്റ്വർക്ക് VPN ബ്ലോക്ക് ചെയ്യുന്നു, അല്ലെങ്കിൽ സർട്ടിഫിക്കറ്റ് തെറ്റാണ്, അല്ലെങ്കിൽ ഒരു നിർദ്ദിഷ്ട രാജ്യം ഇടപെടുന്നു എന്ന് ആരോ തീരുമാനിക്കുന്നു. റീസെറ്റ് എന്നത് ഒരു കണക്ഷൻ അവസാനിപ്പിക്കുന്ന TCP പാക്കറ്റാണ്, ലോഗ് വരി നിങ്ങളുടെ ക്ലയന്റിന് ഒന്ന് ലഭിച്ചു എന്ന് രേഖപ്പെടുത്തുന്നു. അത് അയച്ച ഉപകരണമോ കാരണമോ പേരിടുന്നില്ല.

റീസെറ്റ് ഒരു പാക്കറ്റാണ്, വിധിയല്ല

TCP റീസെറ്റ് പ്രോസസ്സിംഗ് നിർവചിക്കുന്നു: RST ഫ്ലാഗുള്ള സെഗ്മെന്റ് കണക്ഷൻ ഉടൻ അവസാനിപ്പിക്കുന്നു. സ്വീകർത്താവ് ചർച്ച ചെയ്യുന്നില്ല, വീണ്ടും ശ്രമിക്കുന്നില്ല, എന്തുകൊണ്ടെന്ന് ചോദിക്കുന്നില്ല. അത് റീസെറ്റ് റിപ്പോർട്ട് ചെയ്ത് മുന്നോട്ട് പോകുന്നു.

ക്ലയന്റിന് അറിയാവുന്നത് അത്രമാത്രം. RST സർവറിൽ നിന്നോ, ഒരു പ്രോക്സിയിൽ നിന്നോ, ഒരു ഫയർവാളിൽ നിന്നോ, അവസ്ഥ നഷ്ടപ്പെട്ട ഒരു ലോഡ് ബാലൻസറിൽ നിന്നോ വന്നിരിക്കാം.

ഉറവിടം കണ്ടെത്തുന്നത് വേറിട്ട ഒരു അഭ്യാസമാണ്. ക്യാപ്ചറിൽ കാണുന്ന ഉറവിട വിലാസം ഭൗതിക ഉറവിടത്തിന്റെ തെളിവല്ല, അതിന് പിന്നിലെ നയ തീരുമാനത്തെക്കുറിച്ച് ഒന്നും പറയുന്നുമില്ല. ഇടനില ഉപകരണങ്ങൾക്ക് വിലാസങ്ങൾ വ്യാജമാക്കാം, അവസ്ഥയുള്ള ഉപകരണങ്ങൾക്ക് ഉദ്ദേശ്യത്താലല്ല, സമയപരിധി കഴിഞ്ഞ് റീസെറ്റ് ചെയ്യാം. റീസെറ്റിനെ വിധിയായി കാണുന്നത് സത്യം കണ്ടെത്തുന്ന ഭാഗം ഒഴിവാക്കുന്നു.

ഏത് കണക്ഷനാണ് റീസെറ്റ് ചെയ്തതെന്ന് സ്ഥിരീകരിക്കുക

ആദ്യം സജീവ പ്രൊഫൈൽ യഥാർത്ഥത്തിൽ TCP ഉപയോഗിക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക. UDP ടണലിൽ റീസെറ്റിന് അർത്ഥമില്ല, HTTP പ്രോക്സിയുടെ ലോഗ് VPN-ൽ നിന്ന് വ്യത്യസ്തമായ TCP ഭാഗത്തെക്കുറിച്ചാകാം.

ലക്ഷ്യം, പോർട്ട്, ശ്രമത്തിന്റെ സമയം, ക്ലയന്റ് എത്തിയ ഘട്ടം എന്നിവ രേഖപ്പെടുത്തുക.

ഘട്ടമാണ് ഏറ്റവും ഉപയോഗപ്രദമായ ഫീൽഡ്. TLS ഹാൻഡ്ഷേക്കിനിടയിലെ റീസെറ്റ് ഒരു കൂട്ടം സംശയിതരെ ചൂണ്ടിക്കാണിക്കുന്നു; പ്രാമാണീകരണത്തിന് ശേഷമുള്ള റീസെറ്റ് മറ്റൊരു കൂട്ടത്തെ. ഘട്ടമില്ലാതെ എല്ലാ സിദ്ധാന്തവും യോജിക്കുന്നു.

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

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

കഴിയുമെങ്കിൽ ക്ലയന്റിലും സർവറിലും ക്യാപ്ചർ ചെയ്യുക. ക്ലയന്റിൽ കാണുന്നതും സർവറിൽ കാണാത്തതുമായ റീസെറ്റ് സർവറിൽ ഉത്ഭവിച്ചിട്ടില്ല.

ഇരു ദിശകളിലും RST സെഗ്മെന്റുകൾ ശ്രദ്ധിക്കുക:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

നിയന്ത്രിത താരതമ്യത്തിലൂടെ ചുരുക്കുക

രണ്ടാമത്തെ അംഗീകൃത നെറ്റ്വർക്കിന് പരാജയം ക്ലയന്റിനെയാണോ പാതയെയാണോ പിന്തുടരുന്നതെന്ന് പറയാനാകും. അതേ പ്രൊഫൈൽ മറ്റെവിടെയെങ്കിലും പ്രവർത്തിക്കുന്നുവെങ്കിൽ, ക്ലയന്റ് കോൺഫിഗറേഷൻ കുഴപ്പമില്ലാതിരിക്കാം, ചരം പാതയാണ്.

ഇത് ഇപ്പോഴും ഒരു നിർദ്ദിഷ്ട ഇടനില ഉപകരണം തിരിച്ചറിയുന്നില്ല. ഇത് പരിധി ഒരു റൂട്ടിലേക്ക് ചുരുക്കുന്നു, അത് ഉപയോഗപ്രദവും സത്യസന്ധവുമായ ഫലമാണ്.

“ഈ പാത പരാജയപ്പെടുന്നു” എന്നതും “ഈ പേരിട്ട പ്രവർത്തകനാണ് അതുണ്ടാക്കിയത്” എന്നതും തമ്മിലുള്ള വ്യത്യാസം നിലനിർത്തുക. ആദ്യത്തേത് പരിശോധിക്കാനാകും; രണ്ടാമത്തേത് സാധാരണയായി ഒരു ക്ലയന്റിൽ നിന്നല്ല.

വിശ്വാസ ക്രമീകരണങ്ങൾ മാറ്റാതെ പരിഹാരം പരിശോധിക്കുക

TLS പരിശോധന പ്രവർത്തനരഹിതമാക്കരുത്, ക്രെഡൻഷ്യലുകൾ വീണ്ടും സൃഷ്ടിക്കരുത്, ഒരു റീസെറ്റ് വരിയുടെ അടിസ്ഥാനത്തിൽ ബ്ലോക്കിംഗ് നയം പ്രഖ്യാപിക്കരുത്. ഈ മാറ്റങ്ങളിൽ ഓരോന്നും പരീക്ഷിക്കപ്പെടുന്ന സിസ്റ്റം മാറ്റുകയും അടുത്ത താരതമ്യത്തെ അർത്ഥശൂന്യമാക്കുകയും ചെയ്യുന്നു.

തിരിച്ചറിഞ്ഞ ഘടകം അതിന്റെ ഉടമയിലൂടെ പരിഹരിക്കുക, തുടർന്ന് അതേ പ്രൊഫൈലും അതേ നിരീക്ഷണവും ആവർത്തിക്കുക:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

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