ഫോർവേഡ് ചെയ്ത VPN പോർട്ട്: സന്ദർശകരും ദാതാവും എന്ത് കാണാം

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

മൂന്ന് വസ്തുക്കൾ, മൂന്ന് വ്യത്യസ്ത ചോദ്യങ്ങൾ

പൊതു വിലാസത്തെ അതിനു പിന്നിൽ ഉത്തരം നൽകുന്ന ആപ്പ്‌ലിക്കേഷനിൽ നിന്ന് വേർതിരിച്ചു നിർത്തുക, രണ്ടിനെയും ഈ കാര്യം നടത്തുന്ന വ്യക്തിയിൽ നിന്നോ സംഘടനയിൽ നിന്നോ വേർതിരിച്ചു നിർത്തുക. ഓരോന്നിനും സ്വന്തം പ്രേക്ഷകരും സ്വന്തം തെളിവുകളും ഉണ്ട്. ഇവ കൂട്ടിക്കലർത്തിയാൽ വ്യവസ്ഥാപിതമായി തോന്നുന്നതും തെറ്റായതുമായ നിഗമനങ്ങൾ വരുന്നു.

ആ ക്രമത്തിൽ അവ പരിശോധിക്കുക. ആദ്യത്തേത് പ്രാപ്യതയുടെ ചോദ്യമാണ്, രണ്ടാമത്തേത് ആപ്പ്‌ലിക്കേഷൻ ഐഡന്റിറ്റിയുടെ ചോദ്യമാണ്, മൂന്നാമത്തേത് ആരോപണത്തിന്റെ ചോദ്യമാണ്, അതിന് ആദ്യത്തെ രണ്ടെണ്ണം ഭാഗികമായി മാത്രം വെളിച്ചം നൽകുന്നു. പോർട്ട് ഫോർവേഡിംഗ് സ്വകാര്യമാണോ എന്ന് ആരെങ്കിലും ചോദിച്ചാൽ, മൂന്നിൽ ഏതിനെയാണ് ഉദ്ദേശിക്കുന്നതെന്ന് ചോദിക്കുക. ഉത്തരങ്ങൾ യഥാർത്ഥത്തിൽ വ്യത്യസ്തമാണ്, നയ പേജ് സാധാരണയായി അവയിൽ ഒന്നിനെ മാത്രം പരിഗണിക്കുന്നു.

എൻഡ്‌പോയിന്റുകൾക്കിടയിൽ സന്ദർശകന് എന്ത് ബന്ധിപ്പിക്കാം

സന്ദർശകൻ എൻഡ്‌പോയിന്റിലേക്ക് ബന്ധിപ്പിക്കുന്നു, ആപ്പ്‌ലിക്കേഷൻ നിയമാനുസൃതമായി അവതരിപ്പിക്കുന്നത് കാണുന്നു: 'ഹോസ്റ്റ്നെയിം', സർട്ടിഫിക്കറ്റിന്റെ പേര്, ലോഗിൻ പേജ്, പ്രസിദ്ധീകരിച്ച ഉള്ളടക്കം. ഈ വിശദാംശങ്ങൾ സേവനത്തിന്റെ സാധാരണ പ്രവേശന വിലാസം ടണലിനു പിന്നിൽ മറഞ്ഞിരിക്കുമ്പോഴും അതിനെ തിരിച്ചറിയിക്കുന്നു. ഒരേ പേരിലുള്ള സൈറ്റ് അവതരിപ്പിക്കുന്ന രണ്ട് എൻഡ്‌പോയിന്റുകൾ നിരീക്ഷകർക്ക് അവ ബന്ധിപ്പിക്കാൻ അടിസ്ഥാനം നൽകുന്നു. ഈ പെരുമാറ്റത്തിൽ ചോർച്ചയില്ല, കാരണം ആപ്പ്‌ലിക്കേഷൻ കാണപ്പെടാൻ വേണ്ടിയാണ് രൂപകൽപ്പന ചെയ്തത്.

രണ്ട് എൻഡ്‌പോയിന്റുകൾക്കിടയിൽ സർട്ടിഫിക്കറ്റുകൾ, റീഡയറക്ടുകൾ, പേജ് ഉള്ളടക്കം എന്നിവ ഒത്തുപോകുന്നത് അവ ഒരേ സേവനത്തിന്റേതാണെന്നുള്ള ശക്തമായ സൂചനയാണ്. മറ്റൊരു രേഖ രണ്ടിനെയും ബന്ധിപ്പിക്കുന്നതുവരെ അത് സേവനത്തെക്കുറിച്ചുള്ള പ്രസ്താവനയായി തുടരുന്നു, മനുഷ്യനെക്കുറിച്ചല്ല.

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

ഫോർവേഡിംഗ് ദാതാവ് എന്ത് അറിയണം

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

ചരിത്രപരമായ മാപ്പിംഗുകൾ, അക്കൗണ്ട് ബന്ധങ്ങൾ, കണക്ഷൻ രേഖകൾ എന്നിവ നിലനിൽക്കുന്നുണ്ടോ എന്നത് ദാതാവിന്റെ യഥാർത്ഥ നയത്തിന്റെയും നടപ്പാക്കലിന്റെയും ചോദ്യമാണ്. ഫോർവേഡിംഗ് ഓരോ വിഭാഗവും രേഖപ്പെടുത്തുന്നു എന്ന് തെളിയിക്കുന്നില്ല. മാപ്പിംഗ് പിൻവലിച്ചതിനുശേഷം ഏത് ഫീൽഡുകൾ അവശേഷിക്കുന്നു, എത്ര കാലം എന്ന് പ്രത്യേകം ചോദിക്കുക.

ഇൻകമിംഗ് പ്രാപ്യത ക്ലയന്റിന്റെ ഔട്ട്ഗോയിംഗ് റൂട്ടിംഗിൽ നിന്നും DNS-ൽ നിന്നും പരാജയ സ്വഭാവത്തിൽ നിന്നും വേറിട്ടതാണ്. ഒരു മാപ്പിംഗ് ചേർക്കുന്നത് ക്ലയന്റിന്റെ ബാക്കി ട്രാഫിക് എങ്ങനെ പുറത്തുപോകുന്നു എന്ന് വിവരിക്കുന്നില്ല.

മാപ്പിംഗ് എത്ര കാലം നിലനിൽക്കുന്നു എന്നത് എക്സ്പോഷറിനെ മാറ്റുന്നു

ഒരു മാപ്പിംഗ് ഒരു സെഷനിലേക്കോ റിസർവേഷനിലേക്കോ അത് മാറ്റുന്ന ദാതാവിന്റെ നയപ്രകാരമോ നിലനിൽക്കാം. സ്ഥിരമായ അനുവദനയോ തുടർച്ചയായ റൊട്ടേഷനോ അനുമാനിക്കരുത്; ഉൽപ്പന്നത്തിന്റെ രേഖപ്പെടുത്തിയ സ്വഭാവം വായിക്കുകയും നിരീക്ഷിക്കുന്നത് രേഖപ്പെടുത്തുകയും ചെയ്യുക. ഒരാഴ്ച ഇടവേളയിലുള്ള രണ്ട് നിരീക്ഷണങ്ങൾ 'റൊട്ടേഷനെ'ക്കുറിച്ച് ഉൽപ്പന്ന പേജിലെ ഏത് മാർക്കറ്റിംഗ് വാക്യത്തെക്കാളും കൂടുതൽ പറയുന്നു. നിരീക്ഷിച്ച ഇടവേള നിങ്ങളുടെ കുറിപ്പുകളിൽ എൻഡ്‌പോയിന്റിന് അടുത്ത് എഴുതുക, കാരണം ഇടവേള എക്സ്പോഷറിന്റെ ഭാഗമാണ്.

ആയുസ്സ് ഏത് പരസ്പരബന്ധം സാധ്യമാണ് എന്നത് മാറ്റുന്നു. സ്ഥിരമായ എൻഡ്‌പോയിന്റ് ഒരു സേവനത്തിന്റെ ദീർഘകാല ട്രാക്കിംഗിനെ ക്ഷണിക്കുന്നു, ഭ്രമണം ചെയ്യുന്നത് ഓരോ നിരീക്ഷണവും മുൻപത്തേതുമായി ബന്ധിപ്പിക്കാൻ ബുദ്ധിമുട്ടാക്കുന്നു. രണ്ട് സ്വഭാവങ്ങളും ദാതാവിന്റെ രേഖകളെക്കുറിച്ചുള്ള ഉറപ്പല്ല, ഒന്നും സേവനം തന്നെ എന്ത് പ്രസിദ്ധീകരിക്കുന്നു എന്ന തീരുമാനത്തെ മാറ്റിസ്ഥാപിക്കുന്നുമില്ല.

ബോധപൂർവം പ്രസിദ്ധീകരിക്കുക, പിന്നീട് രണ്ട് വാതിലുകളും അടയ്ക്കുക

ദാതാവ് ആവശ്യമായ പ്രോട്ടോക്കോൾ അനുവദിക്കുന്നു, ലക്ഷ്യ ശ്രോതാവ് നിങ്ങൾ ഉദ്ദേശിച്ചതു തന്നെ, ഹോസ്റ്റ്, ആപ്പ്‌ലിക്കേഷൻ നിയന്ത്രണങ്ങൾ ഇപ്പോഴും പ്രവേശനം പരിമിതപ്പെടുത്തുന്നു എന്ന് ഉറപ്പാക്കുക. പ്രസിദ്ധീകരിക്കുന്നതിന് മുമ്പ് സേവനം അപരിചിതനോട് എന്ത് അവതരിപ്പിക്കും എന്ന് നോക്കുക. ഈ രണ്ട് കമാൻഡുകൾ സന്ദർശകന് ലഭിക്കുന്ന സർട്ടിഫിക്കറ്റും ഹെഡറുകളും കാണിക്കുന്നു.

openssl s_client -connect pub.example.net:443 -brief < /dev/null
curl -sSI https://pub.example.net/

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

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