IPsec-നെ Shadowsocks കൊണ്ട് മാറ്റുന്നതിന് മുമ്പ് നഷ്ടപ്പെടുന്ന ജോലികൾ എഴുതിവയ്ക്കുക

മൂന്ന് സേവനങ്ങൾ, ഒരു ടണൽ: ഒരു വെബ് ആപ്പ്, ഒരു ഡാറ്റാബേസ്, ഒരു ഫയൽ പങ്കുവയ്ക്കൽ. ഓടിക്കാൻ എളുപ്പമെന്ന് പറഞ്ഞ് IPsec-ന് പകരം Shadowsocks കൊണ്ടുവരാൻ ആരോ നിർദ്ദേശിക്കുന്നു. തുടർന്നുള്ള എൻക്രിപ്ഷൻ ചർച്ച പ്രധാന കാര്യം വിടുന്നു, കാരണം ടണൽ ഒരേ സമയം പല ജോലികൾ ചെയ്യുന്നു, അവയിൽ ഒന്ന് മാത്രമാണ് സൈഫറുകളെക്കുറിച്ച്. ഉൽപ്പന്നങ്ങൾ താരതമ്യം ചെയ്യുന്നതിന് മുമ്പ് ആ ജോലികൾ എഴുതിവയ്ക്കുക. പട്ടിക ചെറുതാണ്, അതിലെ ഏതെങ്കിലും ഒരു ഇനം മാറ്റം അസാധുവാക്കാം.

ട്രാഫിക് എങ്ങനെ പിടിക്കപ്പെടുന്നു എന്നതിൽ തുടങ്ങുക

പ്രോട്ടോക്കോളിന് രണ്ട് പകുതികളുണ്ട്. ഒരു പ്രാദേശിക ഘടകം കണക്ഷൻ സ്വീകരിക്കുന്നു, ലക്ഷ്യ വിലാസത്തിൽ തുടങ്ങുന്ന സ്ട്രീം എൻക്രിപ്റ്റ് ചെയ്ത് വിദൂര ഘടകത്തിലേക്ക് അയയ്ക്കുന്നു. വിദൂര പകുതി ആ ലക്ഷ്യത്തിലേക്ക് കണക്ഷൻ തുറന്ന് ബൈറ്റുകൾ കൈമാറുന്നു. UDP ഡാറ്റാഗ്രാമുകളോടെ അതേ രൂപം പിന്തുടരുന്നു. ഇത് അത് പിടിക്കുന്ന സ്ട്രീമുകൾക്കുള്ള ഫോർവേഡിംഗ് ആണ്, പിടിക്കാത്ത സ്ട്രീമുകളെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. പ്രോക്സിയോട് വ്യക്തമായി സംസാരിക്കുന്ന ആപ്പ് എളുപ്പമാണ്; ബാക്കിയെല്ലാം പിടിക്കപ്പെടാൻ അഡാപ്റ്ററോ റൂട്ടിംഗ് നിയമങ്ങളോ വേണം.

മറ്റെന്തെങ്കിലും താരതമ്യം ചെയ്യുന്നതിന് മുമ്പ് ഓരോ ആപ്പിനും പിടിക്കുന്ന രീതി രേഖപ്പെടുത്തുക. പിടിക്കപ്പെടാത്ത ട്രാഫിക് സാധാരണ വഴിയിലൂടെ പുറത്തുപോകുന്നു, ഒരു സേവനം ഓഫീസിന് പുറത്ത് വ്യത്യസ്തമായി പെരുമാറുന്നതുവരെ ആരും ശ്രദ്ധിക്കുന്നില്ല.

ഓരോ ലക്ഷ്യത്തിനും പ്രോട്ടോക്കോളിനും പേര് നൽകുക

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

വൃത്തിയുള്ള രൂപകൽപ്പനകളെ തകർക്കുന്ന കേസുകൾ ചേർക്കുക: ആന്തരിക DNS, പ്രോക്സി ക്രമീകരണങ്ങൾ അവഗണിക്കുന്ന ആപ്പുകൾ, സെർവറിൽ നിന്ന് ക്ലയന്റിലേക്ക് തുടങ്ങേണ്ട ഏതെങ്കിലും സ്ട്രീം. ഓരോന്നിനും അനുമാനമല്ല, വ്യക്തമായ ക്രമീകരണം വേണം.

എൻക്രിപ്ഷൻ അനുമതിയല്ല

Shadowsocks-ലെ രേഖപ്പെടുത്തിയ AEAD രീതികൾ പ്രാമാണീകൃത എൻക്രിപ്ഷൻ നൽകുന്നു, അതിനാൽ മുഴുവൻ കുടുംബത്തെയും അസുരക്ഷിതമെന്ന് തള്ളിക്കളയുന്നത് തെറ്റാണ്. ആ വസ്തുത ആക്സസ് ചോദ്യത്തിന് ഉത്തരം നൽകാൻ അനുവദിക്കുന്നതും അത്ര തന്നെ തെറ്റാണ്. ആര് ഏത് സേവനത്തിൽ എത്തുന്നു, ഒരാൾ പോകുമ്പോൾ ആക്സസ് എങ്ങനെ ഒഴിവാക്കുന്നു, രഹസ്യങ്ങൾ എവിടെ സൂക്ഷിക്കുന്നു, ഏത് ഘടകം അതിർത്തി നടപ്പാക്കുന്നു എന്നിവ ആരോ തീരുമാനിക്കണം. ഒരു പങ്കിട്ട രഹസ്യം ഓരോ ഉടമയ്ക്കും ഒരേ പരിധി നൽകുന്നു, ഒരാളെ ഒഴിവാക്കുന്നത് എല്ലാവർക്കുമുള്ള റൊട്ടേഷനായി മാറുന്നു.

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

ഇന്ന് ഇരുവശത്തുമുള്ള നിയന്ത്രണങ്ങൾ പട്ടികപ്പെടുത്തുക, എന്നിട്ട് ഏത് വിടവുകളോടെ ജീവിക്കാമെന്ന് വിലയിരുത്തുക.

പ്രവർത്തന ജോലി എണ്ണുക

ഓരോ മാറ്റത്തിനും ക്ലയന്റ് പാക്കേജുകൾ, സെർവർ അപ്ഡേറ്റുകൾ, ക്രെഡൻഷ്യൽ റൊട്ടേഷൻ, പരാജയ കൈകാര്യം എന്നിവയ്ക്ക് ഉത്തരവാദിയെ വേണം. ടണൽ ലഭ്യമല്ലാത്തപ്പോൾ ഓരോ ആപ്പും എന്ത് ചെയ്യുന്നു എന്ന് ശ്രദ്ധിക്കുക: പരാജയപ്പെടുന്നു, പ്രാദേശിക വഴിയിൽ വീണ്ടും ശ്രമിക്കുന്നു, അല്ലെങ്കിൽ കാത്തിരിക്കുന്നു. ആ പെരുമാറ്റം വിന്യാസത്തിൽ നിന്ന് വരുന്നതാണ്, പ്രോട്ടോക്കോളിന്റെ പേരിൽ നിന്നല്ല.

ഒരു വെബ് ആപ്പിന് ഇടുങ്ങിയ പ്രോക്സി മതിയാകാം. ഓരോ വ്യക്തിക്കും അനുമതികളോടെ മുഴുവൻ നെറ്റ്വർക്കിലേക്കുള്ള ആക്സസിന്, അധിക ഭാഗങ്ങൾ സാധാരണയായി അവ മാറ്റിയ ടണലിനെക്കാൾ ചെലവേറിയതാണ്.

തീരുമാനം ഏത് ഉൽപ്പന്നം സുരക്ഷിതമെന്ന് തോന്നുന്നു എന്നതല്ല. പട്ടികപ്പെടുത്തിയ ജോലികൾ ടീം യഥാർത്ഥത്തിൽ പരിപാലിക്കുന്ന നിയന്ത്രണങ്ങളോടെ പൂർത്തിയാക്കുന്ന രൂപകൽപ്പന ഏതാണ് എന്നതാണ്.