Реверс прокси (reverse proxy) - это очень рекомендуемый метод для выхода сервера приложений в Интернет. Серверы приложений, например те, на которых работают приложения Node.js или минимальный встроенный веб-сервер Flask, часто привязываются к localhost с помощью TCP-порта. Это означает, что по умолчанию ваше приложение доступно только локально на машине, на которой оно расположено.
Хотя можно указать другую точку привязки, чтобы обеспечить доступ через Интернет, эти серверы приложений предназначены для обслуживания через обратный прокси-сервер в производственных средах. Такая настройка обеспечивает несколько преимуществ с точки зрения безопасности:
- изоляция сервера приложений от прямого доступа в Интернет
- централизация защиты брандмауэра
- минимизация плоскости атаки для таких распространенных угроз, как атаки типа "отказ в обслуживании".
С точки зрения клиента взаимодействие с обратным прокси-сервером ничем не отличается от прямого взаимодействия с сервером приложений. Функционально это одно и то же, и клиент не видит разницы. Клиент запрашивает ресурс, а затем получает его, при этом от него не требуется никакой дополнительной настройки.
В этом руководстве мы покажем, как настроить обратный прокси с помощью Nginx, популярного веб-сервера и решения для обратного прокси. Вы настроите Nginx в качестве обратного прокси с помощью директивы proxy_pass и передадите соответствующие заголовки из запроса клиента. Если у вас нет под рукой сервера приложений для тестирования, вы можете настроить тестовое приложение с помощью WSGI-сервера Gunicorn.
Конфигурирование серверного блока
Рекомендуется создавать собственный файл конфигурации для новых добавлений серверного блока, а не редактировать конфигурацию по умолчанию. Создайте и откройте новый файл конфигурации Nginx с помощью nano или удобного текстового редактора. Хотя в данном примере мы используем nano, вы можете использовать любой текстовый редактор по своему усмотрению:
| 1 | sudo nano /etc/nginx/sites-available/your_domain |
Вставьте в новый файл следующие слова, обязательно заменив их на your_domain и app_server_address. Если у вас нет сервера приложений для тестирования, по умолчанию используйте http://127.0.0.1:8000 для дополнительной настройки сервера Gunicorn на следующем шаге:
| 1 2 3 4 5 6 7 8 9 10 | server { listen 80; listen [::]:80; server_name your_domain www.your_domain; location / { proxy_pass app_server_address; include proxy_params; } |
Сохраните и выйдите, в nano это можно сделать, нажав CTRL+O, а затем CTRL+X.
Этот конфигурационный файл начинается со стандартной настройки Nginx, в которой Nginx будет прослушивать порт 80 и отвечать на запросы, поступающие на адреса your_domain и www.your_domain. Функциональность обратного прокси-сервера включается с помощью директивы proxy_pass в Nginx. При такой конфигурации переход на ваш_домен в локальном веб-браузере будет аналогичен открытию адреса app_server_address на удаленной машине. Хотя в данном руководстве рассматривается проксирование только одного сервера приложений, Nginx способен выступать в качестве прокси-сервера сразу для нескольких серверов. Добавляя по мере необходимости дополнительные блоки размещения, можно объединить несколько серверов приложений через прокси в одно целое веб-приложение.
Все HTTP-запросы сопровождаются заголовками, которые содержат информацию о клиенте, отправившем запрос. Сюда входят такие сведения, как IP-адрес, предпочтения кэша, отслеживание файлов cookie, статус авторизации и т.д. Nginx предоставляет некоторые рекомендуемые настройки пересылки заголовков, которые вы включили в качестве proxy_params, а подробности можно найти в файле /etc/nginx/proxy_params:
| 1 2 3 4 | proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; |
При использовании обратных прокси-серверов ваша цель - передать соответствующую информацию о клиенте, а иногда и информацию о самом обратном прокси-сервере. Существуют случаи, когда прокси-серверу необходимо знать, какой обратный прокси-сервер обработал запрос, но обычно важная информация содержится в исходном запросе клиента. Для того чтобы передать эти заголовки и сделать информацию доступной в тех местах, где она ожидается, Nginx использует директиву proxy_set_header.
По умолчанию, когда Nginx выступает в роли обратного прокси, он изменяет два заголовка, удаляет все пустые заголовки и затем передает запрос. Два изменяемых заголовка - это заголовок Host и Connection. Существует множество HTTP-заголовков, и вы можете посмотреть этот подробный список HTTP-заголовков, чтобы получить более подробную информацию о назначении каждого из них, однако здесь будут рассмотрены те, которые имеют отношение к обратным прокси.
Вот заголовки, передаваемые proxy_params, и переменные, в которых хранятся данные:
- Host: Этот заголовок содержит исходный хост, запрошенный клиентом, который представляет собой домен и порт сайта. Nginx хранит его в переменной $http_host.
- X-Forwarded-For: Этот заголовок содержит IP-адрес клиента, отправившего исходный запрос. Он также может содержать список IP-адресов, в котором первым идет IP-адрес исходного клиента, а затем список всех IP-адресов обратных прокси-серверов, через которые прошел запрос. Nginx хранит этот список в переменной $proxy_add_x_forwarded_for.
- X-Real-IP: Этот заголовок всегда содержит один IP-адрес, принадлежащий удаленному клиенту. В отличие от аналогичного X-Forwarded-For, который может содержать список адресов. Если X-Forwarded-For не присутствует, то он будет таким же, как и X-Real-IP.
- X-Forwarded-Proto: Этот заголовок содержит протокол, использованный исходным клиентом для соединения, будь то HTTP или HTTPS. Nginx хранит его в переменной $scheme.
Далее включите этот конфигурационный файл, создав ссылку из него на каталог sites-enabled, который Nginx считывает при запуске:
| 1 | sudo ln -s /etc/nginx/sites-available/your_domain /etc/nginx/sites-enabled/ |
Теперь можно проверить конфигурационный файл на наличие синтаксических ошибок:
| 1 | sudo nginx -t |
Если проблем не обнаружено, перезапустите Nginx для применения изменений:
| 1 | sudo systemctl restart nginx |
Теперь Nginx настроен как обратный прокси для вашего сервера приложений, и вы можете обращаться к нему из локального браузера, если ваш сервер приложений запущен. Если у вас есть предполагаемый сервер приложений, но он не запущен, можно перейти к запуску предполагаемого сервера приложений. Оставшуюся часть данного руководства можно пропустить.
В противном случае перейдите к настройке тестового приложения и сервера с Gunicorn на следующем шаге.
Тестирование обратного прокси с помощью Gunicorn (необязательно)
Если перед началом работы над этим руководством у вас был подготовлен и запущен сервер приложений, то теперь вы можете посетить его в браузере ваш домен.
Однако если у вас нет под рукой сервера приложений для тестирования обратного прокси, вы можете выполнить следующие шаги по установке Gunicorn вместе с тестовым приложением. Gunicorn - это WSGI-сервер на языке Python, который часто используется в паре с обратным прокси-сервером Nginx.
Далее вы напишете функцию Python, которая будет возвращать "Hello World!" в качестве HTTP-ответа, который будет отображаться в веб-браузере. Создайте файл test.py с помощью nano или другого текстового редактора:
| 1 | nano test.py |
Вставьте в файл следующий Python-код:
| 1 2 3 | def app(environ, start_response): start_response("200 OK", []) return iter([b "Hello, World!"]) |
Это минимальный код, необходимый Gunicorn для запуска HTTP-ответа, который отображает строку текста в веб-браузере. После ознакомления с кодом сохраните и закройте свой файл.
Теперь запустите свой сервер Gunicorn с помощью следующей команды:
| 1 | gunicorn -w 4 test:app |
Эта команда запускает сервер Gunicorn с 4 рабочими процессами (как указано в опции -w 4), выполняющими ваше тестовое приложение. Теперь ваше приложение доступно по адресу http://127.0.0.1:8000, а благодаря настройке обратного прокси-сервера Nginx оно также доступно по адресу http://your_domain.
Заключение
Из этого руководства вы узнали, как настроить Nginx в качестве обратного прокси-сервера для сервера приложений. Такая настройка дает ряд преимуществ, включая повышенную безопасность и возможность обслуживать несколько серверов приложений одновременно. Вы также узнали, как передавать важную информацию из запроса клиента на сервер приложений с помощью директивы proxy_set_header. Независимо от того, работаете ли вы с приложением Node.js, сервером Flask или любым другим сервером приложений, обратный прокси является неотъемлемой частью безопасной и эффективной производственной среды.