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

इंटरफ़ेस काउंटर किसी अवलोकन का समर्थन कर सकते हैं, लेकिन यह सिद्ध नहीं कर सकते कि किस प्रक्रिया ने बाइट बनाए। ऐसा स्थानांतरण करें जिसे छोड़ने की अनुमति है: पहले काम करने वाले मार्ग पर, फिर आरंभ पर टनल के बिना, फिर व्यवधान, पुनः कनेक्शन और नए बने इंटरफ़ेस के माध्यम से। नया प्रयास और पहले से खुला कनेक्शन दोनों परखें, क्योंकि नियम पुराने सॉकेट पर लागू नहीं हुआ हो सकता है। तिथि, खाता और परिणाम परीक्षण के साथ दर्ज करें।

ऐसा उदाहरण चिपकाना जो पूरी श्रृंखला साफ़ कर दे, एक छेद को कई छेदों से बदल देता है, इसलिए नियम मिटाने के बजाय जोड़ें। जब पाँचों जाँचें पास हो जाएँ, तो गारंटी स्पष्ट है: क्लाइंट का ट्रैफ़िक टनल से बाहर जाता है या बिल्कुल नहीं जाता, और जो नियम इसे लागू करता है वह स्वयं टनल की विफलता को भी झेल जाता है।