ഒരു Linux ഉപയോക്താവിന്റെ ഉടമസ്ഥതയിലുള്ള ഓരോ IPv4 സോക്കറ്റും നിലവിലുള്ള ഒരു ടണലിലൂടെ പുറത്തുപോകേണ്ടിവരുമ്പോൾ അക്കൗണ്ട് അടിസ്ഥാനമാക്കിയുള്ള റൂട്ടിംഗ് അനുയോജ്യമാണ്, പ്രോഗ്രാം തലത്തിലുള്ള വേർതിരിവ് വേണ്ടിവരുമ്പോൾ അത് അനുയോജ്യമല്ല. ഇത് UID അനുസരിച്ച് തിരഞ്ഞെടുക്കുന്നു, അതിനാൽ ആ അക്കൗണ്ടിൽ പ്രവർത്തിക്കുന്ന എല്ലാം പരിധിയിൽ വരും, മറന്നുപോയ ബാച്ച് ജോലിയും ഉൾപ്പെടെ. ഒരു ip rule പോലും സ്പർശിക്കുന്നതിന് മുമ്പ് ആ ചോദ്യം തീർക്കുക.

താഴെയുള്ള ഉദാഹരണം UID 1500-ൽ ഒരു സമർപ്പിത ബ്രൗസർ അക്കൗണ്ട്, 10.80.0.11 ലോക്കൽ വിലാസം വഹിക്കുന്ന ടണൽ ഉപകരണം tun-office, ബന്ധപ്പെട്ട ലക്ഷ്യസ്ഥാനങ്ങൾ അനുവദിക്കുന്ന VPN എന്നിവ അനുമാനിക്കുന്നു. ഡീമൺ തന്നെ ആ UID-ന് പുറത്താണ് പ്രവർത്തിക്കുന്നത്.

സംവിധാനം തിരഞ്ഞെടുക്കുന്ന മൂന്ന് വ്യവസ്ഥകൾ

ജോലി ചെയ്യുന്ന ഐഡന്റിറ്റി അക്കൗണ്ടായിരിക്കുമ്പോൾ, അതിന്റെ മുഴുവൻ ട്രാഫിക്കും മാറ്റുന്നത് സ്വീകാര്യമാകുമ്പോൾ, namespace ജോലിക്ക് അർഹതയുള്ളതിനേക്കാൾ ഭാരമാകുമ്പോൾ UID നിയമം തിരഞ്ഞെടുക്കുക. ജോലിഭാരത്തിന് സ്വന്തം ഇന്റർഫേസുകളും റിസോൾവറും റൂട്ടിംഗ് ടേബിളും വേണ്ടിവരുമ്പോൾ നെറ്റ്വർക്ക് namespace തിരഞ്ഞെടുക്കുക. കൃത്യമായി ഒരു ആപ്ലിക്കേഷൻ മാത്രം മാറ്റേണ്ടിവരുമ്പോൾ പ്രോക്സിയോ പ്രതി-പ്രോസസ് ബൈൻഡോ തിരഞ്ഞെടുക്കുക, സെഷന്റെ ബാക്കി ലോക്കൽ പാതയിൽ തുടരുമ്പോൾ. ഇവ മൂന്നും എഴുതിവെക്കുന്നത് ഉദ്ദേശിച്ചതിലും കൂടുതൽ നിശ്ശബ്ദമായി ഉൾക്കൊള്ളുന്ന നിയമത്തെ തടയുന്നു.

ഒഴിവാക്കേണ്ട തെറ്റ് ലോഞ്ചർ ഉടമയെ നിർണ്ണയിക്കുന്നു എന്ന് അനുമാനിക്കുന്നതാണ്. മറ്റൊരു ഉപയോക്താവിന്റെ സെഷൻ URL നൽകിയ ബ്രൗസർ UID 1500-ന് കീഴിൽ സോക്കറ്റുകൾ സൃഷ്ടിച്ചിട്ടില്ല, ഏത് നിയമവും അത് സൃഷ്ടിക്കുന്ന ട്രാഫിക്ക് മാറ്റില്ല.

ടേബിൾ, നിയമം, കാവൽക്കാരൻ

നിലവിലുള്ള നിയമങ്ങൾ പരിശോധിച്ച് ഉപയോഗിക്കാത്ത ടേബിൾ, മുൻഗണന സംഖ്യകൾ തിരഞ്ഞെടുത്തതിന് ശേഷം ക്രമീകരണം ചെറുതാണ്: ടണലിന്റെ സ്രോതസ്സ് വിലാസം വഹിക്കുന്ന സമർപ്പിത ടേബിളിലെ ഡിഫോൾട്ട് റൂട്ട്, അക്കൗണ്ടിന്റെ തിരയലുകൾ ആ ടേബിളിലേക്ക് അയക്കുന്ന നിയമം, ഫാൾബാക്ക് തടയുന്ന അവസാന നിയമം. എഴുതുമ്പോൾ അത് ഐഡംപോട്ടന്റ് റൂട്ട് മാറ്റിസ്ഥാപനമാണ്, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, തുടർന്ന് ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

കാവൽക്കാരൻ ip -4 rule add priority 12101 uidrange 1500-1500 unreachable ആണ്, അതിന്റെ നീളം സൂചിപ്പിക്കുന്നതിനേക്കാൾ അത് പ്രധാനമാണ്. അതില്ലാതെ 51820 ടേബിളിലെ കാണാത്ത റൂട്ട് സാധാരണ അപ്ലിങ്കിലേക്ക് വീഴുന്നു, നയം പിടിക്കേണ്ടിയിരുന്ന ട്രാഫിക് അക്കൗണ്ട് നിശ്ശബ്ദമായി ചോർത്തുന്നു. അതോടെ അതേ പരാജയം ടൈംഔട്ട് ആകുന്നു, അതായത് ഫാൾബാക്ക് അല്ല, തടയൽ.

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

UID റൂട്ടിംഗ് ഒഴിവാക്കുന്നത്: DNS

റിസോൾവർ ഡീമൺ തന്റെ അപ്സ്ട്രീം സോക്കറ്റുകൾ സ്വന്തം UID-ക്ക് കീഴിൽ തുറക്കുന്നു, അതിനാൽ 1500 തിരഞ്ഞെടുക്കുന്നത് ആ ചോദ്യങ്ങളെ 51820 ടേബിളിലേക്ക് മാറ്റുന്നില്ല. DNS സംയോജനം പ്രത്യേക തീരുമാനമാണ്: അക്കൗണ്ടിനെ ടണലിലൂടെ എത്താവുന്ന റിസോൾവറിലേക്ക് വിരൽ ചൂണ്ടുക, അല്ലെങ്കിൽ പേര് നിർണ്ണയം ഹോസ്റ്റിന്റെ പാത പിന്തുടരുന്നു, ട്രാഫിക് അല്ല എന്ന് സ്വീകരിക്കുക.

ലോക്കൽ stub-ലേക്കുള്ള loopback ചോദ്യം അപ്സ്ട്രീം ചോദ്യം ബ്രൗസറിന്റെ റൂട്ട് ഉപയോഗിച്ചു എന്നതിന് തെളിവല്ല, കാഷിൽ നിന്നുള്ള വിജയകരമായ പേജ് ലോഡും അല്ല.

IPv6-ന് ഡിസൈനിൽ സ്വന്തം വാക്യം വേണം

മുകളിലുള്ള നിയമങ്ങൾ IPv4 മാത്രം ഉൾക്കൊള്ളുന്നു. ഈ അക്കൗണ്ടിൽ നിന്ന് നേരിട്ടുള്ള IPv6 ഇല്ലാത്ത IPv4 ടണലാണ് ആവശ്യമെങ്കിൽ, പരിശോധിച്ച അവസാന നിയമം ചേർക്കുക, ഉദാഹരണത്തിന് ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, തുടർന്ന് മുൻ IPv6 നിയമങ്ങളും നിലനിർത്താൻ ആഗ്രഹിക്കുന്ന loopback ഒഴിവുകളും പരിശോധിക്കുക.

നേരിട്ടുള്ള IPv6 തടയുന്നത് ഇരട്ട-സ്റ്റാക്ക് ടണലിംഗ് അല്ല; അത് ഒരു അതിർത്തിയാണ്. അതിനെ ടണലിംഗ് എന്ന് വിളിക്കുന്നത് നയം വായിക്കുന്ന അടുത്ത വ്യക്തിയെ ആശയക്കുഴപ്പത്തിലാക്കും, ആ ആശയക്കുഴപ്പം തകർന്ന IPv6 സൈറ്റിനെക്കുറിച്ചുള്ള ഹെൽപ്പ്ഡെസ്ക് ടിക്കറ്റായി പുറത്തുവരും.

യഥാർത്ഥ അക്കൗണ്ട് ഉപയോഗിച്ച് പരിശോധിക്കുക, പിന്നെ ജീവിതചക്രം ഏറ്റെടുക്കുക

തിരയലുകൾ താരതമ്യം ചെയ്യുക: സാധാരണ UID ഉപയോഗിച്ച് അതേ ലക്ഷ്യസ്ഥാനത്തേക്ക് ip -4 route get 198.51.100.25 uid 1500. തുടർന്ന് സമർപ്പിത അക്കൗണ്ടിന് കീഴിൽ അനുവദിക്കപ്പെട്ട അഭ്യർത്ഥന നടത്തി വിദൂര അറ്റം കാണുന്ന സ്രോതസ്സ് വിലാസം പരിശോധിക്കുക. മുൻഗണനാ സ്രോതസ്സ് വിലാസം source NAT അല്ല, മറ്റൊന്ന് ബൈൻഡ് ചെയ്യുന്ന ആപ്ലിക്കേഷനെ അത് മറികടക്കില്ല. രണ്ട് തിരയലുകളും ഒരേ പാത തിരികെ നൽകുന്നുവെങ്കിൽ, നിയമം നിങ്ങൾ കരുതുന്നത് ചെയ്യുന്നില്ല.

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

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