TCP 443 ശരിക്കും സഹായിക്കുന്നുണ്ടോ? സെർവർ അവിടെ കേൾക്കുന്നുവെങ്കിൽ മാത്രം
TCP പ്രൊഫൈൽ ഒരു പകരവഴിയാണ്, വേഷമല്ല. സെർവർ ആ പോർട്ടിൽ കേൾക്കുന്നുണ്ടെന്ന് പരിശോധിച്ച്, ഇരട്ട TCP-യുടെ ചെലവ് എത്തിച്ചേരാനാകാതിരിക്കുന്നതിനോട് തുലനം ചെയ്യുക.
TCP 443 ഒരു മുൻവ്യവസ്ഥയുള്ള പകരവഴിയാണ്, ഏതെങ്കിലും ഫിൽട്ടറിനെ കടന്ന് ടണൽ കൊണ്ടുപോകുന്ന വേഷമല്ല. ഓപ്പറേറ്റർ ഇതിനകം ആ പോർട്ടിൽ TCP ശ്രോതാവ് പ്രസിദ്ധീകരിച്ചിട്ടുണ്ടെങ്കിലും പാത മണിക്കൂറുകളോളം തുറന്നിരിക്കുന്ന കണക്ഷൻ സഹിക്കുന്നുവെങ്കിലും അത് സഹായിക്കുന്നു. ഇവയിൽ ഒന്ന് ഇല്ലെങ്കിൽ അത് സാധാരണയായി സമയപരിധിയായി പരാജയപ്പെടുന്നു, സമയപരിധി ഏതാണ് വിട്ടുപോയതെന്ന് അപൂർവ്വമായി മാത്രം പറയുന്നു. മാറണോ എന്ന തീരുമാനത്തിന് മൂന്ന് ചോദ്യങ്ങൾ വേണം, അവയിൽ ഒന്ന് മാത്രമാണ് പോർട്ട് നമ്പറിനെക്കുറിച്ച്.
പോർട്ട് നമ്പർ ഗതാഗതത്തിന്റെ വാഗ്ദാനമല്ല
പോർട്ട് ഒരു അന്തിമബിന്ദുവിന് പേര് നൽകുന്നു; TCP അതിനെ ക്രമീകൃത ബൈറ്റ് പ്രവാഹമാക്കുന്നു; OpenVPN ആ പ്രവാഹത്തിനുള്ളിൽ എന്ത് സഞ്ചരിക്കുന്നു എന്ന് തീരുമാനിക്കുന്നു. അതേ നമ്പറിലുള്ള ഒരു വെബ് സെർവർ തികച്ചും വ്യത്യസ്തമായ അപ്ലിക്കേഷൻ ക്രമീകരണം ഉപയോഗിക്കുന്നു, അതിനാൽ 443 പോർട്ട് പങ്കിടുന്നത് രണ്ടിനെയും ഫിൽട്ടറിന് സമാനമായി കാണിക്കുന്നു, അതിൽ കൂടുതലില്ല. നമ്പർ ഫിൽട്ടർ വായിക്കുന്ന ഒരു സൂചനയാണ്, പാക്കറ്റുകളിലുള്ളത് മാറ്റുന്ന ഗുണമല്ല. പോർട്ട് പങ്കിടുന്നതുകൊണ്ട് രണ്ടിനെയും ഒന്നായി കാണുന്നതാണ് ഇവിടത്തെ മിക്ക ആശയക്കുഴപ്പത്തിനും പിന്നിലുള്ള തെറ്റ്.
ഇടനില ഉപകരണങ്ങൾ ഒരു പോർട്ടിനെക്കുറിച്ച് ലളിതമായ അനുവദിക്കുക-അല്ലെങ്കിൽ-വിലക്കുക തീരുമാനം അപൂർവ്വമായി മാത്രം എടുക്കുന്നു. പലതും ആദ്യ ബൈറ്റുകൾ പരിശോധിക്കുന്നു, ചിലത് ലക്ഷ്യം ഉറപ്പിക്കുന്നു, മറ്റു ചിലത് വളരെനേരം തുറന്നിരിക്കുന്ന കണക്ഷനുകൾ പുനഃസജ്ജമാക്കുന്നു. അതുകൊണ്ടാണ് ഒരേ പ്രൊഫൈൽ ഒരു നെറ്റ്വർക്കിൽ നിന്ന് പ്രവർത്തിക്കുകയും മറ്റൊന്നിൽ നിന്ന് സമയപരിധിയിൽ എത്തുകയും ചെയ്യുന്നത്, അതുകൊണ്ടാണ് പകരവഴിയെ വാഗ്ദാനമായി വിശ്വസിക്കുന്നതിനുപകരം പിന്തുണയുള്ള ഓപ്ഷനായി പരീക്ഷിക്കേണ്ടത്. ഫിൽട്ടർ ട്രാഫിക് പരിശോധിക്കുമ്പോൾ പോർട്ട് നമ്പർ അത് നോക്കുന്ന ആദ്യ കാര്യം മാത്രമാണ്.
പ്രൊഫൈൽ തൊടുന്നതിന് മുൻപ് ശ്രോതാവ് ഉറപ്പാക്കുക
സെർവർ പോർട്ടിൽ TCP-ക്കായി ക്രമീകരിച്ചിരിക്കണം, ക്ലയന്റ് പ്രൊഫൈൽ അതേ ഗതാഗതം ആവശ്യപ്പെടണം. UDP പ്രൊഫൈൽ TCP ആവശ്യപ്പെടാൻ വീണ്ടും എഴുതുന്നത് ശ്രോതാവിനെ സൃഷ്ടിക്കുന്നില്ല, ഉണ്ടാകുന്ന സമയപരിധി പോർട്ട് വിട്ടുകളയുന്ന ഫയർവാളിൽ നിന്ന് വേർതിരിക്കാനാകില്ല. ഓപ്പറേറ്ററുടെ സ്വന്തം TCP പ്രൊഫൈൽ ഉണ്ടെങ്കിൽ ഡൗൺലോഡ് ചെയ്യുക, കാരണം ചില സേവനങ്ങൾ ഓരോ ഗതാഗതത്തിനും പ്രത്യേക അന്തിമബിന്ദുവും പ്രത്യേക ഐഡന്റിറ്റി ക്രമീകരണങ്ങളും പ്രസിദ്ധീകരിക്കുന്നു. കൈകൊണ്ട് തിരുത്തൽ നിയന്ത്രിത പരീക്ഷണത്തിന് നല്ലതാണ്, ദാതാവ് ഉദ്ദേശിച്ച ക്രമീകരണം ഊഹിക്കാനുള്ള മോശം വഴിയാണ്.
ആ പൊരുത്തത്തിന്റെ ഇരുവശവും ക്രമീകരണത്തിൽ കാണാം, OpenVPN പ്രോജക്ടിന്റെ ലിങ്ക് ഓപ്ഷനുകൾ രണ്ട് രൂപങ്ങളും രേഖപ്പെടുത്തുന്നു. ഏറ്റവും ചെറിയ ജോടി ഇങ്ങനെ കാണപ്പെടുന്നു:
# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443മൂന്ന് വ്യവസ്ഥകൾ പകരവഴി ലാഭകരമാണോ എന്ന് തീരുമാനിക്കുന്നു
ആദ്യ വ്യവസ്ഥ, ഓപ്പറേറ്റർ ആ ഗതാഗതം ഒട്ടും വാഗ്ദാനം ചെയ്യുന്നു എന്നതാണ്; അതില്ലാതെ മറ്റൊന്നും പ്രധാനമല്ല. രണ്ടാമത്തേത്, പാത ദീർഘകാല സെഷൻ ജീവനോടെ നിർത്തുന്നു എന്നതാണ്, കാരണം ചില നെറ്റ്വർക്കുകൾ പോർട്ട് പൂർണ്ണമായി തടയുന്നതിനുപകരം തുറന്നിരിക്കുന്ന കണക്ഷനുകൾ പുനഃസജ്ജമാക്കുന്നു. മൂന്നാമത്തേത്, പകരവഴി ഉദ്ദേശ്യപൂർവ്വമുള്ള ഒഴിവാക്കലാണോ അതോ നിങ്ങൾ പരിഹരിക്കാത്ത ഒരു തകരാർ മറയ്ക്കുന്ന താൽക്കാലിക പരിഹാരമാണോ എന്നതാണ്.
ഓരോ വ്യവസ്ഥയ്ക്കും വിലകുറഞ്ഞ പരിശോധനയുണ്ട്. അവയിലേതെങ്കിലും പരാജയപ്പെട്ടാൽ ക്ലയന്റിന്റെ ഭാഗത്തുനിന്ന് ഒരേപോലെ കാണപ്പെടുന്നു:
| Condition | How to check it | What a failure decides |
|---|---|---|
| The server offers TCP | The operator's profile list, or a listening-socket check on the server | No client-side edit can help |
| The path keeps long sessions | A test connection left open for an hour | Reconnects will look like server faults |
| The fallback is deliberate | A change record naming the UDP fault | The underlying fault stays invisible |
ഗതാഗതങ്ങൾ താരതമ്യം ചെയ്യുന്നതിന് മുൻപ് ക്യാപ്റ്റീവ് പോർട്ടലിലെ ഏതെങ്കിലും സൈൻ-ഇൻ പൂർത്തിയാക്കുക. നിങ്ങളുടെ ഉപകരണം സ്വീകരിക്കാത്ത നെറ്റ്വർക്ക് രണ്ട് ഗതാഗതങ്ങളെയും തടയുന്നു, അപ്പോൾ താരതമ്യം ടണലിനെയല്ല, പോർട്ടലിനെ അളക്കുന്നു. സൈൻ ഇൻ ചെയ്യുക, സാധാരണ ബ്രൗസിംഗ് പ്രവർത്തിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക, അതിനുശേഷം മാത്രം പരീക്ഷണം ആരംഭിക്കുക.
നിങ്ങൾ സ്വീകരിക്കുന്ന ചെലവ്: TCP-യ്ക്കുള്ളിൽ TCP
TCP നഷ്ടപ്പെട്ട സെഗ്മെന്റുകൾ വീണ്ടും അയച്ച് അവയുടെ ക്രമം സൂക്ഷിക്കുന്നു. തന്നെയും TCP ഉപയോഗിക്കുന്ന ഒരു അപ്ലിക്കേഷൻ TCP ടണലിനുള്ളിൽ പ്രവർത്തിക്കുമ്പോൾ, രണ്ട് വീണ്ടെടുപ്പ് പാളികൾ ഒരേ നഷ്ടത്തോട് പ്രതികരിക്കുന്നു, ആ പരസ്പരപ്രവർത്തനമാണ് നഷ്ടമുള്ള പാതയിൽ ടണലിനെ മന്ദഗതിയിലാക്കുന്നത്. ലക്ഷണം വൃത്തിയുള്ള പരാജയമല്ല, കാലതാമസവും വിറയലുമാണ്, അത് ദൂരെയുള്ള അറ്റത്തെ കുറ്റപ്പെടുത്തുന്നത് എളുപ്പമാക്കുന്നു. തീരുമാനത്തിൽ എത്തുന്നതിന് മുൻപ് ക്ലയന്റിൽ നിന്ന് രണ്ട് ഗതാഗതങ്ങളിലും അളക്കുക.
UDP ഈ കൂടുവയ്ക്കൽ ഒഴിവാക്കുന്നു, ഓപ്പറേറ്റർമാർ അത് ഇഷ്ടപ്പെടാനും TCP പകരമായി മാത്രം നൽകാനുമുള്ള പ്രധാന കാരണം അതാണ്. സ്ഥിരതയുള്ള TCP കണക്ഷൻ എത്തിച്ചേരാനാകാത്ത UDP കണക്ഷനെക്കാൾ ഇപ്പോഴും ഉപകാരപ്രദമാണ്, അതിനാൽ താരതമ്യം നല്ലതും ചീത്തയും ഓപ്ഷനുകൾക്കിടയിലല്ല, രണ്ട് യഥാർത്ഥ ചെലവുകൾക്കിടയിലാണ്. താരതമ്യം ചെയ്യുമ്പോൾ ഉപകരണവും ആക്സസ് നെറ്റ്വർക്കും മാറ്റമില്ലാതെ നിർത്തുക, അല്ലെങ്കിൽ ഫലം തെറ്റായ ചരത്തെ വിവരിക്കും.
ചില ക്ലയന്റ് സവിശേഷതകൾ ഒരു ഗതാഗതത്തിന് മാത്രം രേഖപ്പെടുത്തിയിട്ടുണ്ട്, അതിനാൽ പകര പ്രൊഫൈൽ നിങ്ങൾ ആശ്രയിച്ച സ്വഭാവം നിശ്ശബ്ദമായി ഒഴിവാക്കാം. TCP പ്രൊഫൈലിനെ ലളിതമായ മാറ്റമായി കാണുന്നതിന് മുൻപ് ഓപ്ഷന്റെ ഗതാഗത ആവശ്യകത വായിക്കുക.
മറ്റൊരു ഗതാഗതം തൊടാത്ത തകരാറുകൾ
കാലഹരണപ്പെട്ട സർട്ടിഫിക്കറ്റിന് ഇപ്പോഴും ക്ലോക്ക് പരിശോധനയോ പുതുക്കലോ വേണം, നിരസിക്കപ്പെട്ട അക്കൗണ്ടിന് ഇപ്പോഴും ശരിയായ ക്രെഡൻഷ്യലുകൾ വേണം. ഓപ്പറേറ്റർ നൽകിയ സെർവർ ഐഡന്റിറ്റി പരിശോധനകൾ നിലനിർത്തുക, കാരണം പരിചിതമായ പോർട്ട് നമ്പർ ആരെയും ആധികാരികമാക്കുന്നില്ല. മറുപടി നൽകുന്ന പോർട്ട് എന്തോ കേൾക്കുന്നുണ്ട് എന്ന് മാത്രം പറയുന്നു.
ടണൽ ഉയർന്നിട്ടും ലക്ഷ്യങ്ങൾ പരാജയപ്പെടുന്നുവെങ്കിൽ, ബാക്കിയുള്ള പ്രശ്നം കണക്ഷനുശേഷമുള്ള റൂട്ടിംഗോ നാമപരിഹാരമോ ആണ്, ഗതാഗതമല്ല. പോർട്ടുകൾ ചുറ്റിത്തിരിയുന്നതിനുപകരം ആ പാത പിന്തുടരുക, അങ്ങനെയാണ് ഒരു ഉച്ചയ്ക്കുശേഷം നഷ്ടപ്പെടുന്നത്. പ്രൊഫൈൽ ഏത് ഗതാഗതം പരീക്ഷിക്കണമെന്ന് പറയുന്നു; UDP പാത എന്തുകൊണ്ട് പരാജയപ്പെട്ടുവെന്ന് അത് ഒരിക്കലും പറയുന്നില്ല.