ഗേറ്റ്‌വേയോ ഫോർവേഡ് ചെയ്ത ക്ലയന്റോ? സോഴ്‌സ് വിലാസം വായിക്കൽ

വെബ് സർവർ ഒരു വിലാസം രേഖപ്പെടുത്തുന്നു, അത് ഗേറ്റ്‌വേയുടെ സ്വന്തം പ്രോസസ്സിന്റേതാണെന്ന് എല്ലാവരും കരുതുന്നു. വിവർത്തന ഘട്ടത്തിൽ സ്വകാര്യ വിലാസം അപ്രത്യക്ഷമായ ഒരു ഫോർവേഡ് ചെയ്ത ക്ലയന്റിന്റേതാകാം. ലക്ഷ്യസ്ഥാനം കാണുന്ന നെറ്റ്‌വർക്ക് സോഴ്‌സ് മാത്രം കാണുന്നു, അതിൽ കൂടുതലൊന്നുമില്ല. ഇത് ഒരു അതിർത്തി പ്രസ്താവനയാണ്, ഉത്ഭവം ഒരിക്കലും സ്ഥാപിക്കാനാവില്ലെന്ന വാദമല്ല.

ലക്ഷ്യസ്ഥാനം യഥാർത്ഥത്തിൽ കാണുന്നത്

10.20.0.7-ൽ ഒരു ക്ലയന്റ്, പുറം വിലാസം 198.51.100.10 ആയ ഒരു ഗേറ്റ്‌വേ, ഇന്റർനെറ്റിലെ ഒരു ലക്ഷ്യസ്ഥാനം എന്നിവ എടുക്കുക. ഗേറ്റ്‌വേ ക്ലയന്റിന്റെ സോഴ്‌സ് വിവർത്തനം ചെയ്താൽ, ലക്ഷ്യസ്ഥാനത്തിന്റെ സോക്കറ്റ് 198.51.100.10 രേഖപ്പെടുത്തുന്നു. സ്വകാര്യ വിലാസം പാക്കറ്റിൽ നിന്ന് പോകുന്നു, ആ ഹെഡറിൽ നിന്ന് ലക്ഷ്യസ്ഥാനത്തിന് അത് വീണ്ടും വായിക്കാനാവില്ല. ഈ സംഖ്യകൾ ഉദാഹരണത്തിനുള്ളതാണ്, നിങ്ങളുടെ നെറ്റ്‌വർക്കിൽ നിന്നുള്ള ഒരു ക്യാപ്ചർ അല്ല.

നിരീക്ഷണം ഇപ്പോഴും ഉപകാരപ്രദമാണ്: ലക്ഷ്യസ്ഥാനം അനുവദിക്കേണ്ടതോ തടയേണ്ടതോ ആയ നെറ്റ്‌വർക്ക് സോഴ്‌സ് ഇത് തിരിച്ചറിയുന്നു. അതിന് പിന്നിലെ വ്യക്തിയെയോ പ്രോസസ്സിനെയോ മാത്രം തിരിച്ചറിയുന്നില്ല. ലക്ഷ്യസ്ഥാനത്തിന്റെ ഓപ്പറേറ്റർക്ക്, ഈ വ്യത്യാസം തടയൽ ഒരു നെറ്റ്‌വർക്ക് തീരുമാനമാണോ അക്കൗണ്ട് തീരുമാനമാണോ എന്ന് നിർണ്ണയിക്കുന്നു.

വിവർത്തന അവസ്ഥ ലക്ഷ്യസ്ഥാനത്തിന് ദൃശ്യമല്ല

വിവർത്തനം ചെയ്ത കണക്ഷനും യഥാർത്ഥ ക്ലയന്റും തമ്മിലുള്ള മാപ്പിംഗ് ഗേറ്റ്‌വേ സൂക്ഷിക്കുന്നു, ലക്ഷ്യസ്ഥാനത്തിന് ഇല്ലാത്തത് കൃത്യമായി ആ അവസ്ഥയാണ്. പരമ്പരാഗത NAT വിവരണം വിവർത്തന രേഖയെ പിന്നീട് ദൃശ്യമാകുന്ന ഹെഡറുകളിൽ നിന്ന് വേർതിരിക്കുന്നു. ഒരു വശം വായിച്ചാൽ മറുവശം ലഭിക്കുന്നില്ല.

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

conntrack -L -s 198.51.100.10
tcpdump -ni eth0 host 198.51.100.10

TTL-ഉം വിരലടയാളങ്ങളും സൂചനകളാണ്, തെളിവല്ല

IPv4-ലെ TTL അയച്ചയാൾ തിരഞ്ഞെടുക്കുന്ന പ്രാരംഭ മൂല്യത്തെയും പാക്കറ്റ് കടന്ന ഹോപ്പുകളുടെ എണ്ണത്തെയും ആശ്രയിച്ചിരിക്കുന്നു. രണ്ട് വസ്തുതകളും ഇല്ലാതെ, ഒരു മൂല്യത്തിന് VPN ഹോപ്പ് സംഭവിച്ചുവെന്ന് തെളിയിക്കാനാവില്ല. അറിയപ്പെടുന്ന അധിക റൂട്ട് ചെയ്ത ഹോപ്പിനും LAN റൗട്ടർ, ടണൽ പാത, അല്ലെങ്കിൽ മറ്റൊരു ഫോർവേഡിംഗ് ക്രമീകരണം എന്നിവ തമ്മിൽ വേർതിരിക്കാനാവില്ല. TTL വ്യത്യാസത്തെ ഒരു ചോദ്യമായി കാണുക, നിഗമനമായി അല്ല.

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

വിലാസം കൊണ്ടല്ല, ഐഡന്റിറ്റി കൊണ്ട് അധികാരപ്പെടുത്തുക

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

തെളിവുകൾ ലേബലോടെ സൂക്ഷിക്കുക: നിരീക്ഷിച്ച സോഴ്‌സ്, പ്രാമാണീകരിച്ച അക്കൗണ്ട്, സമയം, പരിഗണനയിലുള്ള അനുമാനം. «ഇവിടെ ആന്തരിക സോഴ്‌സ് കാണുന്നില്ല» എന്നതിനെ «എവിടെയും ആരോപണം സാധ്യമല്ല» എന്ന് വിവർത്തനം ചെയ്യരുത്. മാസങ്ങൾക്ക് ശേഷം അന്വേഷണത്തിന്റെ ഭാഗമല്ലാത്ത ഒരാൾ രേഖ വായിക്കുമ്പോൾ ലേബൽ പ്രധാനമാണ്.

നിരീക്ഷണത്തിന്റെ തീയതിയും അത് നിർമ്മിച്ച സിസ്റ്റവും രേഖപ്പെടുത്തുക. ആരോപണമില്ലാത്ത ലോഗ് ഭാഗം പിന്നീട് പ്രതിരോധിക്കാൻ ബുദ്ധിമുട്ടാണ്.