VPN വിലാസത്തിലേക്ക് ബന്ധിച്ച ആപ്പ് ഇപ്പോഴും തെറ്റായ റൂട്ട് ഉപയോഗിക്കുന്നു

ഒരു ആപ്പ് VPN-ന്റെ വിലാസത്തിലേക്ക് ബന്ധിക്കുന്നു, എന്നിട്ടും കണക്ഷൻ സാധാരണ ഡിഫോൾട്ട് റൂട്ടിലൂടെ പുറത്തുപോകുന്നു. ബൈൻഡിൽ ഒന്നും പരാജയപ്പെട്ടിട്ടില്ല; ബൈൻഡ് ചെയ്യുന്നത് കൃത്യമായി അതു തന്നെ ചെയ്തു. സോക്കറ്റ് ഒരു ലോക്കൽ വിലാസത്തിലേക്ക് ബന്ധിക്കുമ്പോൾ കർണൽ ഹെഡറിൽ ഇടുന്ന ഉറവിട വിലാസമാണ് തിരഞ്ഞെടുക്കുന്നത്. അത് ഒരു റൂട്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നില്ല, ആ ഉറവിടം വഹിക്കുന്ന പാക്കറ്റുകളെ ഒരു പ്രത്യേക ടണലിലേക്ക് അയക്കുന്ന നയ നിയമവും സൃഷ്ടിക്കുന്നില്ല.

ഈ റൺബുക്കിന്റെ ബാക്കി ഞാൻ ഉപയോഗിക്കുന്ന പരിശോധനാ ക്രമവും ഓരോ നിരീക്ഷണവും നൽകുന്ന കമാൻഡും ആണ്.

ബൈൻഡ് യഥാർത്ഥത്തിൽ തീരുമാനിക്കുന്നത്

ബൈൻഡ് സോക്കറ്റിന് ഒരു ലോക്കൽ വിലാസം നൽകുന്നു. തുടർന്ന് ഒരു നയ നിയമം ആ ലുക്കപ്പ് വായിക്കുന്ന ടേബിൾ മാറ്റുന്നില്ലെങ്കിൽ, കർണൽ മറ്റൊരു വിധത്തിൽ ചെയ്യുമായിരുന്ന അതേ റൂട്ട് ലുക്കപ്പ് തന്നെ ചെയ്യുന്നു.

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

Linux IP സോക്കറ്റ് റഫറൻസ് ബൈൻഡിന്റെ അർത്ഥം രേഖപ്പെടുത്തുന്നു. റൂട്ടിംഗ് പകുതി ip-rule, ip-route എന്നിവയിലാണ്, അവ ഒരു കാരണത്താൽ വെവ്വേറെ മാനുവലുകളാണ്.

വിലാസം ഈ നെയിംസ്പേസിന്റേതാണെന്ന് ഉറപ്പാക്കുക

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

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

ആ മൂന്നും ആപ്പിന്റെ അതേ സന്ദർഭത്തിൽ പ്രവർത്തിപ്പിക്കുക: അതേ നെയിംസ്പേസ്, കഴിയുമെങ്കിൽ അതേ ഉപയോക്താവ്. പഴയ net30 ഡയഗ്രം നിങ്ങളുടെ നിലവിലെ ടോപ്പോളജി ക്ലയന്റിന് ഏത് വിലാസം നൽകി എന്നതിന് തെളിവല്ല. യഥാർത്ഥത്തിൽ സജീവമായ ഇന്റർഫേസ് വായിക്കുക.

ആ ഉറവിടത്തിനും ലക്ഷ്യത്തിനുമുള്ള ലുക്കപ്പ് വായിക്കുക

ഒരു കമാൻഡ് ബൈൻഡ് ഉത്തരം നൽകാത്ത ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

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

തുടർന്ന് ip rule show ഏതെങ്കിലും നിയമം മറ്റൊരു ടേബിൾ തിരഞ്ഞെടുക്കുമായിരുന്നോ എന്ന് പറയുന്നു. ഇവിടെ മുൻഗണനകൾ പ്രധാനമാണ്, കാരണം ആദ്യം ചേരുന്ന നിയമം വിജയിക്കുന്നു, നിങ്ങളുടെ നിയമത്തിന് മുകളിലുള്ള എല്ലാം പിടിക്കുന്ന ഒരു നിയമം നിങ്ങളുടെ നിയമത്തെ അദൃശ്യമാക്കുന്നു.

അതാണ് ഡിസൈൻ എങ്കിൽ മാത്രം നയ നിയമം ഇൻസ്റ്റാൾ ചെയ്യുക

ഉറവിടാധിഷ്ഠിത റൂട്ടിംഗ് ബോധപൂർവമുള്ള ഡിസൈനാണ്, ഒരു ആപ്പിനുള്ള അറ്റകുറ്റപ്പണിയല്ല. നയ ഉടമ ടണൽ സബ്നെറ്റിൽ നിന്നുള്ള ട്രാഫിക് ടണൽ ഉപയോഗിക്കണമെന്ന് ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ആ നിയമം അവരുടെ കോൺഫിഗറേഷനിൽ പെടുന്നതാണ്, നിങ്ങളുടെ ലാപ്ടോപ്പിലെ ഒറ്റത്തവണ കമാൻഡിൽ അല്ല.

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

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

ip rule del, ip route flush table 100 എന്നിവ ഉപയോഗിച്ച് പിൻവലിക്കുക. ഈ രീതിയിൽ ചേർക്കുന്നതെല്ലാം റീബൂട്ടിൽ അപ്രത്യക്ഷമാകും, ഒരു മാനേജർ അത് എഴുതിയില്ലെങ്കിൽ; ഇത് ഒരു സുരക്ഷാ സ്വഭാവവും ഏക പകർപ്പ് നിങ്ങളുടെ ഷെൽ ചരിത്രത്തിൽ സൂക്ഷിക്കാതിരിക്കാനുള്ള കാരണവുമാണ്.

മൂന്ന് നിരീക്ഷണങ്ങളിലൂടെ പരിശോധിക്കുക

ആപ്പ് അഭ്യർത്ഥിച്ച ഉറവിടം, ലുക്കപ്പ് തിരഞ്ഞെടുത്ത റൂട്ട്, സർവർ യഥാർത്ഥത്തിൽ കണ്ട ഉറവിടം എന്നിവ രേഖപ്പെടുത്തുക.

ഈ മൂന്നും വ്യത്യാസപ്പെടാം, ഓരോ വ്യത്യാസവും വേറെ എവിടെയോ ചൂണ്ടുന്നു. ടണൽ ഇന്റർഫേസിലെ ക്യാപ്ചർ പാക്കറ്റ് ശരിയായ ഉറവിടവുമായി പുറത്തുപോയത് തെളിയിക്കുന്നു. ഫിസിക്കൽ ഇന്റർഫേസിലെ ക്യാപ്ചർ അത് തെറ്റായ വഴിയിലൂടെ പുറത്തുപോയത് തെളിയിക്കുന്നു. പാത ആദ്യം മുതൽ അവസാനം വരെ തെളിയിക്കുന്നത് സർവർ വശത്തെ കാഴ്ച മാത്രമാണ്.

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