Что такое обратный прокси: практическое руководство по DNS и вебу

Обратный прокси — это сервер, который принимает запросы от имени одного или нескольких внутренних серверов и пересылает их по нужному адресу. С точки зрения посетителя прокси часто является публичной конечной точкой: браузер не подключается к серверу приложения напрямую. Обратный прокси может терминировать HTTPS, маршрутизировать запросы по имени хоста или пути, балансировать трафик, кешировать ответы, сжимать содержимое и применять средства безопасности. DNS обычно указывает публичное имя хоста на прокси или на управляемый провайдером адрес перед ним. Затем прокси использует собственную конфигурацию маршрутизации, чтобы добраться до приложения выше по цепочке.

Обратный прокси и прямой прокси

Прямой прокси действует от имени клиентов: клиент отправляет через него запросы к внешним сервисам, часто из соображений политик, приватности или сетевого доступа. Обратный прокси действует от имени серверов: внешние клиенты подключаются к нему, а он пересылает запросы внутренним сервисам. Слово «прокси» само по себе поэтому неоднозначно. В архитектуре сайта обратный прокси, как правило, представляет публичную конечную точку сервиса и скрывает детали пула внутренних серверов. Он может направлять несколько доменов на одной инфраструктуре и разные пути на разные приложения, сохраняя одну публичную точку подключения.

DNS и обратный прокси решают разные части соединения. DNS сопоставляет имя хоста с публичным адресом или псевдонимом. Когда клиент подключился, прокси использует информацию о хосте в HTTP, индикацию имени сервера в TLS и собственную конфигурацию, чтобы выбрать нужный сервис. Поэтому запрос по голому IP может показать страницу по умолчанию или предупреждение о сертификате, даже если домен работает: запрос может не содержать ожидаемого контекста имени хоста. Точно так же смена DNS не создаёт автоматически подходящий маршрут в прокси и не выпускает сертификат. Оба уровня должны согласовываться по имени хоста и пункту назначения.

Типичные способы, которыми прокси становится частью сбоя

Домен может разрешаться правильно, а обратный прокси при этом указывает на мёртвый upstream, использует не тот порт или отклоняет имя хоста, для обслуживания которого не настроен. Сбои TLS возможны, если у границы нет действительного сертификата или неверно настроено зашифрованное соединение с upstream. Прокси может также вернуть тайм-аут, когда внутренний сервер перегружен или недоступен. И наоборот, исправное приложение может казаться недоступным, если DNS направляет клиентов на неверный адрес прокси. Сначала запишите ответ DNS, а затем по порядку изучите HTTP-ответ, TLS-соединение, журналы прокси и состояние внутренних серверов.

• Убедитесь, что DNS указывает на предполагаемую публичную конечную точку прокси.
• Проверьте, что у прокси есть правило для хоста и исправный upstream для домена.
• Проверяйте настройки TLS и на границе, и в upstream, когда HTTPS не работает.
• Используйте журналы прокси, чтобы отличить ошибки маршрутизации от ошибок приложения.
• Не считайте, что запрос IP раскрывает внутренний сервер.

Безопасность и эксплуатационные границы

Обратный прокси может уменьшить прямое воздействие на внутренние сервисы, но он не является границей безопасности автоматически, пока правила доступа не настроены и не поддерживаются. Исходный сервер должен принимать трафик только по предусмотренным путям там, где это позволяет архитектура. Административные интерфейсы нельзя размещать на публичных маршрутах без надлежащей аутентификации. Обновляйте программное обеспечение прокси, ограничивайте доступ к управлению и проверяйте пересылаемые заголовки: прокси становится доверенным интерпретатором информации от клиента и upstream. Задокументируйте, какая команда отвечает за DNS, правила прокси, сертификаты и внутренний сервер, чтобы реагирование на инцидент не буксовало, пока каждая группа считает ответственным другой уровень.

О связи между публичной границей и внутренним сервером читайте в статье что такое исходный сервер. О глобальных прокси-сетях — в статье как CDN используют DNS. Публичная проверка домена и IP подтвердит адрес, который отдаёт DNS, но маршрут обратного прокси и исправность приложения требуют собственных эксплуатационных проверок. Если держать эти обязанности раздельно, отладка получается точнее, а результат с адресом не принимают за полную диагностику инфраструктуры.

Явно закрепите владение правилами прокси

Обратный прокси стоит в критической точке передачи, поэтому записывайте, кто отвечает за DNS, маршрутизацию по хосту, сертификаты, описания upstream и политики доступа. Изменение может быть верным на одном уровне и всё равно не сработать, потому что другой уровень не обновили: DNS указывает на прокси, но в прокси нет виртуального хоста; маршрут есть, но сертификат выдан на другое имя; или upstream исправен, но файрвол блокирует подсеть прокси. Ведите простую схему пути и заведомо рабочий запрос для каждого производственного имени хоста. Во время инцидента сравнивайте публичный ответ DNS, журнал доступа прокси, состояние upstream и журнал приложения по одной и той же временной метке запроса или идентификатору корреляции.