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 е граница на акаунт, а не доказателство, че конкретен изпълним файл е създал всяка разрешена връзка.