¶ Описание
Для безопасной передачи данных между несколькими серверами требуется использовать протокол https, в котором есть поддержка шифрования.
Относительно простым решением является создание прокси-сервера через nginx, в котором будет настроена переадресация запросов адрес:порт_службы <-> адрес:порт_с_шифрованием.
Это позволит:
- Отделить внешний ip и порт, по которому будут обращаться сторонние адресаты по протоколу https, и внутренний адрес службы, по которому смогут обращаться локальные сервисы.
- С помощью одного выделенного порта сделать переадресацию на множество локальных портов служб. Даже если порты будут меняться, внешний айпи и порт останется неизменными. У адресатов ничего не сломается.
¶ Создание прокси-сервера
Для работы требуется скачать Nginx-дистрибутив для WIndows с официального сайта (Рекомендуется Mainline version).
¶ Генерация самоподписанного сертификата
- Скачать и установить OpenSSL (Не light версию!).
- Перейти в папку с OpenSSL.exe (Например, "C:\Program Files\OpenSSL-Win64\bin") и запустить оттуда консоль PowerShell.
- Сгенерировать самоподписанный сертификат командой
.\openssl.exe req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes -keyout cert_name.key -out cert_name.crt -subj "/CN=внешний_айпи" -addext "subjectAltName=IP:внешний_айпи"
Либо для доменного имени
.\openssl.exe req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes -keyout cert_name.key -out cert_name.crt -subj "/CN=Домен" -addext "subjectAltName=DNS:домен"
Здесь:
cert_name.crt - открытый ключ, который можно высылать на хостинги. Имя выбирается любое.
cert_name.key - закрытый ключ. Имя выбирается любое.
/CN=внешний_айпи - IP, где развёрнута служба.
/CN=Домен - доменное имя сервера, где развёрнута служба.
IP:внешний_айпи - альтернативный IP, где развёрнута служба.
DNS:домен - альтернативное доменное имя сервера, где развёрнута служба.
Важно! Генерировать сертификат на внешний(белый) IP, так как именно по нему будет обращение к сервису и он же будет указываться в конфигах далее.
- Сертификаты сгенерируются в этой же папке, откуда была запущена консоль. Установить в доверенные сертификаты ключ .crt
¶ Настройка Nginx
Полное руководство находится на официальном сайте. Есть на русском языке.
-
скачать Nginx-дистрибутив и распаковать куда-нибудь на диск.
-
Создать папку certs в директории папки conf, куда подложить сгенерированные ключи
-
Если нужно развернуть какую-нибудь html-страницу (Например, с виджетом), то папку с файлами требуется положить в папку html
-
Конфигурация настраивается в папке conf в файле nginx.conf
¶ Заполнение кофигурационного файла Nginx
Простая структура файла:
http {
server {
listen порт;
location / {
настройки
}
}
В блоке server настраиваются порты, к которым будет обращение
В блоке location настраиваются сопоставления адресов.
Таких блоков серверов может быть множество. Ниже представлена конфигурация для проксирования одной службы.
Однако поддержка нескольких служб в nginx должна осуществляться также и на стороне самих служб на программном уровне.
#user nobody;
worker_processes 1;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pid logs/nginx.pid;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
#log_format main '$remote_addr - $remote_user [$time_local] "$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';
#access_log logs/access.log main;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
server {
listen порт ssl;
server_name внешний_айпи;
ssl_certificate ../certs/cert_name.crt;
ssl_certificate_key ../certs/cert_name.key;
location / {
proxy_pass http://адрес_службы:порт/;
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;
proxy_http_version 1.1;
proxy_redirect off;
proxy_set_header "Connection" "";
proxy_pass_header Content-Type;
}
}
}
¶ Запуск сервера и дополнительные команды
- сервер запускается командой start nginx
- Перезапускается ./nginx -s reload
- Останавливается ./nginx -s stop
- Проверяется, есть ли запущенные процессы tasklist /fi "imagename eq nginx.exe"
- Также настоятельно рекомендую проверять nginx в запущенных процессах. Завершать можно из диспетчера.
После изменения в файле конфигурации требуется перезапускать nginx.
Чтобы проверить запустился ли сервер после команды start nginx, откройте в браузере страницу localhost, должна открыться страница nginx
На этапе запуска сервера, если что-то не так, в консоль будут выводиться ошибки. Также ошибки можно посмотреть в логах в папке logs.
Итогом должен стать рабочий адрес службы. Проверить это можно, например, зайдя в сваггер службы, либо сделать запрос в консоль curl https://ip:port/
Также можно обернуть nginx в контейнер и запускать из докера. Инструкция и описание reverse_proxy здесь.
¶ Как это работает на примерах
¶ Подписывание виджета для интеграции самоподписным сертификатом с добавлением нашего сертификата в доверенные на стороне интеграции
¶ Анализ задачи
Рассмотрим ситуацию, когда у клиента есть некий белый IP (для примера возьмем IP гугла 172.217.22.14). У нас есть сервер с виджетом Барс на windows (внутренний IP 192.168.1.100). Нам надо интегрировать виджет некую платежную систему, с доверенным сертификатом. Мы хотим, чтобы адрес вида http://192.168.1.100:5200 (виджет) был доступен по https://172.217.22.14 (стандартный порт https - 443)
- Клиент пробрасывает на своём сетевом оборудовании с порта 443 на любой свободный порт сервера. Например 5700. (Важно! Порт не должен совпадать с портом, по которому запущен виджет!)
- В nginx сервере у нас получается следующая конфигурация:
server {
# Nginx будет слушать входящие HTTPS-подключения на внутреннем порту 5700
listen 5700 ssl;
# Указываем путь к вашему сертификату и ключу
ssl_certificate C:/nginx/conf/ssl/server.crt;
ssl_certificate_key C:/nginx/conf/ssl/server.key;
# Указываем адрес вашего сервера (для имени в заголовках)
server_name 172.217.22.14;
# Настроить корень / для всего приложения
location / {
proxy_pass http://192.168.1.100:5200/;
# ИЛИ, если виджет на том же сервере: proxy_pass http://127.0.0.1:5200/;
# ИЛИ, если виджет на том же сервере: proxy_pass http://localhost:5200/;
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;
}
}
¶ Алгоритм сетевого обмена
- Пользователь вводит в браузере https://172.217.22.14/web/widget.
- Запрос через интернет попадает на белый IP-адрес вашего предприятия.
- На маршрутизаторе (роутере) предприятия настроен проброс портов (Port Forwarding): все входящие подключения на порт 443 (стандартный для HTTPS) перенаправляются на порт 5700 на вашем внутреннем сервере 192.168.1.100.
- Запрос доходит до Nginx, который "слушает" порт 5700.
- Nginx принимает HTTPS-соединение: Он использует ваш самоподписной сертификат и приватный ключ, чтобы расшифровать входящий запрос пользователя.
- Nginx действует как обратный прокси (Reverse Proxy): После расшифровки Nginx формирует новый, обычный HTTP-запрос и перенаправляет его вашему веб-приложению, которое работает на http://192.168.1.100:5200.
- Приложение обрабатывает запрос и отправляет ответ (HTML, JSON, etc.) обратно в Nginx.
- Nginx берет ответ от приложения, шифрует его с помощью того же сертификата.
- Зашифрованный ответ отправляется обратно через маршрутизатор.
- Ответ проходит через белый IP и интернет.
- Браузер пользователя получает ответ, расшифровывает его с помощью публичного ключа из сертификата и отображает страницу.
¶ Схема запросов БЕЗ добавления самоподписанного сертификата в доверенные (в большинстве случаев для работы не годится)
Пояснение к схеме:
- Браузер и Nginx договариваются о параметрах шифрования.
- Nginx отправляет браузеру свой самоподписной сертификат.
- Браузер проверяет, подписан ли сертификат одним из доверенных Центров сертификации (ЦС), которые встроены в него (VeriSign, Let's Encrypt и др.).
- Так как сертификат вы подписали сами, а не доверенный ЦС, браузер не может проверить его подлинность. Он не знает, ваш ли это сертификат или злоумышленника (атака "человек посередине").
- Браузер показывает пользователю большое красное предупреждение о том, что соединение небезопасно.
- Пользователь должен вручную принять риск и добавить исключение (обычно кнопка "Дополнительно" -> "Перейти на сайт (небезопасно)").
- Только после этого браузер и Nginx обменяются ключами и установят безопасное соединение. Важно: данные будут шифроваться, но личность сервера не подтверждена доверенной стороной.
¶ Схема запросов с добавлением самоподписанного сертификата в доверенные(используем в интеграциях)
Пояснение к схеме:
- Процесс начинается так же: пользователь делает запрос, а Nginx отправляет свой самоподписной сертификат.
- Ключевое отличие: Браузер проверяет подпись сертификата. Видя, что он подписан самим собой, он смотрит, есть ли у него в хранилище "Доверенные корневые центры сертификации" сертификат, которым был подписан этот.
- Поскольку ваш корневой сертификат (тот, который вы создали и распространили) был заранее добавлен в это хранилище, браузер доверяет ему автоматически.
- Далее браузер проверяет другие параметры (например, что имя в сертификате CN=172.217.22.14 совпадает с адресом сайта). Если всё совпадает, соединение считается безопасным и доверенным.
- Пользователь не видит никаких предупреждений. В адресной строке отображается стандартный замочек, как при использовании платных сертификатов от Let's Encrypt, DigiCert и т.д.
- Устанавливается полностью доверенное зашифрованное соединение.