ഈ ആപ്പ് ഒഴിവാക്കാനുള്ള സ്വിച്ചില്ല: പ്രോസസ്സിന് അതിന്റെ സ്വന്തം ഉറവിടം നൽകുക

ഒരു പ്രോഗ്രാം സാധാരണ കണക്ഷൻ ഉപയോഗിക്കണം, ബാക്കിയെല്ലാം ടണലിൽ തുടരണം, കൂടാതെ ക്ലയന്റിന് അതിന് സ്വിച്ചില്ല. മറഞ്ഞിരിക്കുന്ന മെനുവും കണ്ടെത്താനില്ല. പാക്കറ്റിനുള്ളിലെ ഫീൽഡുകളിൽ നിന്നാണ് റൂട്ട് തിരഞ്ഞെടുക്കുന്നത്, പാക്കറ്റ് വിലാസങ്ങളും പോർട്ടുകളും വഹിക്കുന്നു, അത് സൃഷ്ടിച്ച പ്രോസസ്സിന്റെ ഐഡന്റിറ്റിയല്ല, അതിനാൽ ഒഴിവാക്കൽ ആ ഫീൽഡുകളിലൊന്നിൽ പ്രകടിപ്പിക്കണം. ഒരു പാക്കറ്റ് ഒരിക്കൽ പിന്തുടരുക, ലഭ്യമായ ഓപ്ഷനുകൾ നിഗൂഢമായിരിക്കുന്നത് നിർത്തും.

ക്ലയന്റിന് അത് എന്തുകൊണ്ട് നൽകാനാകില്ല

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

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

യഥാർത്ഥ ആപ്പ് അടിസ്ഥാനമാക്കിയ റൂട്ടിംഗ് പ്ലാറ്റ്ഫോം അതിന് യന്ത്രസംവിധാനം ചേർത്തിടത്ത് മാത്രമേ ഉള്ളൂ, ഉദാഹരണത്തിന് Windows-ലെ ഫിൽട്ടർ കോളുകൾ അല്ലെങ്കിൽ Android-ലെ VPN സേവന ബൈൻഡിംഗ്. ഡെസ്ക്ടോപ്പ് OpenVPN ഇൻസ്റ്റൻസ് അവയൊന്നും കൊണ്ടുവരുന്നില്ല, ഒരു കോൺഫിഗറേഷൻ ഫ്ലാഗും അത് കണ്ടുപിടിക്കുന്നുമില്ല.

Linux: പ്രോസസ്സ് അടയാളപ്പെടുത്തുക, തുടർന്ന് അടയാളം റൂട്ട് ചെയ്യുക

ഏറ്റവും വൃത്തിയുള്ള സമീപനം തീരുമാനത്തെ സോക്കറ്റ് ഉടമസ്ഥതയിലുള്ള പ്രോസസ്സുമായി ബന്ധിപ്പിക്കുന്നു. owner പൊരുത്തം OUTPUT ചെയിനിൽ പ്രാദേശികമായി ഉത്പാദിപ്പിക്കുന്ന ട്രാഫിക്കിന് പ്രവർത്തിക്കുന്നു, അതിനാൽ അവിടെ പ്രയോഗിക്കുന്ന അടയാളത്തിന് പ്രത്യേക പട്ടിക തിരഞ്ഞെടുക്കാം:

iptables -t mangle -A OUTPUT -m owner --uid-owner 1001 -j MARK --set-mark 0x1
ip rule add fwmark 0x1 table 200
ip route add 192.168.1.0/24 dev eth0 src 192.168.1.0 table 200
ip route add default via 192.168.1.1 dev eth0 table 200

ഉപയോക്താവ് 1001-ന്റെ പാക്കറ്റുകൾ പിന്നീട് പട്ടിക 200 സമീപിച്ച് സാധാരണ ഗേറ്റ്വേ വഴി പുറത്തുപോകുന്നു, പ്രധാന പട്ടിക ബാക്കിയെല്ലാം ടണലിലേക്ക് അയയ്ക്കുന്നു. owner പൊരുത്തം പ്രാദേശികമായി ഉത്പാദിപ്പിക്കുന്ന പാക്കറ്റുകൾക്ക് മാത്രം ബാധകമാണ്, അതാണ് ഇവിടെ പ്രധാനമായ ട്രാഫിക്, മറ്റൊരു ഹോസ്റ്റിനായി ഫോർവേഡ് ചെയ്യുന്ന പാക്കറ്റുകളെ അതിന് വർഗ്ഗീകരിക്കാനാവില്ല. ഉദ്ദേശ്യത്താലല്ല, ഉപകരണങ്ങളാൽ പരിശോധിക്കുക: ss -tnp സ്ഥാപിത കണക്ഷനുകളുടെ പ്രാദേശിക വിലാസവും ഉടമ പ്രോസസ്സും കാണിക്കുന്നു, ip route get 1.1.1.1 mark 0x1 അടയാളം ഏത് പട്ടിക തിരഞ്ഞെടുക്കുന്നു എന്ന് കാണിക്കുന്നു.

നെറ്റ്വർക്ക് നെയിംസ്പേസ് സ്വയംപര്യാപ്തമായ പ്രോഗ്രാമിന് കൂടുതൽ ഉറച്ച ഉത്തരമാണ്, കാരണം അതിനുള്ളിൽ സൃഷ്ടിക്കുന്ന ഓരോ സോക്കറ്റും നിർമ്മാണപരമായി അതിലേക്ക് ബന്ധിക്കപ്പെട്ടിരിക്കുന്നു, അതിനാൽ സഹായ പ്രോസസ്സുകളും ഉപ കണക്ഷനുകളും വർഗ്ഗീകരണമില്ലാതെ പെരുമാറ്റം പാരമ്പര്യമായി നേടുന്നു. വില പ്ലംബിംഗാണ്: ഒരു veth ജോഡി, ഓരോ അറ്റത്തും ഒരു വിലാസം, നെയിംസ്പേസിനുള്ളിൽ ഹോസ്റ്റിലേക്ക് തിരികെ ചൂണ്ടുന്ന ഡിഫോൾട്ട് റൂട്ട്.

ip netns add novpn
ip link add veth-host type veth peer name veth-ns
ip link set veth-ns netns novpn
ip addr add 10.200.0.1/24 dev veth-host
ip netns exec novpn ip addr add 10.200.0.2/24 dev veth-ns
ip netns exec novpn ip route add default via 10.200.0.1

Windows: ലക്ഷ്യം ഇപ്പോഴും തീരുമാനിക്കുന്നു

Windows ലക്ഷ്യത്തിൽ നിന്നാണ് ഔട്ട്ഗോയിംഗ് ഇന്റർഫേസ് തിരഞ്ഞെടുക്കുന്നത്, അതിനാൽ വേറെ വഴി ആഗ്രഹിക്കുന്ന പ്രോഗ്രാം ആ തിരഞ്ഞെടുപ്പിന് മുമ്പ് സ്റ്റാക്ക് സമീപിക്കുന്ന എന്തെങ്കിലും മാറ്റണം. ForceBindIP ആദ്യ പകുതി മൂടുന്നു: നിങ്ങൾ പേരിടുന്ന പ്രാദേശിക വിലാസത്തിലേക്ക് സോക്കറ്റുകൾ ഇതിനകം ബന്ധിച്ച നിലയിൽ പ്രോഗ്രാം ആരംഭിക്കുന്നു. അത് മാത്രം പാക്കറ്റ് ഏത് ഇന്റർഫേസിലൂടെ പുറത്തുപോകുന്നു എന്നത് മാറ്റുന്നില്ല, കാരണം റൂട്ട് ഇപ്പോഴും ലക്ഷ്യം തിരഞ്ഞെടുക്കുന്നു. ഡിഫോൾട്ട് റൂട്ട് ടണലിലേക്ക് ചൂണ്ടുന്ന ലാപ്ടോപ്പിൽ ഉറവിടം ബന്ധിക്കുക, പാക്കറ്റ് എങ്കിലും ടണലിൽ പ്രവേശിക്കും.

ലക്ഷണത്തിന് വായിക്കാവുന്ന ഒരു രൂപമുണ്ട്, ഒരിക്കൽ അത് അറിഞ്ഞാൽ. തിരഞ്ഞെടുത്ത ഇന്റർഫേസ് നേരിട്ട് എത്തുന്ന LAN വിലാസത്തിന് ഇത് ബാധകമാണ്, റൂട്ട് ടണലിലേക്ക് ചൂണ്ടുന്ന ഇന്റർനെറ്റിലെ എന്തിനും ഇത് പരാജയപ്പെടുന്നു. പ്രോഗ്രാം ജോലി ഒരു സഹായിക്ക് കൈമാറുന്നതുവരെ അത് പ്രവർത്തിക്കുന്നതായും തോന്നും, കാരണം സ്വന്തം സോക്കറ്റ് തുറക്കുന്ന സഹായിയോട് ബന്ധനത്തെക്കുറിച്ച് ഒരിക്കലും പറഞ്ഞിട്ടില്ല.

ഒരു പ്രോസസ്സ് തെറ്റായ യൂണിറ്റാകുമ്പോൾ തീരുമാനം മാറ്റുക

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

രണ്ടും ഒരു വാക്യത്തിൽ പറയാവുന്ന പരിധിയുള്ള ഉറവിട അല്ലെങ്കിൽ ലക്ഷ്യ നയങ്ങളാണ്. ഒന്നും ആപ്പ് അടിസ്ഥാനമാക്കിയല്ല, തന്നെത്താൻ ആപ്പ് അടിസ്ഥാനമാക്കിയെന്ന് പരസ്യപ്പെടുത്തുന്ന രൂപകൽപ്പന പ്രോഗ്രാം തന്റെ ജോലി രണ്ടാം പ്രോസസ്സിന് കൈമാറുന്ന ആദ്യ അവസരത്തിൽ പരാജയപ്പെടുന്നു.