Среди множества инфраструктурных сервисов, которые образуют единую корпоративную систему существует Proxy. Его основная цель стать промежуточным узлом, при передаче трафика и выполнить заранее заложенный функционал по изменению/сниффингу, проходящих соединений.
По назначению существует два вида подобных решений forward и reverse-прокси, где первый перенаправляет через единую точку трафик в наружу, а второй наоборот с внешнего сегмента на внутренний. В данном материале рассмотрим второй вариант его имплементации и настроим сервис для работы.
Что такое Reverse Proxy?
Как упоминали ранее, Reverse Proxy представляет собой промежуточный узел, через который проходит внешний трафик на сервера, соответственно от клиентов.
В таких случаях, данное решение обусловлено потребностью в балансировке нагрузки на узлы, так как обработка самих пакетов может быть достаточно нагрузочной, то различные подходы в их балансировании могут ее снизить. А так же может быть узлом контроля проходящего трафика, к примеру локальным WAF или же узлом перенаправления к ICAP-серверам.
При создании облачного сервера от Serverspace, у каждого из стандартных репозиториев задан ключ. Для выполнения тестов, вы можете использовать изолированную среду VPS сервера, на любой из двух платформ vStack cloud или же VMware cloud. Нажмем на кнопку Создать сервер и выберем конфигурацию, подходящую под наши задачи, затем нажмем кнопку Создать.
Потребуется некоторое время для развертывания серверных мощностей. После чего вы можете подключиться любым из удобных способов.
Развертывание и настройка
Для начала выберем пакет ПО, которое выполняет функции подобного проксирования, обычно простые веб-сервера имеют такую функциональность, поэтому предоставим пакет Nginx:
После перейдем к настройке нашего сервиса по стандартной директории /etc/nginx, внутри нам интересны два файла, которые отвечают за глобальную настройку сервиса и виртуальных хостов, перейдем ко второму:
Если ваш файл виртуальных хостов называется иначе, то зайдите именно в него с помощью nano. Рассмотрим основной синтаксис виртуального хоста, который определяется по полю SNI в приходящем сетевом пакете:
listen ip:port;
server_name domain_name;
root /path/to/site-file;
index /index.html;
..
location / {}
..
}
Заполните основные поля с метаданными вашего веб-сервера, то на каком порте будет доступен ваш веб, какое доменное имя будет обрабатываться и т.д. Обратите внимание, что поле location будет отвечать за действия с пакетом, который пришел по указанному пути. Сейчас это обычный веб-сервер, чтобы он стал reverse-proxy необходимо добавить директивы в location:
proxy_pass http://192.168.1.10:80;
proxy_set_header Host $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;
}
Для понимания, чем отличаются reverse-proxy и веб-сервер сравните директивы двух путей /hello и /cats, во втором случае мы указываем путь, где лежат наши данные, а в первом проксируем соединение. Обратите внимание, директива proxy_pass позволяет установить соединение с ресурсом и как клиент передать пакеты, предварительно изменив их директивой proxy_set_header.
Каждая из них так же имеет свой функционал:
- HOST укажет хосты, к которым необходимо обратиться;
- X-Real-IP пропишет реальный адрес клиента перед проксированием;
- X-Forwarded-For укажет кому проксирует;
- X-Forwarded-Proto укажет какую схему/протокол для этого используется.
После чего видоизмененные пакеты будут отправлены на Upstream или же Backend, где дальше будет обработан веб-приложением. Сохраним файл и создадим ссылку на конфиг для его автозагрузки:
Либо замените название файла на свое и создайте также ссылку в enabled часть. После перезапустите nginx или заставьте его перечитать конфиг:
Так как nginx-сервер слушает на всех интерфейсах по-умолчанию, то трафик приходя на устройство будет проксироваться и уходить на бэк. Если возникает потребность еще и в предварительном терминировании SSL-трафика, то добавьте директив на его обработку:
ssl_certificate_key www.example.com.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
После чего трафик будет передан в открытом виде, где дальнейшие решения смогут обработать, поступающие пакеты. Так же в нашей базе знаний вы можете найти материалы, о том как можно настроить WAF на основе такого Reverse Proxy решения!