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

इंटरफेस काउंटर निरीक्षणाला पुष्टी देऊ शकतात, पण कोणत्या प्रक्रियेने बाइट तयार केले हे सिद्ध करू शकत नाहीत. सोडण्यास परवानगी असलेले हस्तांतरण करा: आधी कार्यरत मार्गावर, नंतर सुरुवातीला टनेलशिवाय, नंतर व्यत्यय, पुन्हा जोडणी आणि नव्याने तयार केलेल्या इंटरफेसद्वारे. नवा प्रयत्न आणि आधीच उघडे असलेले जोडणी दोन्ही चाचणी करा, कारण नियम जुन्या सॉकेटला लागू झाला नसेल. तारीख, खाते आणि निकाल चाचणीसह नोंदवा.

संपूर्ण साखळी स्वच्छ करणारे उदाहरण पेस्ट करणे एका छिद्राच्या बदल्यात अनेक छिद्रे देते, म्हणून नियम पुसण्याऐवजी जोडा. जेव्हा पाचही तपासण्या उत्तीर्ण होतील, तेव्हा हमी स्पष्ट आहे: क्लायंटची रहदारी टनेलमधून बाहेर जाते किंवा अजिबात जात नाही, आणि जो नियम ते लागू करतो तो टनेलच्याच अयशस्वीतेला तोंड देऊन टिकतो.