Прямой и обратный прокси: чем отличаются и как работают

Главное отличие: чью сторону обслуживает посредник

Слова «прямой» и «обратный» не означают, что ответы идут только в одну сторону. В обоих случаях есть запрос и ответ. Отличие — в роли посредника относительно клиента и обслуживаемого сервиса. Такая терминология посредников закреплена в HTTP Semantics, RFC 9110.

Прямой прокси: сотрудник выходит в интернет

Клиент обращается к выбранному прокси, а тот — к разрешённому внешнему ресурсу. В явной схеме адрес и порт прокси задают в приложении или управляемой политике. Поддержка настроек различается: браузер, служба обновлений и приложение могут использовать разные механизмы.

• Политика доступа: кто и к каким назначениям может обращаться.
• Журналирование: события разрешений, отказов и соединений в доступном выбранному режиму объёме.
• Единый выход: часть внешних систем видит адрес корпоративной точки выхода, если трафик действительно проходит через неё.
• Дополнительные функции: аутентификация, категории, кэш и анализ контента — если они есть в продукте и настроены.

Прокси не становится обязательным путём только от появления записи в браузере. Если требуется централизованный контроль, отдельно проектируют разрешённый выход, исключения и доступ сервисов. Нельзя обещать, что одна настройка автоматически охватит весь трафик компьютера.

Явный прокси, PAC и перехват — разные способы подключения

• Явная настройка: приложение знает адрес посредника и использует поддерживаемый прокси-протокол.
• PAC: сценарий выбора прокси для поддерживающего его клиента. Он может назначать разные пути для разных обращений; это не сетевой запрет прямого выхода.
• Перехват на сети: трафик направляют к посреднику сетевой схемой. Для HTTPS и аутентификации возникают отдельные ограничения; такой режим нельзя считать эквивалентом явной настройки.

Примеры PAC и выбора пути приведены в документации Mozilla. Для рабочих станций заранее проверяют браузеры, системные службы, обновления, программы 1С и внешние интеграции. Фоновая служба не обязана наследовать настройки интерактивного пользователя. Для исключений определяют владельца, назначение, срок и способ контроля.

HTTPS через прямой прокси: что делает CONNECT

Для HTTPS через обычный явный HTTP-прокси клиент может запросить туннель методом CONNECT к нужному имени и порту. После успешного открытия по туннелю передаются данные TLS. Само наличие прокси при таком режиме не означает расшифровку HTTP-содержимого.

Посреднику доступны сведения для организации соединения и метаданные, зависящие от протокола и конфигурации. Но полный URL-путь, тело HTTPS-страницы, пароль или вложение нельзя объявлять видимыми только потому, что соединение прошло через туннель. Семантика метода описана в RFC 9110, CONNECT.

Ограничивают не только пользователей, но и разрешённые назначения и порты. Прокси с произвольным CONNECT может стать путём к внутренним службам, которым внешний клиент не должен доверять. Правила и конечный запрет требуют проверки для установленной версии продукта.

Расшифровка HTTPS — отдельная функция, а не свойство любого прокси

Для анализа HTTPS-содержимого посредник может завершать одно TLS-соединение и устанавливать другое. На управляемом клиенте тогда требуется предусмотренное доверие к удостоверяющему центру, а на посреднике — корректная проверка внешнего сервера. Отключение проверки сертификатов не является нормальной заменой такой настройки.

• Определяют поддерживаемые приложения и исключения: закрепление сертификата, взаимная TLS-аутентификация и особенности протокола могут нарушить работу.
• Защищают ключи и доверенный центр; ограничивают операторские права и фиксируют изменения политики.
• Определяют допустимый объём анализа и хранения, правила обращения с чувствительными данными и информирование пользователей в принятом в компании порядке.
• Отдельно проверяют внешнее доверие, обновление сертификатов и работу интеграций после изменения.

У Squid режимы туннелирования и расшифровки описаны отдельно в документации ssl_bump с указанием доступных версий. Это пример механизма, а не утверждение, что любую редакцию Squid или любой NGFW можно настроить одинаково.

Обратный прокси: публикуем своё приложение

Пользователь открывает, например, корпоративный портал под именем компании. DNS и сеть приводят его к внешней точке входа. Обратный прокси принимает запрос и передаёт его назначенному внутреннему приложению, затем возвращает ответ.

Так можно централизовать внешний HTTPS, домены, часть правил доступа, маршрутизацию и журналы. Внутренний сервер при этом не обязан иметь прямой доступ из интернета. Но изоляцию обеспечивает реальная сеть и правила, а не само слово reverse proxy.

В руководстве NGINX показана передача запросов получателю. Один прокси может обслуживать несколько доменов или путей, если это согласовано с приложениями. Перенос приложения в подпуть способен потребовать изменения ссылок, cookie и перенаправлений.

Портал, почта и 1С: что проверить перед публикацией

• Портал / Bitrix: базовый адрес, HTTPS, загрузку файлов, авторизацию, фоновые интеграции и поддерживаемые длительные соединения.
• Веб-почта: форму входа, работу с вложениями, особенности продукта и его доверие к внешнему входу. HTTP-прокси не публикует автоматически SMTP, IMAP и все почтовые протоколы.
• Веб-интерфейс 1С: поддерживаемый веб-сервер, публикацию базы, лицензии, тип аутентификации, долгие операции и обмены.
• API: пути, методы, заголовки авторизации, ограничения размера, таймауты, совместимость клиентов и контроль повторных изменений данных.

Reverse proxy не добавляет приложению отсутствующую поддержку публикации и не заменяет его обновление. Административные панели, диагностические адреса и служебные функции не нужно открывать вместе с пользовательским интерфейсом по умолчанию.

Два участка TLS: клиент → прокси и прокси → сервер

При завершении HTTPS на обратном прокси внешний сертификат обслуживает точка входа. Второй участок может быть HTTP или HTTPS по выбранной схеме. Значок замка в браузере подтверждает только то TLS-соединение, которое установил браузер, а не всю внутреннюю цепочку.

Если второй участок защищён TLS, настраивают доверие к сертификату сервера, проверку имени и при необходимости SNI. Для внешнего участка важны имя, цепочка, обновление и контроль срока действия сертификата. Эти роли различаются в руководстве HAProxy.

Проверяют также, что приложение понимает исходную схему HTTPS. Иначе возможны циклические редиректы на входе, неверные абсолютные ссылки или неправильные свойства cookie. Заголовок о схеме должен приходить по доверенному пути, а не приниматься от любого клиента.

Реальный IP: почему нельзя доверять любому X-Forwarded-For

При проксировании приложение часто видит сетевой адрес посредника. Исходный клиент может передаваться через согласованный HTTP-заголовок, например X-Forwarded-For, или другой поддерживаемый механизм. Но внешний клиент способен самостоятельно прислать такой заголовок.

• Определяют, какие прокси входят в доверенную цепочку и от каких адресов приложение принимает сведения о клиенте.
• На границе формируют или обрабатывают заголовки по выбранной модели; не используют произвольный пользовательский текст как подтверждённый IP.
• Закрывают обходной прямой доступ к backend, если безопасность рассчитана на прохождение через входной прокси.
• Проверяют фактический адрес в приложении, журнале и ограничениях доступа. Это три связанных, но не обязательно одинаково настроенных места.

Модуль NGINX realip отдельно задаёт доверенных отправителей. PROXY protocol требует поддержки принимающей стороны и не является обычным HTTP-заголовком.

Аутентификация на прокси и права в приложении

Прямой прокси может проверять сотрудника перед выходом наружу. Обратный — выполнять входную проверку пользователя или обращаться к сервису идентификации, если это поддерживает выбранная схема. Это не означает, что у приложения больше не нужны собственные права.

После внешней проверки приложение должно получать идентичность только от доверенного посредника. Пользовательский заголовок с именем «admin» не является доказательством входа. Обходной адрес backend, незащищённые служебные маршруты или потеря проверки на одном location могут нарушить всю схему.

Для сотрудников, подрядчиков и технических интеграций задают разные разрешения, срок доступа и способ отмены. Способ MFA выбирают с учётом протокола: интерактивная веб-проверка не подходит автоматически для любой фоновой службы.

Кэш: ускорение возможно, утечка чужой страницы тоже

Кэш сохраняет разрешённые ответы и может уменьшать повторные обращения к серверу. Его включают для подходящего контента, с правильным ключом, временем жизни и условиями обхода. Это отдельная функция, а не обязательное поведение каждого прокси.

• Статические файлы и публичный контент часто имеют другую политику, чем личный кабинет.
• Ответ, зависящий от пользователя, cookie или авторизации, нельзя бездумно отдавать из общего кэша другим людям.
• Проверяют заголовки управления кэшем, обновление, принудительную очистку и поведение после выхода из учётной записи.
• Кэш не является резервной копией базы и не обеспечивает целостность пользовательских данных.

Настройки пропуска и отключения кэширования рассматриваются в NGINX Content Caching. Для персонализированного приложения безопаснее сначала подтвердить корректность политики, чем включать кэширование всех ответов ради показателя скорости.

Файлы, WebSocket и долгие операции: почему обычной страницы мало

• Размер запроса: большой документ может упереться в лимит загрузки на прокси раньше, чем попадёт в приложение.
• Время: подключение к серверу, ожидание данных и вся операция — разные интервалы. Увеличение любого таймаута до часа не лечит зависание базы.
• Длительные соединения: WebSocket, потоковая передача и особенности HTTP-версии требуют поддержки и подходящих параметров.
• Буферизация: влияет на потоковую выдачу, память и временные файлы. Настройка должна соответствовать поведению приложения.

Например, для классического HTTP/1.1 WebSocket NGINX отдельно описывает передачу служебных заголовков и ожидание данных в руководстве WebSocket proxying. Нельзя из работоспособности обычного GET сделать вывод о совместимости всех режимов.

Для 1С и API фиксируют ожидаемое время тяжёлой операции и поведение при обрыве. Если запись уже выполнена, повтор запроса после таймаута способен создать дубль; это вопрос приложения и семантики операции, а не только прокси.

Прокси, NAT, VPN, WAF и балансировщик: разные роли

• NAT меняет адреса и/или порты в сетевой схеме. Он не равен HTTP-аутентификации или анализу содержимого.
• VPN организует защищённое сетевое соединение в выбранном режиме. Прокси обслуживает определённые обращения и не обязан переносить весь трафик устройства.
• WAF применяет правила защиты веб-приложения. Наличие reverse proxy не означает наличие и настройку WAF.
• Балансировщик выбирает получателя из пула. Прокси может иметь только один backend, а может совмещать роли.
• Защита от DDoS требует соответствующей ёмкости и фильтрации; посредник не спасает от любого переполнения канала.

Для подробностей распределения запросов есть отдельная статья о балансировщике. При выборе продукта проверяют конкретные функции, режим, редакцию и лицензию; не складывают все обещания информационной безопасности в слово «прокси».

Как не превратить корпоративный прокси в открытый шлюз

Прямой прокси должен обслуживать согласованных клиентов и назначения. Если его без ограничений открыть наружу, посторонние могут использовать ваш выход и обращаться к службам, доступным с самого прокси. Одной настройки пароля без сетевой и протокольной модели недостаточно.

• Ограничьте доступ к входу назначенными сетями или защищённым путём и нужными пользователями.
• Разрешайте подходящие назначения и порты; учитывайте локальные и служебные ресурсы, включая адреса метаданных облака.
• Задайте явный конечный запрет и проверьте порядок правил для версии установленного продукта.
• Проверьте результат и из разрешённой, и из неразрешённой точки — в согласованном контуре.

Squid http_access описывает риски чрезмерно разрешающего доступа и минимальную модель ограничений. Пример документации нельзя слепо переносить между версиями: перечень доступных директив меняется.

Журналы: контроль работы и помощь в расследовании

На прямом прокси полезны данные о клиенте, политике, назначении и результате соединения в доступном режиме объёме. На обратном — время, маршрут, код, выбранный backend и длительность этапов, если продукт это фиксирует.

• Синхронизируйте время и согласуйте идентификаторы запросов между прокси и приложением.
• Сопоставляйте ошибки с обновлением, изменением политики, отказом DNS и событиями СУБД.
• Защитите журналы, задайте сроки хранения и ротацию; контролируйте заполнение диска.
• Не сохраняйте пароли, токены и полные чувствительные URL только ради подробности.

Например, Squid отдельно настраивает access_log. Одна запись соединения с внешним сервисом не доказывает, какой именно документ был загружен и прочитан; для расследования учитывают пределы видимости HTTPS и другие источники.

Мониторинг должен видеть не только живой процесс прокси, но и рабочий путь: разрешённый запрос наружу либо пользовательскую операцию опубликованного приложения.

Три прикладные ситуации

Как проверить путь запроса командами

Примеры ниже — Linux и curl. Имена portal.example.test, адреса 192.0.2.10 и 192.0.2.20 служат подстановками: замените их параметрами своего согласованного контура. Команды не устанавливают прокси и не изменяют рабочие правила. При подготовке статьи реальную публикацию приложения и прокси-проход не испытывали.

1. Явно обратиться через прямой прокси

curl --proxy http://192.0.2.10:3128 --noproxy '' --connect-timeout 3 --max-time 15 --silent --show-error --dump-header - --output /dev/null https://portal.example.test/

--proxy задаёт HTTP-прокси. --noproxy '' отменяет исключения из окружения для этой проверки. Для HTTPS curl запрашивает туннель через такой прокси; успешность подтверждают ответ, журнал посредника и ожидаемое назначение. 407 означает требование прокси-аутентификации, а не обязательно поломку сайта. Пароли в примере намеренно не передаются в командной строке.

2. Сравнить с прямым обращением в разрешённом тестовом контуре

curl --noproxy '*' --connect-timeout 3 --max-time 15 --silent --show-error --dump-header - --output /dev/null https://portal.example.test/

--noproxy '*' отключает использование прокси curl для этого обращения. Это диагностическое сравнение там, где прямой тест согласован, а не инструкция обходить корпоративные ограничения. Успешный ответ сам по себе не определяет весь сетевой маршрут: сопоставьте журналы и политику.

3. Проверить обратный прокси до изменения DNS

curl --noproxy '*' --resolve portal.example.test:443:192.0.2.20 --connect-timeout 3 --max-time 15 --silent --show-error --dump-header - --output /dev/null https://portal.example.test/

--resolve направляет выбранную пару имени и порта на указанный адрес, сохраняя имя для HTTPS. Нужны правильный сертификат и доверие. --dump-header - выводит заголовки, --output /dev/null убирает тело; таймауты ограничивают соединение и всю операцию. Ключи описаны в руководстве curl.

После сетевой проверки выполните вход пользователя, загрузку файла и нужную операцию. Проверьте запрещённый доступ, корректное определение клиента, возврат после изменения и журналирование. Отсутствие ошибки curl ещё не означает приёмку приложения.

Карточки для настройки и проверки

Поможем организовать управляемый доступ и публикацию

Вопросы и ответы