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

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

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