iptables --uid-owner супадае з лакальнымі сокетамі Squid, а не з карыстальнікамі LAN
Выкарыстоўвайце значэнне --uid-owner як стваральніка лакальнага сокета, разважаючы пра выхад Squid, і трымайце перанакіраваныя пакеты LAN асобна.
Супастаўленне owner у iptables можа вызначыць пакеты, створаныя сокетам лакальнага працэсу. Напрыклад, -m owner --uid-owner 1234 азначае лакальны сокет, які належыць UID 1234; ён не вызначае імя карыстальніка HTTP-проксі.
На машыне з Squid адрознівайце гэтыя шляхі:
| Трафік | Адпаведнае адрозненне |
|---|---|
| Кліент падключаецца да Squid на гэтай машыне | Уваходнае злучэнне да слухача проксі |
| Squid адкрывае злучэнне да прызначэння | Лакальна створаны выходны сокет |
| Кліент LAN маршрутызуецца напрамую праз гэтую машыну | Перанакіраваны трафік без лакальнага сокета-стваральніка |
Пашырэнне дзейснае ў OUTPUT і POSTROUTING. Перанакіраваныя пакеты не маюць звязанага лакальнага сокета для гэтага супастаўлення, таму правіла FORWARD не можа выявіць карыстальніка аддаленага камп'ютара, запытаўшы UID Squid.
Такім чынам, палітыка, якая дазваляе ўласныя выходныя сокеты Squid, закранае толькі частку схемаў сеткі, пабудаваных выключна на проксі. Перасылка праз шлюз, доступ да слухача, іншыя дазволеныя службы і фактычны ўліковы запіс службы проксі павінны апрацоўвацца ў адпаведнай сферы.
Выкарыстоўвайце наладжаны ідэнтыфікатар выканання, а не здагадку, што Squid працуе як nobody. Некалькі працэсаў могуць дзяліць адзін UID, таму дазвол на аснове UID — гэта мяжа ўліковага запісу, а не доказ, што пэўны выканальны файл стварыў кожнае дазволенае злучэнне.