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

இடைமுக எண்ணிகள் ஒரு கண்காணிப்பை ஆதரிக்கலாம், ஆனால் எந்தச் செயல்முறை பைட்டுகளை உருவாக்கியது என்பதை நிரூபிக்க முடியாது. கைவிட அனுமதிக்கப்பட்ட பரிமாற்றத்தைச் செய்யுங்கள்: முதலில் வேலை செய்யும் பாதையில், பின்னர் துவக்கத்தில் சுரங்கம் இல்லாமல், பின்னர் இடையூறு, மீளிணைப்பு மற்றும் புதிதாக உருவாக்கப்பட்ட இடைமுகம் வழியாக. புதிய முயற்சியையும் ஏற்கனவே திறந்த இணைப்பையும் சோதியுங்கள், ஏனெனில் விதி பழைய சாக்கெட்டுக்குப் பயன்படுத்தப்படாமல் இருக்கலாம். தேதி, கணக்கு மற்றும் முடிவைச் சோதனையுடன் பதிவு செய்யுங்கள்.

முழுச் சங்கிலியையும் தூய்மையாக்கும் உதாரணத்தை ஒட்டுவது ஒரு துளையை பலவற்றுக்கு மாற்றுகிறது, எனவே விதிகளை அழிப்பதற்குப் பதிலாகச் சேருங்கள். ஐந்து சரிபார்ப்புகளும் தேர்ச்சி பெற்றால், உத்தரவாதம் தெளிவானது: வாடிக்கையாளரின் போக்குவரத்து சுரங்கம் வழியாக வெளியேறுகிறது அல்லது அறவே வெளியேறாது, அதை வலியுறுத்தும் விதி சுரங்கத்தின் சொந்த தோல்வியையும் தாங்குகிறது.