iptables --uid-owner ემთხვევა Squid-ის ლოკალურ სოკეტებს და არა LAN მომხმარებლებს
Squid-ის გამავალი ტრაფიკის განხილვისას გამოიყენეთ --uid-owner-ის ლოკალური სოკეტის შემქმნელის მნიშვნელობა და გადაგზავნილი LAN პაკეტები ცალკე გაითვალისწინეთ.
iptables-ის owner შესაბამისობას შეუძლია ლოკალური პროცესის სოკეტის მიერ შექმნილი პაკეტების იდენტიფიცირება. მაგალითად, -m owner --uid-owner 1234 აღნიშნავს UID 1234-ის საკუთრებაში არსებულ ლოკალურ სოკეტს; ის არ იდენტიფიცირებს HTTP პროქსის მომხმარებლის სახელს.
Squid-ის მომუშავე მანქანაზე გაარჩიეთ ეს გზები:
| ტრაფიკი | შესაბამისი განსხვავება |
|---|---|
| კლიენტი უკავშირდება Squid-ს ამ მანქანაზე | შემომავალი კავშირი პროქსის მსმენელთან |
| Squid ხსნის დანიშნულების კავშირს | ლოკალურად შექმნილი გამავალი სოკეტი |
| LAN კლიენტი პირდაპირ მარშრუტიზაციას აკეთებს ამ მანქანის გავლით | გადაგზავნილი ტრაფიკი ლოკალური შემქმნელი სოკეტის გარეშე |
გაფართოება მოქმედებს OUTPUT და POSTROUTING-ში. გადაგზავნილ პაკეტებს ამ შესაბამისობისთვის დაკავშირებული ლოკალური სოკეტი არ აქვთ, ამიტომ FORWARD წესი ვერ შეძლებს დისტანციური კომპიუტერის მომხმარებლის აღმოჩენას Squid-ის UID-ის კითხვით.
ამიტომ Squid-ის საკუთარი გამავალი სოკეტების დაშვების პოლიტიკა მხოლოდ პროქსიზე დაფუძნებული ქსელის დიზაინის ერთ ნაწილს მოიცავს. კარიბჭის გავლით გადაგზავნა, მსმენელზე წვდომა, სხვა დაშვებული სერვისები და პროქსის ფაქტობრივი სერვისის ანგარიში შესაბამის სფეროში უნდა დამუშავდეს.
გამოიყენეთ კონფიგურირებული გაშვების იდენტობა იმის ნაცვლად, რომ ჩათვალოთ Squid-ის nobody-ს სახით მუშაობა. რამდენიმე პროცესს შეუძლია ერთი UID-ის გაზიარება, ამიტომ UID-ზე დაფუძნებული ნებართვა ანგარიშის საზღვარია და არა მტკიცებულება, რომ კონკრეტულმა შესრულებადმა ფაილმა ყველა დაშვებული კავშირი შექმნა.