iptables --uid-owner correspond aux sockets locales de Squid, pas aux utilisateurs du LAN
Utilisez le sens de créateur de socket locale de --uid-owner pour raisonner sur la sortie de Squid et gardez séparés les paquets LAN réacheminés.
La correspondance owner d'iptables peut identifier les paquets créés par la socket d'un processus local. Par exemple, -m owner --uid-owner 1234 désigne une socket locale possédée par l'UID 1234 ; cela n'identifie pas un nom d'utilisateur de proxy HTTP.
Sur une machine qui exécute Squid, distinguez ces chemins :
| Trafic | Distinction pertinente |
|---|---|
| Un client se connecte à Squid sur cette machine | Connexion entrante vers l'écouteur du proxy |
| Squid ouvre une connexion vers une destination | Socket sortante créée localement |
| Un client du LAN route directement par cette machine | Trafic réacheminé sans socket créatrice locale |
L'extension est valide dans OUTPUT et POSTROUTING. Les paquets réacheminés n'ont pas de socket locale associée pour cette correspondance, donc une règle FORWARD ne peut pas découvrir l'utilisateur de l'ordinateur distant en demandant l'UID de Squid.
Une politique autorisant les sockets sortantes propres à Squid ne traite donc qu'une partie d'une conception de réseau reposant uniquement sur un proxy. Le réacheminement par passerelle, l'accès à l'écouteur, les autres services autorisés et le compte réel du service proxy doivent être traités dans leur périmètre approprié.
Utilisez l'identité d'exécution configurée plutôt que de supposer que Squid tourne sous nobody. Plusieurs processus peuvent partager un même UID, donc une autorisation fondée sur l'UID est une frontière de compte, non la preuve qu'un exécutable précis a créé chaque connexion autorisée.