സപ്പോർട്ട് ടിക്കറ്റുകൾ വരുന്നു: ആപ്പ് ഒരു വിലാസം കാണിക്കുന്നു, എന്നാൽ സർവർ മറ്റൊന്ന് രേഖപ്പെടുത്തി, പിന്നെ ഇവയിൽ ഏതാണ് കള്ളം പറയുന്നതെന്ന് ചോദിക്കുന്നു. രണ്ടുമല്ല; ഇവ രണ്ട് വ്യത്യസ്ത കാര്യങ്ങളുടെ രണ്ട് നിരീക്ഷണങ്ങളാണ്. ഇന്റർഫേസിൽ ബന്ധിപ്പിച്ച വിലാസം, സോക്കറ്റിൽ ബന്ധിപ്പിച്ച വിലാസം, വിദൂര സേവനം കാണുന്ന ഉറവിട വിലാസം, ഇവ മൂന്ന് വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു. VPN ഫോണിലേക്ക് ഒരു നെറ്റ്വർക്ക് സന്ദർഭം ചേർക്കുന്നു, ആ മൂന്നിനെയും ഒരു ഉപകരണ വ്യാപക സംഖ്യയാക്കി ചുരുക്കുന്നില്ല. വിലാസങ്ങൾ വായിക്കുന്നതിന് മുൻപ് ടിക്കറ്റിലെ ഫീൽഡ് പേരുകൾ വായിക്കുക.

ടിക്കറ്റ് സാധാരണയായി എന്താണ് വിവരിക്കുന്നത്

Wi-Fi-യിൽ ടണൽ ഓണായ ഒരു ഫോൺ സങ്കൽപ്പിക്കുക. Wi-Fi ഇന്റർഫേസിന് ഒരു LAN വിലാസമുണ്ട്, ടണൽ ഇന്റർഫേസിന് അനുവദിച്ച ഒരു ആന്തരിക വിലാസമുണ്ട്, ടണലിലൂടെ പുറത്തുപോകുന്ന അഭ്യർത്ഥന വഴിയിലെ ഏതെങ്കിലും പരിഭാഷയെ അതിജീവിക്കുന്ന ഉറവിടത്തിൽ നിന്ന് ഒരു പൊതു സേവനത്തിൽ എത്തുന്നു. ആന്തരിക വിലാസം പ്രിന്റ് ചെയ്യുന്ന ആപ്പും പരിഭാഷപ്പെടുത്തിയ ഉറവിടം രേഖപ്പെടുത്തുന്ന സർവറും രണ്ടും കൃത്യമായി റിപ്പോർട്ട് ചെയ്യുന്നു, ആ രണ്ട് മൂല്യങ്ങൾ ഒരിക്കലും ഒത്തുപോകില്ല.

മൂന്ന് നിരീക്ഷണങ്ങൾ എന്താണ് വിവരിക്കുന്നത് എന്നതിൽ മാത്രമല്ല, എന്താണ് തെളിയിക്കാൻ കഴിയുന്നത് എന്നതിലും വ്യത്യസ്തമാണ്.

ObservationWhat it describesWhat it cannot prove
An address on a local interfaceOne configured attachment: Wi-Fi, cellular or a tunnelThe source a remote site receives
A socket's local endpointThe binding used by that one connectionThe address after translation further along
The peer address at a serviceWhat arrived at that observation pointAny other interface on the phone

ആ പട്ടിക ഈ മൂല്യങ്ങൾ ടിക്കറ്റിലേക്ക് നിറയ്ക്കുന്ന കോഡിന് അടുത്ത് സൂക്ഷിക്കുക, കാരണം ഇവിടെയുള്ള ആശയക്കുഴപ്പത്തിന്റെ ഭൂരിഭാഗവും നെറ്റ്വർക്ക് തകരാറല്ല, കോളങ്ങളുടെ കൂട്ടിമാറ്റമാണ്.

സോക്കറ്റ് കോൾ എന്തിന് ഉത്തരം നൽകാം, എന്തിന് നൽകാനാവില്ല

API തലത്തിൽ, getsockname നിലവിൽ ഒരു നിർദ്ദിഷ്ട സോക്കറ്റിൽ ബന്ധിപ്പിച്ചിരിക്കുന്ന പ്രാദേശിക എൻഡ്പോയിന്റ് റിപ്പോർട്ട് ചെയ്യുന്നു. ബന്ധിപ്പിച്ച സോക്കറ്റിന് അത് കേർണൽ ആ കണക്ഷനുവേണ്ടി തിരഞ്ഞെടുത്ത ഉറവിടമാണ്, അത് ഏതെങ്കിലും ഇന്റർഫേസ് പട്ടികയേക്കാൾ ഇതിനകം കൃത്യമാണ്. ഇത് പൊതു വിലാസ തിരച്ചിലല്ല, ബന്ധിപ്പിക്കാത്ത സോക്കറ്റിൽ ഇത് വിളിക്കുന്നത് നിങ്ങളോട് ഏതാണ്ട് ഒന്നും പറയുന്നില്ല. അത് തിരികെ നൽകുന്നത് പിന്നീട് വഴിയിൽ വീണ്ടും എഴുതാം, അതിനാൽ സേവനം എന്താണ് സ്വീകരിച്ചത് എന്നതിൽ സേവനത്തിന്റെ സ്വന്തം നിരീക്ഷണത്തിന് മാത്രമാണ് അധികാരം.

Apple പ്ലാറ്റ്ഫോമുകളിൽ ഇന്റർഫേസുകളുടെ വശത്തിന് വേറിട്ട ഒരു ഉപരിതലമുണ്ട്: ടണൽ ക്രമീകരണങ്ങൾ ടണൽ ഇന്റർഫേസിന് അനുവദിച്ച വിലാസങ്ങൾ പട്ടികപ്പെടുത്തുന്നു. അവ വായിക്കുന്നത് ടണൽ എങ്ങനെ ക്രമീകരിച്ചു എന്ന് പറയും, ഒരു നിർദ്ദിഷ്ട അഭ്യർത്ഥന ഏത് വഴിയാണ് പോയത് എന്ന് പറയില്ല, കാരണം റൂട്ടിംഗും ഓരോ ആപ്പിനുമുള്ള നിയമങ്ങളും അത് ഓരോ കണക്ഷനും തീരുമാനിക്കുന്നു.

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

ചോദ്യത്തിന് യോജിക്കുന്ന നിരീക്ഷണം തിരഞ്ഞെടുക്കുക

എല്ലാം അളക്കുന്നതിനു പകരം ബോധപൂർവം തിരഞ്ഞെടുക്കുക. ബാക്കെൻഡ് കാണുന്നതിന് ബാക്കെൻഡിൽ ഉറവിടം രേഖപ്പെടുത്തുക, മുൻപിൽ ഒരു റിവേഴ്സ് പ്രോക്സി ഉണ്ടെങ്കിൽ, ക്ലയന്റ് വിലാസം ക്ലയന്റ് അയച്ച എന്തിൽ നിന്നുമല്ല, നിങ്ങളുടെ വിന്യാസം യഥാർത്ഥത്തിൽ സെറ്റ് ചെയ്യുന്ന ഫോർവേഡിംഗ് ഹെഡറിൽ നിന്ന് വായിക്കുക.

ടണൽ ക്രമീകരിച്ചിട്ടുണ്ടോ എന്ന് അറിയാൻ ഇന്റർഫേസ് വായിക്കുക. ഈ ആപ്പിന്റെ ട്രാഫിക് അത് ഉപയോഗിച്ചോ എന്ന് അറിയാൻ, ആ ആപ്പിൽ നിന്ന് നിങ്ങൾ നിയന്ത്രിക്കുന്ന ഒരു ലക്ഷ്യത്തിലേക്ക് ട്രാഫിക് അയച്ച് ഇരു അറ്റത്തും ഉറവിടം താരതമ്യം ചെയ്യുക.

ഓരോ ആപ്പിനുമുള്ള നിയമങ്ങൾ അവയുടെ സ്വന്തം വാക്യത്തിന് അർഹമാണ്. ബ്രൗസറിന്റെ ഫലം ആ ബ്രൗസറിനെക്കുറിച്ചുള്ള തെളിവാണ്, നിയന്ത്രിത ഓരോ ആപ്പിനുമുള്ള ടണൽ ഒരേ ഫോണിലെ രണ്ട് ആപ്പുകളെ ഒരേ നിമിഷത്തിൽ വ്യത്യസ്ത വഴികളിൽ ഇടാം. കവറേജ് പരിശോധിക്കുകയെന്നാൽ ബന്ധപ്പെട്ട ആപ്പിൽ നിന്ന്, ബന്ധപ്പെട്ട വിലാസ കുടുംബത്തിൽ ട്രാഫിക് അയക്കുകയെന്നാണ്.

ഇന്റർഫേസ് പേരുകൾ ഡിറ്റക്ടറല്ല

ഇന്റർഫേസ് പേര് VPN പരിശോധനയായും ഉപയോഗിക്കരുത്. പേരുകൾ പൊതു കരാറല്ല, ഒരു ഫോണിൽ പല അറ്റാച്ച്മെന്റുകൾ ഉണ്ടാകാം, അവയിൽ ഒന്ന് മാത്രമാണ് നിങ്ങളുടെ അഭ്യർത്ഥന വഹിക്കുന്നത്.

ഫീൽഡിന് അത് വഹിക്കുന്ന നിരീക്ഷണത്തിന്റെ പേര് നൽകുക. local_interface_address, socket_local_endpoint, service_observed_source എന്നിവ വിചിത്രവും അവ്യക്തതയില്ലാത്തതുമാണ്, മൂല്യം ഒരു ആഴ്ച കഴിഞ്ഞ് ഒരു സപ്പോർട്ട് ടിക്കറ്റിൽ എത്തുമ്പോൾ നിങ്ങൾക്ക് വേണ്ടത് ആ അവ്യക്തതയില്ലായ്മയാണ്. device IP എന്ന ഒരു കോളം മൂന്നും ശേഖരിച്ച് പിന്നീട് അത് ഒന്നാണെന്ന് വിശ്വസിക്കപ്പെടും.

ഐഡന്റിറ്റി വിലാസ കോളത്തിന് പുറത്ത് സൂക്ഷിക്കുക

പങ്കിട്ട VPN എക്സിറ്റ് ഒരു ഉപയോക്തൃ ഐഡന്റിറ്റിയല്ല, സ്വകാര്യ വിലാസം ഒരു ആക്സസ് ക്രെഡൻഷ്യലുമല്ല. രണ്ടും വ്യക്തിയെയല്ല, ഒരു വഴിയെയാണ് വിവരിക്കുന്നത്, ഇവയിൽ ഏതിനെയെങ്കിലും ഓതന്റിക്കേഷനായി കാണുന്നത് ഒരു റൂട്ടിംഗ് അപകടത്തെ അനുമതി തീരുമാനമാക്കി മാറ്റുന്നു.

ഫോണിന് ഏത് വിലാസമാണുള്ളതെന്ന് ആരെങ്കിലും ചോദിച്ചാൽ, ഉപയോഗപ്രദമായ മറുപടി ഏത് കണക്ഷനും ഏത് നിരീക്ഷകനും എന്ന ചോദ്യമാണ്. getsockname എന്നതിന്റെ നിർവചനം മധ്യ കേസിന് ഉദ്ധരിക്കാൻ യോഗ്യമാണ്, കാരണം അത് സോക്കറ്റ് ചോദ്യം തീർക്കുന്നു, ബാക്കി രണ്ടും തീർക്കുന്നതായി നടിക്കുന്നുമില്ല.

പിന്നെ മൂന്നിൽ ഏതാണ് നിങ്ങളുടെ ഉൽപ്പന്നത്തിന് യഥാർത്ഥത്തിൽ കാണിക്കേണ്ടതെന്ന് എഴുതി ബാക്കി രണ്ടും ഇന്റർഫേസിൽ നിന്ന് നീക്കം ചെയ്യുക.

അനുബന്ധ ലേഖനങ്ങൾ