ആപ്പ് ഒരു ഇന്റർഫേസിലേക്ക് ബന്ധിച്ചിരിക്കുന്നുവോ? അതിന്റെ VPN പാത ഡിഫോൾട്ട് അല്ല

മെഷീനിലെ ഒരു ആപ്ലിക്കേഷൻ VPN വഴി പുറത്തുപോകുന്നു, മറ്റൊന്ന് പോകുന്നില്ല, രണ്ട് ഉപയോക്താക്കളും ഒന്നും മാറ്റിയിട്ടില്ലെന്ന് സത്യം ചെയ്യുന്നു. വ്യത്യാസം പലപ്പോഴും ആപ്ലിക്കേഷൻ തന്നെ എടുക്കുന്ന ബൈൻഡിംഗ് തീരുമാനമാണ്: ഉപകരണത്തോട് ബന്ധിച്ച സോക്കറ്റ്, കണക്ഷന് മുമ്പ് തിരഞ്ഞെടുത്ത ഉറവിട വിലാസം, അല്ലെങ്കിൽ സ്വന്തം റൂട്ടിംഗ് പട്ടികയുള്ള നെയിംസ്പേസ്. ഓരോന്നും ഏത് പാത ബാധകമാകുമെന്ന് മാറ്റുന്നു, അവയൊന്നും ബ്രൗസറിന്റെ പൊതുവായ IP പരിശോധനയിൽ കാണുന്നില്ല.

മൂന്ന് വ്യത്യസ്ത ബൈൻഡിംഗുകൾ, മൂന്ന് വ്യത്യസ്ത ഫലങ്ങൾ

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

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

ആപ്പ് യഥാർത്ഥത്തിൽ എന്താണ് സെറ്റ് ചെയ്യുന്നതെന്ന് നിർണ്ണയിക്കുക

റൂട്ടുകളിൽ തൊടുന്നതിന് മുമ്പ് ആപ്ലിക്കേഷന്റെ നെറ്റ്വർക്കിംഗ് കോൺഫിഗറേഷനോ രേഖപ്പെടുത്തിയ പെരുമാറ്റമോ വായിക്കുക. ഇന്റർഫേസ് തിരഞ്ഞെടുപ്പ്, ഉറവിട വിലാസ ഫീൽഡ് അല്ലെങ്കിൽ നെയിംസ്പേസ് ഓപ്ഷൻ നൽകുന്നുവെങ്കിൽ ആ ക്രമീകരണമാണ് ആദ്യം പരിശോധിക്കേണ്ടത്. ഇല്ലെങ്കിൽ ബൈൻഡിംഗ് ആന്തരികമായിരിക്കാം, ട്രേസിംഗ് അല്ലെങ്കിൽ അതിന്റെ സ്വന്തം ഡയഗ്നോസ്റ്റിക്സ് വഴി മാത്രം കാണാം.

Linux-ൽ SO_BINDTODEVICE പോലുള്ള സോക്കറ്റ് ഓപ്ഷനുകൾക്ക് രേഖപ്പെടുത്തിയ പരിധിയും അനുമതി ആവശ്യകതകളുമുണ്ട്, പ്രത്യേകാവകാശമില്ലാത്ത പ്രോസസിന് അവ സെറ്റ് ചെയ്യാൻ കഴിഞ്ഞെന്നുവരില്ല. ഈ പരിമിതി ഉപയോഗപ്രദമായ സൂചനയാണ്: ഓപ്ഷൻ പ്രയോഗിക്കാൻ കഴിയുന്നില്ലെങ്കിൽ വ്യത്യാസത്തിന്റെ ഉറവിടം ആപ്പ് ആയിരിക്കില്ല.

നയ റൂട്ടിംഗ് ഉറവിടം വായിക്കുന്നു

നയ റൂട്ടിംഗ് കോൺഫിഗർ ചെയ്തിരിക്കുമ്പോൾ, പാക്കറ്റിന്റെ ഉറവിടം അനുസരിച്ച് ഒരു നിയമത്തിന് പട്ടിക തിരഞ്ഞെടുക്കാം. അതിനാൽ ഉറവിട വിലാസം ബന്ധിക്കുന്ന സോക്കറ്റ് ഡിഫോൾട്ട് പാത ഒരിക്കലും തൊടാത്ത ഒരു നിയമം പിന്തുടരാം, ഒരു ഇന്റർഫേസും വ്യക്തമായി പേരിട്ടിട്ടില്ലെങ്കിലും.

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

സ്പ്ലിറ്റ് ടണലിംഗും സഹായ പ്രോസസുകളും

ഓരോ ആപ്പിനുമുള്ള സ്പ്ലിറ്റ് ടണൽ മറ്റൊരു പാളി ചേർക്കുന്നു. ക്ലയന്റിന് ആപ്പിന്റെ പാക്കേജോ പ്രോസസോ പൊരുത്തപ്പെടുത്താം, സ്വന്തം സോക്കറ്റ് തുറക്കുന്ന സഹായി വേറിട്ട വിഷയമാണ്. ഒരു ലോഞ്ചറും അതിന്റെ പശ്ചാത്തല സേവനവും ഒരേ ദൃശ്യമായ പേരിന് കീഴിൽ വ്യത്യസ്ത കണക്ഷനുകൾ ഉണ്ടാക്കാം.

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

ആപ്പിന്റെ സ്വന്തം പാത പരീക്ഷിക്കുക

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

Linux സോക്കറ്റ് റഫറൻസ് SO_BINDTODEVICE-ഉം അതിന്റെ ആവശ്യകതകളും രേഖപ്പെടുത്തുന്നു. ആദ്യം ആപ്പിന്റെ സ്വന്തം കോൺഫിഗറേഷൻ വായിക്കുക, അതേ സന്ദർഭത്തിൽ തിരയൽ വീണ്ടും നടത്തുക, അതിനുശേഷം മാത്രം റൂട്ടോ ബൈൻഡിംഗോ മാറ്റണോ എന്ന് തീരുമാനിക്കുക.