Transmission Linux-ზე: გამავალი ტრაფიკის შეზღუდვა პროცესის მფლობელით

Transmission-ის შემავალი პორტის დაბლოკვა VPN პოლიტიკა არ არის. ტორენტ კლიენტი ხსნის გამავალ კავშირებს პირებთან და ტრეკერებთან, წყვეტს სახელებს და შეიძლება შეინარჩუნოს დისტანციური მართვის მსმენელი, და თითოეულ ამ ნაკადს შეუძლია გავიდეს ინტერფეისიდან, რომელიც არ გქონდათ გათვალისწინებული. გაიარეთ ხუთი შემოწმება რიგრიგობით და საზღვრად მიიჩნიეთ firewall-ის წესი და არა კლიენტის პარამეტრები. ბოლო ორი შემოწმება ჩვეულებრივ გამოტოვებულია და სწორედ ისინი წყვეტენ, შენარჩუნდება თუ არა გარანტია, როცა გვირაბი ვარდება.

დაასახელეთ პროცესი, რომელიც ფლობს გადაცემას

სამაგიდო აპლიკაცია და სისტემური დემონი სხვადასხვა ანგარიშით მუშაობს, ხოლო მფლობელზე დაფუძნებული წესი მიჰყვება ანგარიშს და არა პროგრამის სახელს. გაარკვიეთ რომელი მათგანი მუშაობს, სანამ წესს დაწერთ. ცალკე სერვისული ანგარიში პოლიტიკას ზუსტ სუბიექტს აძლევს, ხოლო სამაგიდო მომხმარებელი თავის იდენტობას ბრაუზერებთან, რედაქტორებთან და სესიის ყველა სხვა რამესთან იზიარებს. დაადასტურეთ 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

გამოიყენეთ კლიენტის მართვის საშუალებები დანიშნულებისამებრ და გარანტია ჩადეთ firewall-ში. მოსმენის პარამეტრი მაინც შეიძლება სასარგებლო იყოს, მაგრამ ის არ ამტკიცებს, რომ ტრეკერებთან კონტაქტი, ლოკალური აღმოჩენა ან დელეგირებული ძიება ყველა გვირაბიდან გადის. როცა ეს ორი ეწინააღმდეგება, firewall წყვეტს.

ჩაწერეთ მფლობელის დამთხვევა სწორ ჯაჭვში

Netfilter-ის სახელმძღვანელო მფლობელის დამთხვევის შესახებ ხსნის, როგორ მიეკუთვნება ლოკალურად შექმნილი პაკეტები socket-ის ფაილის მფლობელ მომხმარებელს ან ჯგუფს. ეს მიკუთვნება არ ვრცელდება გადამისამართებულ ტრაფიკზე, ხოლო დამატებითი ჯგუფების დამთხვევა მკაფიო პარამეტრს მოითხოვს. წაიკითხეთ იმ გაფართოების სახელმძღვანელო, რომელსაც რეალურად იყენებთ და არა პირველი მაგალითი, რომელსაც იპოვით.

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

ინტერფეისის მთვლელებს შეუძლიათ დაკვირვების გამყარება, მაგრამ ვერ დაამტკიცებენ რომელმა პროცესმა წარმოქმნა ბაიტები. განახორციელეთ გადაცემა, რომლის მიტოვებაც ნებადართულია: ჯერ მომუშავე გზაზე, შემდეგ გაშვებისას გვირაბის გარეშე, შემდეგ შეწყვეტის, ხელახალი დაკავშირების და ახლად შექმნილი ინტერფეისის გავლით. გამოსცადეთ როგორც ახალი ცდა, ისე უკვე ღია კავშირი, რადგან წესი შესაძლოა ძველ socket-ზე არ გამოყენებულიყო. ჩაწერეთ თარიღი, ანგარიში და შედეგი ტესტთან ერთად.

მთელი ჯაჭვის გამწმენდი მაგალითის ჩასმა ერთ ხვრელს რამდენიმეთი ცვლის, ამიტომ დაამატეთ წესები და ნუ წაშლით მათ. როცა ხუთივე შემოწმება გაივლის, გარანტია ცხადია: კლიენტის ტრაფიკი გვირაბით გადის ან საერთოდ არ გადის, და წესი, რომელიც ამას ახორციელებს, თავად გვირაბის გაუმართაობას გადაურჩება.