VPN ഡയറക്ടറിക്ക് അതിന് പിന്നിലെ നോഡിന് ഉറപ്പ് നൽകാൻ കഴിയാത്തത് എന്തുകൊണ്ട്
ഒരു എൻട്രി ഒരു കണക്ഷനെയും അത് പ്രസിദ്ധീകരിച്ച ഡയറക്ടറിയെയും വിവരിക്കുന്നു. ശേഖരണവും സൂക്ഷിക്കലും ഓപ്പറേറ്ററുടേതാണ്, അയാൾ മറ്റൊരു കക്ഷിയായിരിക്കാം.
ഡയറക്ടറിയുടെ ഈ കാര്യങ്ങൾ പട്ടികപ്പെടുത്തുന്ന എൻട്രികൾ: ഹോസ്റ്റ്നാമം, രാജ്യം, പ്രോട്ടോക്കോളുകളുടെ ഒരു കൂട്ടം കണക്ടിവിറ്റിയെക്കുറിച്ചുള്ള തെളിവാണ്, മറുവശത്തുള്ള യന്ത്രം എന്ത് രേഖപ്പെടുത്തുന്നു എന്നതിനെക്കുറിച്ചല്ല. ഇവിടെ പ്രധാനമായ തീരുമാനം പട്ടികകളെ പൊതുവെ വിശ്വസിക്കണോ എന്നതല്ല. നിങ്ങൾ യഥാർത്ഥത്തിൽ ചോദിക്കുന്ന ചോദ്യത്തിന് ഉത്തരം നൽകാൻ ഏത് കക്ഷിക്ക് കഴിയും എന്നതാണ്.
ഒരു എൻട്രിക്ക് പിന്നിലെ നാല് കക്ഷികൾ
ഏതെങ്കിലും വാഗ്ദാനം വായിക്കുന്നതിന് മുമ്പ് റോളുകൾ വേർതിരിക്കുക. ഡയറക്ടറി എൻട്രി പ്രസിദ്ധീകരിക്കുന്നു, സോഫ്റ്റ്വെയർ പ്രോജക്ട് പ്രോട്ടോക്കോൾ നടപ്പാക്കൽ നൽകുന്നു, ഹോസ്റ്റിംഗ് ദാതാവ് യന്ത്രവും നെറ്റ്വർക്കും നൽകുന്നു, നോഡ് ഓപ്പറേറ്റർ സേവനം ക്രമീകരിക്കുന്നു. നാലിൽ ആരും വേറെ സംഘടനയാകാം, ഓരോരുത്തർക്കും സ്വന്തം ഭാഗത്തെക്കുറിച്ച് മാത്രമേ സംസാരിക്കാനാകൂ.
ഈ വിഭജനം വിശദീകരിക്കുന്നത് ഒരു പ്രസ്താവന ശരിയായിരിക്കുകയും എന്നിട്ടും ഉപയോഗശൂന്യമാകുകയും ചെയ്യാം എന്നതാണ്. പ്രോട്ടോക്കോൾ ഉള്ളടക്കം രേഖപ്പെടുത്തുന്നില്ല എന്ന് രേഖപ്പെടുത്തുന്ന ഡെവലപ്പർ, റിലേയിൽ വിശദമായ കണക്ഷൻ ലോഗിംഗ് സജീവമാക്കിയ ഓപ്പറേറ്ററെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. രണ്ട് പ്രസ്താവനകളും വൈരുദ്ധ്യമില്ലാതെ ഒരുമിച്ച് നിലനിൽക്കാം. അതുകൊണ്ടാണ് ചോദ്യം പേരിട്ട ഒരു കക്ഷിയോട് ചോദിക്കേണ്ടത്.
ചില സേവനങ്ങൾ അവരുടെ സ്വന്തം എൻഡ്പോയിന്റുകൾ നടത്തുന്നു, അപ്പോൾ എൻട്രിയും നയവും ഒരേ കക്ഷിയിൽ നിന്നാണ് വരുന്നത്. അത് കൂടുതൽ ശക്തമായ സ്ഥാനമാണ്, പക്ഷേ പേജിന്റെ രൂപത്തിൽ നിന്ന് അനുമാനിക്കാതെ അത് സ്ഥാപിക്കേണ്ടതുണ്ട്. പ്രസ്താവന ആവശ്യപ്പെടുക, എൻട്രി ചൂണ്ടുന്ന സേവനം അത് പേരിടുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക.
അവകാശവാദത്തിന് യോജിക്കുന്ന രേഖ ആവശ്യപ്പെടുക
ശേഖരണത്തെക്കുറിച്ചുള്ള അവകാശവാദത്തിന് സിസ്റ്റം, ഡാറ്റാ വിഭാഗം, കാലയളവ് എന്നിവ പേരിടുന്ന രേഖ വേണം. സൂക്ഷിക്കലിനെക്കുറിച്ചുള്ള അവകാശവാദത്തിന് ഒരു സംഖ്യയും പരിധിയും വേണം. സ്വാതന്ത്ര്യത്തെക്കുറിച്ചുള്ള അവകാശവാദത്തിന് ആർ എന്ത് സ്വന്തമാക്കുന്നു എന്ന വിവരണം വേണം, വിശേഷണമല്ല.
| Field in a listing | What it evidences | What it cannot evidence |
|---|---|---|
| Hostname or address | A reachable endpoint existed when the entry was published | Who runs it, or what it stores |
| Protocols offered | Which client configurations should interoperate | Whether logging was disabled on that deployment |
| Country | Where the endpoint claims to be located | Which legal process could reach the operator |
| Availability score | How often the entry answered a probe | Anything about data handling |
സ്വയംസേവക പ്രോജക്ടുകൾ പലപ്പോഴും ഏറ്റവും വ്യക്തമായ ഉദാഹരണമാണ്, കാരണം ചിലത് അവർ സ്വീകരിക്കുന്ന നോഡുകൾക്ക് വ്യക്തമായ ലോഗിംഗ് ആവശ്യകതകൾ പ്രസിദ്ധീകരിക്കുന്നു. ആ രേഖ പ്രോജക്ടിന്റെ നിയമങ്ങളെക്കുറിച്ചുള്ള പ്രാഥമിക തെളിവാണ്, അവ അവഗണിച്ച ഒരു വ്യക്തിഗത ഓപ്പറേറ്ററെക്കുറിച്ചുള്ള തെളിവല്ല ഇപ്പോഴും.
ഓഡിറ്റുകൾ അതേ യുക്തി മറ്റൊരു തോതിൽ പിന്തുടരുന്നു. ഒരു നിർദ്ദിഷ്ട വിന്യാസം ഒരു നിർദ്ദിഷ്ട കാലയളവിൽ പരിശോധിച്ച റിപ്പോർട്ട് ആ പരിധിക്കുള്ളിൽ ഉപയോഗപ്രദമാണ്. അതേ സോഫ്റ്റ്വെയറിന്റെ ഓരോ സ്വതന്ത്ര പകർപ്പിലേക്കും നീട്ടിയാൽ, അത് ആരും നൽകാത്ത ഉറപ്പായി മാറുന്നു. തീരുമാനം വായിക്കുന്നതിന് മുമ്പ് പരിധിയെക്കുറിച്ചുള്ള ഖണ്ഡിക വായിക്കുക.
ഒരു വിൽപ്പനക്കാരന്റെ സ്വകാര്യതാ പ്രസ്താവന അവരുടെ സ്വന്തം സേവനത്തെ ഉൾക്കൊള്ളുമ്പോൾ, അത് ആ വിൽപ്പനക്കാരൻ തന്റെ സ്വന്തം സിസ്റ്റങ്ങളെക്കുറിച്ചുള്ള പ്രസ്താവനയായി വായിക്കുക. മൂന്നാം കക്ഷിയുടെ റിലേ വിവരിക്കാൻ അത് വീണ്ടും ഉപയോഗിക്കുന്നത് വിഭാഗീയമായ പിശകാണ്, പ്രോട്ടോക്കോൾ ഒന്നുതന്നെയായാലും.
ഓരോ ഓപ്ഷനും കൊണ്ട് നിങ്ങൾ എന്ത് വാങ്ങുന്നു എന്ന് തീരുമാനിക്കുക
ഒരു പൊതു നോഡ് ഉത്തരവാദിത്വത്തിന്റെ വിലയ്ക്ക് എത്തിച്ചേരലും വൈവിധ്യവും വാങ്ങുന്നു. നിങ്ങളോട് കടപ്പെട്ടിട്ടില്ലാത്ത ഒരു ഓപ്പറേറ്റർക്ക് അപ്രത്യക്ഷമാകാം, ക്രമീകരണം മാറ്റാം, അറിയിപ്പില്ലാതെ രേഖകൾ സൂക്ഷിക്കാം, നിങ്ങളുടെ പോംവഴി ഇതിൽ ഒതുങ്ങുന്നു: എൻഡ്പോയിന്റുകൾ മാറ്റുന്നത്. ഈ കൈമാറ്റം ചില ജോലികൾക്ക് സ്വീകാര്യമാണ്, മറ്റുള്ളവയ്ക്കല്ല.
പണം നൽകുന്ന സേവനം പ്രസിദ്ധീകരിച്ച നയവും നഷ്ടപ്പെടാൻ ഉള്ളതും ഉള്ള ഒരു എതിർകക്ഷിയെ വാങ്ങുന്നു. അത് സാങ്കേതിക ഉറപ്പ് വാങ്ങുന്നില്ല, നയം വായിക്കേണ്ടതിന്റെ ആവശ്യം നീക്കുന്നുമില്ല, പക്ഷേ സൂക്ഷിക്കൽ പ്രസ്താവനയുള്ള പേരുള്ള സംഘടന അജ്ഞാതമായ റിലേയെക്കാൾ എളുപ്പം വിലയിരുത്താനാകും.
രണ്ട് സാഹചര്യങ്ങളിലും നിലനിൽക്കുന്ന തീരുമാന നിയമം തെളിവിനെ അപകടസാധ്യതയുമായി യോജിപ്പിക്കുക എന്നതാണ്. ജോലി മാറുന്ന എൻഡ്പോയിന്റിനെ സഹിക്കുന്നുവെങ്കിൽ, ഡയറക്ടറി കാര്യക്ഷമമായ ഉപകരണമാണ്. അത് ഒരു നിർദ്ദിഷ്ട ഡാറ്റാ കൈകാര്യം ചെയ്യൽ വാഗ്ദാനത്തെ ആശ്രയിക്കുന്നുവെങ്കിൽ, ആ വാഗ്ദാനം നൽകാൻ കഴിയുന്ന കക്ഷി മാത്രമാണ് പ്രസക്തം, ഡയറക്ടറി ഉറപ്പല്ല, റൂട്ടിംഗ് സൗകര്യമാണ്.
curl -s --interface tun0 https://example.net/ -o /dev/null -w '%{remote_ip}
'മുകളിലെ ഒരു കമാൻഡ് പ്രവർത്തിപ്പിക്കുന്നത് മൂല്യവത്താണ്, കാരണം അത് രണ്ട് ചോദ്യങ്ങളെ വ്യക്തമായി വേർതിരിക്കുന്നു. നിങ്ങളുടെ ട്രാഫിക് യഥാർത്ഥത്തിൽ ഉപയോഗിച്ച വിലാസം അത് കാണിക്കുന്നു, അത് കണക്ടിവിറ്റിയുടെ വസ്തുതയാണ്, ആ വിലാസത്തിന്റെ ഓപ്പറേറ്റർ കണക്ഷന്റെ മെറ്റാഡാറ്റയുമായി എന്ത് ചെയ്തു എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നുമില്ല.
ക്ലയന്റ് വശത്തെ ചോദ്യങ്ങൾ വേർതിരിച്ച് വയ്ക്കുക
ഓപ്പറേറ്ററുടെ നയം ഒരു പാളിയാണ്, ടണലിലൂടെ നിങ്ങൾ ചെയ്യുന്നതിന്റെ സുരക്ഷ മറ്റൊന്നാണ്. ലക്ഷ്യസ്ഥാനത്തെ HTTPS, ബ്രൗസറിലെ സെഷൻ കൈകാര്യം, നിങ്ങൾ പ്രവേശിച്ച അക്കൗണ്ടിന്റെ ശക്തി എന്നിവ നിങ്ങളുടെ നിയന്ത്രണങ്ങളായി തുടരുന്നു, അനുവദനീയമായ റിലേ അവയെ ദുർബലമാക്കുന്നില്ല, മികച്ചത് അവയെ ശക്തിപ്പെടുത്തുന്നുമില്ല.
ഈ വേർതിരിക്കൽ രണ്ട് സാധാരണ തെറ്റുകൾ തടയുന്നു. കർശനമായ ഓപ്പറേറ്റർ നയത്തെ HTTPS ഒഴിവാക്കാനുള്ള കാരണമായി കാണുന്നത് ഒന്ന്, പ്രവർത്തിക്കുന്ന HTTPS കണക്ഷനെ റിലേ ആര് നടത്തുന്നു എന്നത് അവഗണിക്കാനുള്ള കാരണമായി കാണുന്നത് മറ്റൊന്ന്. രണ്ട് തെറ്റുകളും രണ്ട് പാളികളെ ഒന്നാക്കി ചേർത്ത് പിന്നീട് തെറ്റായതിനെക്കുറിച്ച് തർക്കിക്കുന്നു.
ചെറിയ എഴുത്തുരൂപ മൂല്യനിർണ്ണയം രണ്ടിനെയും കൈകാര്യം ചെയ്യുന്നു. ഓരോ വാഗ്ദാനം നൽകുന്ന കക്ഷിയെ പേരിടുക, അതിനെ പിന്തുണയ്ക്കുന്ന രേഖ അറ്റാച്ച് ചെയ്യുക, തീയതി രേഖപ്പെടുത്തുക. തുടർന്ന് ജോലിക്ക് ശക്തമായ അവകാശവാദം വേണോ അതോ പ്രവർത്തിക്കുന്ന ഒരു വഴി മാത്രം മതിയോ എന്ന് തീരുമാനിക്കുക.
എൻട്രി നിങ്ങൾക്ക് എവിടെ കണക്ട് ചെയ്യാമെന്ന് പറഞ്ഞ നിമിഷം അത് തന്റെ ജോലി ചെയ്തു. ചോദ്യത്തിന്റെ ബാക്കി ഭാഗം ആ എൻഡ്പോയിന്റ് നടത്തുന്നയാൾക്കാണ്, സത്യസന്ധമായ ഉത്തരം പലപ്പോഴും നിങ്ങൾക്ക് അറിയാനാകില്ല, അതനുസരിച്ച് തിരഞ്ഞെടുക്കണം എന്നതാണ്.