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 — це межа облікового запису, а не доказ, що конкретний виконуваний файл створив кожне дозволене з'єднання.