Обратный SSL-прокси к 1С

////

Большое значение имеет шифрование при обмене информацией через интернет, особенно таких чувствительных данных, как логин и пароль. Если для работы применяется веб-публикация баз, необходимо позаботиться о наличии SSL сертификата и настроенного на его применение веб-сервера, дающего возможность подключаться к базам. Подобная настройка может быть выполнена непосредственно на стороне веб-сервера (Apache или IIS), а может на обратном прокси, терминирующим множество SSL подключений к различным сервисам и распределяющим запросы между ними на основании запрашиваемых адресов. В этой статье речь пойдет об организации обратного SSL прокси на базе nginx + LetsEncrypt для выпуска SSL сертификатов для доступа к базам 1С по протоколу HTTPS. Для запуска прокси использован nginx-certbot

Зачем нужен обратный прокси

Обратный прокси выполняет одну из важнейших функций — применяет ко всем внешним подключениям определенные политики. Это может быть распределение, в зависимости от запрашиваемого имени, балансировка нагрузки, отдача статического содержимого из определенных каталогов, а также точка терминирования SSL соединений. На обратном прокси может располагаться wildcart сертификат, несколько простых сертификатов или сертификат на несколько имен. Все соединения между прокси и клиентами будут зашифрованы этим сертификатом, а на бекэнд серверах со службами можно будет не беспокоиться о настройке SSL и сроках действия сертификатов. Таким образом, с определенного момента, наличие обратного прокси снижает стоимость и увеличивает эффективность поддержки SSL на веб-серверах.

Назначение обратного прокси — терминирование SSL (HTTPS) и распределение HTTP запросов по серверам

Опубликованные базы 1С, также, как и другие веб приложения, могут работать через обратный прокси. В этом случае веб-сервер IIS или apache, с помощью которого публикуется база, может работать без настройки SSL в качестве бекэнд сервера, а обратный прокси, в роли которого применен nginx, терминирует ssl соединения к внешнему адресу из интернета и передает запрос на этот бекэнд. Бекэнд обрабатывает запрос и возвращает его обратно, через прокси сервер. Отдаваемый ответ оборачивается в SSL и возвращается клиенту. Так работает схема в общих чертах.

Если в сети имеется еще один веб-сервер, на котором находятся еще опубликованные базы 1С или любое другое веб-приложение и его необходимо опубликовать в интернет, можно добавить дополнительное доменное имя, сертификат для него и дополнить настройку nginx. Таким образом на одном внешнем IP адресе, на одном стандартном порту, могут начать работать два и более сайта с разными доменными именами.

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

Развертывание прокси

Для развертывания сервисов, таких как обратный прокси, очень хорошо зарекомендовал себя docker. Для запуска этого сервиса использован стек docker-compose, состоящий из 2 контейнеров — самого веб-сервера nginx и certbot для получения и обновления SSL-сертификатов:

version: "2"
services:
  nginx:
    container_name: frontend_proxy_nginx
    image: nginx:latest
    restart: always
    ports:
      - "4080:80"
      - "4443:443"
      - "443:443"
    volumes:
       - ./nginx/nginx.conf:/etc/nginx/conf.d/default.conf
       - ./data:/data
       - ./certbot/conf:/etc/letsencrypt
       - ./certbot/www:/var/www/certbot
    command: "/bin/sh -c 'while :; do sleep 6h & wait $${!}; nginx -s reload; done & nginx -g \"daemon off;\"'"
  certbot:
    restart: always
    image: certbot/certbot
    volumes:
       - ./certbot/conf:/etc/letsencrypt
       - ./certbot/www:/var/www/certbot
    entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'"

Здесь все обычно — порты, тома, настройки. Единственное, что отличается — команда запуска. Об этом поясняется далее. Обязательно нужно предусмотреть доступ на этот сервер из интернета по 80 порту, это необходимо при получении SSL сертификата.

Получение SSL сертификата

Для того, чтобы запустить все в работу нужен SSL сертификат, но чтобы получить сертификат, необходимо запуститься. Эту проблему решает запуск скрипта init-letsencrypt.sh перед первым запуском всего приложения. Предварительно в скрипт необходимо внести изменения — перечислить домены, на которые получается сертификат. После запуска будет произведен выпуск сертификатов и запуск приложения. Если все проделано правильно, то после выполнения можно будет заходить на сайты, описанные в конфиге nginx/nginx.conf.

Пример описания одного виртуального сервера из него:

server {
  server_name git.corp.ru;
  listen 80;
  location / {
    return 301 https://$host$request_uri;
  } 
  location /.well-known/acme-challenge/ {
    root /var/www/certbot;
  }
}
server {
  listen 443 ssl;
  server_name git.corp.ru;
  include /etc/letsencrypt/options-ssl-nginx.conf;
  ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
  ssl_certificate /etc/letsencrypt/live/ftp.corp.ru/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/ftp.corp.ru/privkey.pem;
  location / {
    proxy_pass http://172.21.99.55:9090;
  }
}

Здесь происходит проксирование https соединения к гиту — терминирование SSL и передача запроса дальше, на бекэнд с нестандартным портом.

Применение к публикациям 1С

Для того, чтобы теперь сделать публикацию базы 1С доступной через SSL соединение, нужно только настроить обратный прокси.

Для примера допустим, есть две публикации на двух серверах — http://10.0.0.4/test и http://10.0.0.5/prod и нужно, чтобы они обе были доступны по ссылкам https://1c.domain.com/test и https://1c.domain.com/prod

Для этого необходимо на nginx всего лишь выполнить следующие настройки, а затем применить их, попросив веб-сервер перечитать свой файл конфигурации.

Допустим, что изменения в файл init-letsencrypt.sh уже внесены и сертификат обновлен, теперь необходимо настроить и перезапустить nginx. В файл nginx/nginx.conf необходимо добавить секцию сервера:

server {
  server_name 1c.domain.com;
  listen 80;
  location / {
    return 301 https://$host$request_uri;
  } 
  location /.well-known/acme-challenge/ {
    root /var/www/certbot;
  }
}
server {
  listen 443 ssl;
  server_name 1c.domain.com;
  include /etc/letsencrypt/options-ssl-nginx.conf;
  ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
  ssl_certificate /etc/letsencrypt/live/ftp.corp.ru/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/ftp.corp.ru/privkey.pem;
  location /test {
    proxy_pass http://10.0.0.4;
  }
  location /prod {
    proxy_pass http://10.0.0.5;
  }

}

После внесения изменений необходимо выполнить команду:

docker-compose exec nginx nginx -s reload

Изменения вступят в силу. В конфиг добавлена переадресация с обычного http на https, а также распределение по бекэнд серверам с 1С с помощью разных локаций. Все достаточно просто и теперь по одному SSL сертификату можно заходить в базы, опубликованные на разных серверах. SSL терминируется централизованно, после чего подключения распределяются по серверам.

Previous Story

SQL

Next Story

базы 1С на веб-сервере Windows и Linux

Latest from Blog

Port Knocking в Linux

Безопасность — это всегда компромисс между многими показателями, включающими, в том числе, удобство пользования. Современные реалии

BGP Mikrotik

Настройка интерфейса BGP Разберемся как настроить BGP на маршрутизаторах Микротик, допустим нам нужно анонсировать сеть 212.45.0.0/24, наша

VLAN switching на устройствах Mikrotik

Многие устройства Mikrotik имеют чипы коммутации, которые позволяют выполнять VLAN коммутацию на аппаратном уровне. Поэтому, для

HotSpot на Mikrotik c маркетингом

Если смотреть на реалии сегодняшнего дня, то почти у каждого посетителя имеется мобильный гаджет, который подключаются

0 £0.00