Ответ
Разница заключается в том, знает ли клиентское приложение о существовании прокси и нужно ли его явно настраивать.
Прозрачный прокси (Transparent Proxy):
- Клиент не знает о его существовании. Трафик перенаправляется на прокси автоматически, обычно на уровне сетевого шлюза (маршрутизатора) или с помощью правил iptables.
- Использование в DevOps: Часто применяется для целей безопасности (например, веб-фильтрация, инспекция трафика WAF), кэширования контента (Squid) или балансировки нагрузки без изменения конфигурации приложений.
Пример правила iptables для перенаправления HTTP-трафика на локальный прокси (например, Squid):
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
Непрозрачный (явный) прокси (Explicit/Forward Proxy):
- Клиент должен быть явно сконфигурирован для использования прокси (например, через переменные окружения
HTTP_PROXY, настройки браузера или параметры запуска приложения). - Использование в DevOps: Доступ в интернет из изолированных сетей (например, приватных подсетей в облаке), обход ограничений, отладка сетевого трафика через инструменты вроде Charles или Fiddler.
Пример настройки для curl или wget:
export http_proxy="http://proxy.company.com:8080"
export https_proxy="http://proxy.company.com:8080"
curl https://api.example.com
| Сравнение в инфраструктуре: | Критерий | Прозрачный прокси | Непрозрачный прокси |
|---|---|---|---|
| Конфигурация клиента | Не требуется | Обязательна | |
| Обнаруживаемость | Сложнее для обнаружения клиентом | Известен клиенту | |
| Типичный сценарий | Принудительный фильтр трафика на границе сети | Контролируемый доступ в интернет для сервисов | |
| Ограничение | Не работает с HTTPS без MITM-сертификата | Требует поддержки прокси от клиентского софта |