Linux-ൽ Transmission: പ്രോസസിന്റെ ഉടമ അനുസരിച്ച് പുറത്തേക്കുള്ള ട്രാഫിക് നിർബന്ധമാക്കുക

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

കൈമാറ്റത്തിന്റെ ഉടമയായ പ്രോസസിന് പേരു നൽകുക

ഡെസ്ക്ടോപ്പ് ആപ്ലിക്കേഷനും സിസ്റ്റം ഡീമണും വ്യത്യസ്ത അക്കൗണ്ടുകളിൽ പ്രവർത്തിക്കുന്നു, ഉടമ അടിസ്ഥാനമാക്കിയ നിയമം പ്രോഗ്രാമിന്റെ പേരിനെയല്ല, അക്കൗണ്ടിനെ പിന്തുടരുന്നു. ഏതെങ്കിലും നിയമം എഴുതുന്നതിന് മുൻപ് ഇവയിൽ ഏതാണ് പ്രവർത്തിക്കുന്നതെന്ന് കണ്ടെത്തുക. സമർപ്പിത സേവന അക്കൗണ്ട് നയത്തിന് കൃത്യമായ വിഷയം നൽകുന്നു, എന്നാൽ ഡെസ്ക്ടോപ്പ് ഉപയോക്താവ് തന്റെ അടയാളം ബ്രൗസറുകൾ, എഡിറ്ററുകൾ, സെഷനിലെ മറ്റെല്ലാറ്റിനുമൊപ്പം പങ്കിടുന്നു. UID സ്ഥിരീകരിക്കുക, പാക്കേജിലെ അക്കൗണ്ട് പേരാണ് ഉപയോഗിക്കുന്നതെന്ന് അനുമാനിക്കരുത്.

systemctl status transmission-daemon
ps -o user=,pid=,cmd= -C transmission-daemon

അക്കൗണ്ട് ഇനിയും ഇല്ലെങ്കിൽ ഈ ആവശ്യത്തിനായി അത് സൃഷ്ടിച്ച് പ്രവർത്തിപ്പിക്കാൻ മറ്റൊന്നും നൽകരുത്. അക്കൗണ്ടും UID-യും നിയമത്തിന്റെ കുറിപ്പിൽ എഴുതുക, കാരണം വിഷയമില്ലാത്ത നിയമം ആർക്കും സുരക്ഷിതമായി തിരുത്താൻ കഴിയാത്ത നിയമമാണ്.

കേൾക്കുന്ന ഫീൽഡുകൾ പാതയിൽ നിന്ന് വേർതിരിക്കുക

Transmission 4.x പിയർ കേൾക്കുന്ന വിലാസങ്ങൾ rpc-bind-address-ൽ നിന്ന് വേറിട്ട് രേഖപ്പെടുത്തുന്നു, ഈ വ്യത്യാസം പ്രധാനമാണ്. RPC ക്രമീകരണം വിദൂര നിയന്ത്രണ ശ്രോതാവിനെ മാത്രം നിയന്ത്രിക്കുന്നു, അതിനാൽ അത് മാറ്റുന്നത് പിയർ ട്രാഫിക്കിന് പാത തിരഞ്ഞെടുക്കുന്നില്ല. രണ്ട് ക്രമീകരണങ്ങളും ഒന്നായി വായിക്കുന്നതാണ് ശ്രദ്ധാലുവായി തോന്നുന്ന കോൺഫിഗറേഷനും ചോരുന്നതിനുള്ള ഏറ്റവും സാധാരണ കാരണം. അതേ രേഖ പിയറിന്റെ കേൾക്കുന്ന വിലാസം അസാധുവാകുമ്പോൾ ഒരു പകരമാർഗം വിവരിക്കുന്നു, അതായത് ലഭ്യമല്ലാത്ത വിലാസം രേഖപ്പെടുത്തിയ പകരസാഹചര്യമാണ്, ഉറപ്പായ നിരസിക്കലല്ല.

grep -E '"(peer-port|rpc-bind-address|bind-address-ipv4)"' /var/lib/transmission-daemon/.config/transmission-daemon/settings.json

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

ഉടമ പൊരുത്തം ശരിയായ ശൃംഖലയിൽ എഴുതുക

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

iptables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner transmission -j REJECT
ip6tables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
ip6tables -A OUTPUT -m owner --uid-owner transmission -j REJECT

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

tun0 അപ്രത്യക്ഷമാകുമ്പോൾ എന്ത് സംഭവിക്കുമെന്ന് തീരുമാനിക്കുക

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

ip link show tun0
iptables -S OUTPUT

അത് ഉദ്ദേശ്യപൂർവ്വം പരീക്ഷിക്കുക: ടണൽ നിർത്തുക, ഉപേക്ഷിക്കാൻ സുരക്ഷിതമായ കൈമാറ്റം ആരംഭിക്കുക, എന്തെങ്കിലും പുറത്തുപോകുന്നുണ്ടോ എന്ന് നോക്കുക. പിന്നീട് ടണൽ തിരികെ കൊണ്ടുവന്ന് ഉദ്ദേശിച്ച പാത വീണ്ടും പ്രവർത്തിക്കുന്നു എന്ന് സ്ഥിരീകരിക്കുക.

നിയമത്തിന് കാണാൻ കഴിയാത്ത പാതകൾ ഉൾക്കൊള്ളുക

പേരുകളുടെ പരിഹാരം ഒരു പ്രത്യേക പരിഹാരക പ്രോസസ് കൈകാര്യം ചെയ്തേക്കാം, പേരിടം അല്ലെങ്കിൽ സമർപ്പിത ഗേറ്റ്‌വേ അവയുടെ പങ്കിടൽ, ബൂട്ട്‌സ്ട്രാപ്പ് പാതകൾ അതിനായി രൂപകൽപ്പന ചെയ്തിട്ടുണ്ടെങ്കിൽ മറ്റൊരു അതിർത്തി നൽകാം. DNS ഏത് ഘടകത്തിന്റെ ഉടമസ്ഥതയാണ്, അത് അതേ നിർഗമ നിയമം പിന്തുടരുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുക. പിന്നീട് RPC നോക്കുക: rpc-whitelist ഉപയോഗത്തിലുണ്ടെങ്കിൽ അംഗീകൃത മാനേജ്മെന്റ് നെറ്റ്‌വർക്ക് കരാറിന്റെ ഭാഗമാണ്, വിശാലമായ RFC1918 പരിധി അല്ല.

ss -tunp | grep -i transmission

ഇന്റർഫേസ് കൗണ്ടറുകൾക്ക് നിരീക്ഷണത്തെ പിന്തുണയ്ക്കാം, പക്ഷേ ഏത് പ്രോസസ് ബൈറ്റുകൾ സൃഷ്ടിച്ചു എന്ന് തെളിയിക്കാനാവില്ല. ഉപേക്ഷിക്കാൻ അനുവാദമുള്ള കൈമാറ്റം നടത്തുക: ആദ്യം പ്രവർത്തിക്കുന്ന പാതയിൽ, പിന്നീട് തുടക്കത്തിൽ ടണലില്ലാതെ, അതിനുശേഷം തടസ്സം, പുനഃസംയോജനം, പുതുതായി സൃഷ്ടിച്ച ഇന്റർഫേസ് എന്നിവയിലൂടെ. പുതിയ ശ്രമവും ഇതിനകം തുറന്ന കണക്ഷനും രണ്ടും പരിശോധിക്കുക, കാരണം നിയമം പഴയ സോക്കറ്റിൽ പ്രയോഗിച്ചിട്ടുണ്ടാകണമെന്നില്ല. തീയതി, അക്കൗണ്ട്, ഫലം എന്നിവ പരിശോധനയോടൊപ്പം രേഖപ്പെടുത്തുക.

മുഴുവൻ ശൃംഖലയും വൃത്തിയാക്കുന്ന ഉദാഹരണം ഒട്ടിക്കുന്നത് ഒരു ദ്വാരത്തിന് പകരം പലത് നൽകുന്നു, അതിനാൽ നിയമങ്ങൾ മായ്ക്കുന്നതിന് പകരം ചേർക്കുക. അഞ്ച് പരിശോധനകളും കടന്നാൽ, ഉറപ്പ് വ്യക്തമാണ്: ക്ലയന്റിന്റെ ട്രാഫിക് ടണലിലൂടെ പുറത്തുപോകുന്നു അല്ലെങ്കിൽ ഒട്ടും പോകുന്നില്ല, അത് നിർബന്ധമാക്കുന്ന നിയമം ടണലിന്റെ സ്വന്തം പരാജയവും അതിജീവിക്കുന്നു.