Який шлях пакетів у Linux має забезпечувати використання проксі?
Розміщуйте засоби примусового використання мережевого проксі на тому шляху пакетів, яким вони мають керувати, а не фільтруйте лише з'єднання до шлюзу.
Шлюз Linux може запускати процес проксі й водночас маршрутизувати трафік повз нього. Це не той самий шлях пакетів.
| З'єднання | Відповідна локальна роль |
|---|---|
| Клієнт звертається до проксі на шлюзі | Трафік, адресований локальному хосту |
| Клієнт звертається до іншого хоста через шлюз | Пересланий трафік |
| Проксі відкриває з'єднання із сайтом | Трафік, створений локальним процесом |
Netfilter розрізняє шляхи входу, пересилання та виходу. Правило, що керує доступом до власного прослуховувача проксі на шлюзі, не обмежує автоматично кожне маршрутизоване з'єднання через цю машину.
Визначте, що треба забезпечити
Якщо клієнти зобов'язані використовувати схвалений проксі, політика має охоплювати й їхні альтернативні вихідні маршрути, а не лише дозволяти потрібний прослуховувач. Дозволяти з'єднання з будь-якою віддаленою службою лише тому, що вона використовує звичний порт проксі, — не те саме, що дозволяти тільки власну кінцеву точку проксі.
Тримайте власний подальший доступ проксі окремо. Для Squid розрізняйте володіння локальним сокетом і ідентичність користувача LAN перед застосуванням дозволу на вихідний трафік. Заборона всіх корисних вихідних з'єднань проксі зробила б потрібний шлях недоступним. Керівний трафік, розв'язання імен і підтримувані не-веб операції також потребують усвідомленої обробки в політиці розгортання.
Обсяг протоколів важливий. Правило TCP саме по собі не описує трафік UDP, включно з QUIC. Перехоплення трафіку — це інша архітектура; явний проксі HTTPS може надати CONNECT без розшифрування сеансу сайту.
Складіть карту передбачуваних з'єднань перед редагуванням набору правил. Налаштування браузера вибирає маршрут для клієнтів-учасників. Примус на рівні мережі вирішує, які інші маршрути можуть спрацювати. Ні те, ні інше не слід виводити лише з робочого входу до проксі.