ZeroTier-ന് മുകളിലുള്ള HTTP എൻക്രിപ്റ്റ് ചെയ്തിട്ടുണ്ടോ? ഓവർലേ എവിടെ അവസാനിക്കുന്നു എന്ന് പരിശോധിക്കുക

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

പരിശോധന 1: ബ്രൗസർ ഏത് വിലാസത്തിലേക്കാണ് ഡയൽ ചെയ്യുന്നതെന്ന് കണ്ടെത്തുക

URL യന്ത്രത്തിൽ യഥാർത്ഥത്തിൽ ഉള്ളതുമായി താരതമ്യം ചെയ്യുക. ip -brief addr show zt ഇന്റർഫേസും നെറ്റ്വർക്ക് കണ്ട്രോളർ നൽകിയ ഓവർലേ വിലാസവും കാണിക്കുന്നു; URL ആ വിലാസം ഉപയോഗിക്കുന്നുവെങ്കിൽ, ബ്രൗസറിന്റെ സോക്കറ്റ് ഓവർലേയിലേക്ക് പോകുന്നു.

പകരം പേര് ഒരു LAN വിലാസത്തിലേക്ക് റിസോൾവ് ചെയ്യുമ്പോൾ, ക്ലയന്റിന്റെ സ്റ്റാറ്റസ് സൂചകം എന്ത് പറഞ്ഞാലും ഓവർലേ ഒട്ടും ഉൾപ്പെട്ടെന്ന് വരില്ല. ip route get 10.147.20.5 കെർണൽ തിരഞ്ഞെടുക്കുന്ന ഇന്റർഫേസും സ്രോതസ്സ് വിലാസവും പ്രിന്റ് ചെയ്യുന്നു, അതിനാൽ അവിടെ zt ഇന്റർഫേസ് ഉണ്ടെങ്കിൽ പാക്കറ്റ് ഓവർലേയിൽ പ്രവേശിക്കുന്നു, നിങ്ങളുടെ ഭൗതിക NIC യുടെ പേരാണെങ്കിൽ പ്രവേശിക്കുന്നില്ല. പേരുകൾ മറ്റൊരു പാളി ചേർക്കുന്നു: ഓവർലേ വിലാസത്തിലേക്ക് ചൂണ്ടുന്ന ഒരു റെക്കോർഡ് LAN വിലാസത്തിലേക്ക് ചൂണ്ടുന്നതിൽ നിന്ന് വ്യത്യസ്തമായി പ്രവർത്തിക്കുന്നു, ഒരു സെർച്ച് സഫിക്സോ ഹോസ്റ്റ്സ് ഫയൽ എൻട്രിയോ ഏതാണ് ലഭിക്കുന്നതെന്ന് നിശബ്ദമായി തീരുമാനിക്കാം.

പരിശോധന 2: രണ്ട് അറ്റങ്ങളും പിയറുകളാണെന്ന്, ഡീക്രിപ്റ്റ് ചെയ്യുന്ന റിലേയല്ലെന്ന് ഉറപ്പാക്കുക

ZeroTier പിയറുകൾക്കിടയിൽ എൻക്രിപ്റ്റ് ചെയ്യുന്നു, നേരിട്ടുള്ള പാത ഇല്ലാത്തിടത്ത് പാക്കറ്റുകൾ ഇപ്പോഴും എൻക്രിപ്റ്റ് ചെയ്ത നിലയിൽ കൈമാറുന്ന ഒരു റൂട്ടിലൂടെ റിലേ ചെയ്യുന്നു. zerotier-cli peers ഓരോ പിയറിന്റെയും പാത DIRECT അല്ലെങ്കിൽ RELAY എന്ന് ലേറ്റൻസി കണക്കോടെ അടയാളപ്പെടുത്തുന്നു. റിലേ ചെയ്ത പാത റൗണ്ട് ട്രിപ്പുകൾ ചെലവാക്കുന്നു, രഹസ്യസ്വഭാവമല്ല.

ഉത്തരം മാറ്റുന്നത് യഥാർത്ഥത്തിൽ ഒരു എൻഡ്പോയിന്റ് അല്ലാത്ത ഒരു അംഗമാണ്. അപ്പുറം ഒരു ഭൗതിക LAN ലേക്ക് റൂട്ട് ചെയ്യുന്നതോ ബ്രിഡ്ജ് ചെയ്യുന്നതോ ആയ ZeroTier അംഗമാണെങ്കിൽ, ഓവർലേ ആ അംഗത്തിൽ അവസാനിക്കുന്നു, അടുത്ത ഹോപ്പ് സാധാരണ ഈഥർനെറ്റാണ്.

പരിശോധന 3: അഭ്യർത്ഥന വായിക്കാവുന്നതാകുന്ന സ്ഥലം നിരീക്ഷിക്കുക

പേജ് നൽകുന്നുവെന്ന് നിങ്ങൾ കരുതുന്ന ഹോസ്റ്റിൽ, റീലോഡ് ചെയ്യുമ്പോൾ ഓവർലേ ഇന്റർഫേസിൽ ക്യാപ്ചർ ചെയ്യുക: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. ആ ഔട്ട്പുട്ടിലെ വായിക്കാവുന്ന അഭ്യർത്ഥനാ വരി, ആ ഹോസ്റ്റിൽ ട്രാഫിക് ഡീക്രിപ്റ്റ് ചെയ്ത് എത്തിയെന്ന് തെളിയിക്കുന്നു, അതാണ് നിങ്ങൾ അന്വേഷിക്കുന്ന അതിർത്തി.

തുടർന്ന് ബാക്കി LAN ലേക്ക് അഭിമുഖീകരിക്കുന്ന ഇന്റർഫേസിൽ ക്യാപ്ചർ ചെയ്യുക. അതേ അഭ്യർത്ഥന അവിടെ അസംസ്കൃതമായി കാണപ്പെടുന്നുവെങ്കിൽ, അത് അപ്ലിക്കേഷനിൽ എത്തുന്നതിന് മുമ്പ് ഓവർലേ വിട്ടു, ആ ഭാഗത്തുള്ള എല്ലാ ഉപകരണത്തിനും അത് വായിക്കാം. LAN വശത്ത് ഒന്നും കാണാതെ പേജ് ഇപ്പോഴും ലോഡ് ആകുന്നുവെങ്കിൽ, അപ്ലിക്കേഷൻ ZeroTier ഹോസ്റ്റിൽ തന്നെ ടെർമിനേറ്റ് ചെയ്യുന്നു.

മുന്നിൽ ഒരു റിവേഴ്സ് പ്രോക്സി ഉള്ളപ്പോൾ ലൂപ്പ്ബാക്ക് ക്യാപ്ചർ ചെയ്യുന്നതും പ്രധാനമാണ്, കാരണം HTTPS സ്വീകരിച്ച് HTTP ഫോർവേഡ് ചെയ്യുന്ന പ്രോക്സി അതിർത്തി സ്വന്തം ബാക്ക് എൻഡിലേക്ക് നീക്കുന്നു.

പരിശോധന 4: റൂട്ടറിനോ ബ്രിഡ്ജിനോ പിന്നിലുള്ള ഓരോ ഹോപ്പും കണക്കിലെടുക്കുക

ഓവർലേയ്ക്കും LAN-നും ഇടയിൽ റൂട്ട് ചെയ്യാൻ ക്രമീകരിച്ച ഒരു അംഗം സാധാരണ രൂപകൽപ്പനയാണ്, ഈ അനുമാനങ്ങൾ കൂടുതലായി തകരുന്ന സ്ഥലവുമാണ്. ഓവർലേ ബ്രൗസർ-മുതൽ-റൂട്ടർ വരെയുള്ള ഭാഗം സംരക്ഷിക്കുന്നു, അതിന് ശേഷം ഒന്നുമില്ല. ഒരു ബ്രിഡ്ജ് വ്യത്യസ്ത സംവിധാനത്തിലൂടെ അതേ കഥ പറയുന്നു: ഓവർലേയും ഭൗതിക ഭാഗവും ഒരു ബ്രോഡ്കാസ്റ്റ് ഡൊമെയ്നായി മാറുന്നു, അതിനാൽ ബ്രിഡ്ജ് ചെയ്ത ലാപ്ടോപ്പിൽ നിന്നുള്ള ഒരു അഭ്യർത്ഥന ആ ലാപ്ടോപ്പ് ZeroTier നെറ്റ്വർക്കിൽ ഇരുന്നാലും സാധാരണ ഈഥർനെറ്റിലൂടെ കടന്നുപോകുന്നു.

അനുമാനിക്കാതെ അത് ട്രേസ് ചെയ്യുക. ക്ലയന്റിൽ നിന്ന് സേവന വിലാസത്തിലേക്കുള്ള traceroute, ഗേറ്റ്വേ അംഗത്തിലെ റൂട്ടിംഗ് ടേബിളുമായി ചേർത്ത്, അവസാന ഹോപ്പ് zt ആണോ eth ആണോ എന്ന് കാണിക്കുന്നു.

ZeroTier പ്രകടനത്തിനായി നിർദ്ദിഷ്ട ലോക്കൽ പാതകളിൽ ട്രാൻസ്പോർട്ട് സുരക്ഷ ഒഴിവാക്കാവുന്ന ഒരു ട്രസ്റ്റഡ്-പാത്ത് മോഡും വാഗ്ദാനം ചെയ്യുന്നു. അത് ഉപയോഗിക്കുന്ന നെറ്റ്വർക്ക് സാധാരണ എൻക്രിപ്റ്റഡ്-പാത്ത് അനുമാനം അവകാശമാക്കുന്നില്ല, അതിനാൽ ഒന്ന് ഉദ്ധരിക്കുന്നതിന് മുമ്പ് നെറ്റ്വർക്ക് കോൺഫിഗറേഷൻ വായിക്കുക. പ്രോട്ടോക്കോൾ ഡോക്യുമെന്റേഷൻ പിയർ എൻക്രിപ്ഷനും ആ ഒഴിവാക്കലും വിവരിക്കുന്നു.

പരിശോധന 5: അപ്ലിക്കേഷൻ ഇനി എന്ത് ചെയ്യണമെന്ന് തീരുമാനിക്കുക

ഓവർലേ അംഗത്വം ഒരു ഉപകരണത്തെ ഒരു നെറ്റ്വർക്കിലേക്ക് പ്രാമാണീകരിക്കുന്നു, അപ്പുറത്തുള്ള സേവനം നിങ്ങൾ ഉദ്ദേശിച്ചതാണോ എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. HTTPS ഒരു ഹോസ്റ്റ്നെയിമിനെ ഒരു കീയുമായി ബന്ധിപ്പിച്ച് വ്യത്യസ്തമായ ഒരു ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു, അതിനാൽ ഈ രണ്ട് സംരക്ഷണങ്ങളും ഒന്നിനെ മറ്റൊന്ന് മാറ്റിസ്ഥാപിക്കാതെ ഓവർലാപ്പ് ചെയ്യുന്നു. അംഗീകൃതമായ ഒരു പിയർ ഇപ്പോഴും തെറ്റായ സേവനമാകാം, കൂടാതെ വിട്ടുപോയ ഒരു എൻഡ്പോയിന്റ് എൻക്രിപ്ഷന് മുമ്പും ഡീക്രിപ്ഷന് ശേഷവും അഭ്യർത്ഥന വായിക്കുന്നു. അപ്ലിക്കേഷൻ രേഖപ്പെടുത്തുന്നത് രണ്ട് സംവിധാനങ്ങളും ഓഡിറ്റ് ചെയ്യുന്നില്ല.

വീണ്ടും ഉപയോഗിക്കാവുന്ന സെഷനോ പാസ്വേഡോ ഉള്ള എന്തിനും, അപ്ലിക്കേഷനിലോ നിങ്ങൾ നിയന്ത്രിക്കുന്ന ഒരു പ്രോക്സിയിലോ TLS ടെർമിനേറ്റ് ചെയ്ത് സർട്ടിഫിക്കറ്റ് വാലിഡേഷൻ ഓണാക്കി വയ്ക്കുക. ഒരു പഴയ സേവനം സാധാരണ HTTP-യിൽ തുടരേണ്ടിവരുമ്പോൾ, അത് ഉപയോഗിക്കാവുന്ന കൃത്യമായ ഹോസ്റ്റ്-ടു-ഹോസ്റ്റ് പാത, ആർക്ക് അതിൽ എത്താം, ഏത് ഭാഗം അസംരക്ഷിതമായി തുടരുന്നു എന്നിവ എഴുതിവയ്ക്കുക; ഭാവിയിലെ ഒരു അവലോകകന് വേണ്ടത് ആ കുറിപ്പാണ്.

"VPN കണക്ട് ചെയ്തിരിക്കുന്നു" എന്നത് ഇതൊന്നിന്റെയും വിലയിരുത്തലല്ല. സത്യസന്ധമായ പതിപ്പ് രണ്ട് എൻഡ്പോയിന്റുകളും അവയ്ക്കിടയിലുള്ള പാതയും മൂടപ്പെടാത്ത ആദ്യ ഹോപ്പും പേരെടുത്ത് പറയുന്നു.

ക്യാപ്ചർ ഔട്ട്പുട്ടും പിയർ ലിസ്റ്റിംഗും സേവന ഡോക്യുമെന്റേഷന് അടുത്തായി സൂക്ഷിക്കുക, അതുവഴി ഒരു റൂട്ട് മാറ്റുന്നതോ ബ്രിഡ്ജ് ചേർക്കുന്നതോ ആരാണെങ്കിലും ഏത് അനുമാനമാണ് തകർക്കാൻ പോകുന്നതെന്ന് കാണാം.