NGINX выступает в роли обратного прокси-сервера, который позволяет получить доступ к нескольким внутренним ресурсам через один внешний адрес. В простом примере, у нас есть два сервера 1С с веб-публикациями на IIS и Apache, использующие одни и те же порты. Для обеспечения одновременного доступа к обоим серверам, пришлось бы разместить их на нестандартных портах, что делает эксплуатацию неудобной.
Кроме того, для каждого сервера было бы необходимо обеспечивать SSL-шифрование, что требует работы с сертификатами и их преобразованием в различные форматы. Парольная аутентификация также потребовала бы две базы пользователей, а если бы у нас были и другие внутренние веб-ресурсы, которые нужно сделать доступными снаружи, то сложности только возрастали.
Однако, при использовании обратного прокси-сервера все эти проблемы могут быть решены. Обратный прокси-сервер позволяет внешним клиентам получить доступ к множеству внутренних ресурсов через один внешний адрес. Такой подход упрощает настройку и управление инфраструктурой, а также обеспечивает безопасность через SSL-шифрование и парольную аутентификацию.
Таким образом, NGINX в качестве обратного прокси-сервера является эффективным и удобным решением для обеспечения доступа к множеству внутренних ресурсов через один внешний адрес.
У нас в сети есть два веб-сервера, на которых доступны информационные базы 1С:Предприятия. Первый сервер, IIS-SRV-1C.LOC, использует IIS и содержит базы данных Зарплата и Управление персоналом. Второй сервер, APH-SRV-1C.LOC, использует Apache и содержит базу данных Бухгалтерия предприятия.
У нас также есть внешний адрес, который соответствует доменному имени 1с.it-31.lab. Наличие доменного имени обязательно для использования сертификатов Let's Encrypt. Мы категорически не рекомендуем использовать самоподписанные сертификаты для доступа внешних пользователей, так как это приводит к игнорированию ошибок сертификатов и ухудшает безопасность.
Кроме того, NGINX будет выполнять парольную аутентификацию. Это позволит нам иметь единую базу пользователей и паролей.
Данная инструкция предназначена для актуальных версий Debian или Ubuntu. Все команды следует выполнять от имени суперпользователя root.
Установка и первичная настройка NGINX
Существуют два способа установки NGINX: из репозиториев операционной системы или из репозитория разработчиков. Если установить NGINX из репозиториев операционной системы, то версия продукта может быть устаревшей, что нежелательно для сервиса, работающего с внешним миром. Это связано не только с уязвимостями, так как обновления безопасности будут выпускаться до окончания срока поддержки операционной системы, но и с отсутствием поддержки новых технологий, таких как новые шифры или алгоритмы.
Поэтому рекомендуется устанавливать NGINX из репозитория разработчиков. На данный момент поддерживаются версии Debian 11 и 12, а также Ubuntu 20.04 и 22.04.
Для начала необходимо установить необходимые зависимости с помощью команды:
apt install curl gnupg2 Затем нужно получить и установить ключ репозитория в хранилище с помощью следующих команд:
curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor > /usr/share/keyrings/nginx-archive-keyring.gpg Следующим шагом необходимо подключить дополнительный репозиторий.
Для Debian:
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/debian lsb_release -cs nginx" > /etc/apt/sources.list.d/nginx.list Для Ubuntu:
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/ubuntu lsb_release -cs nginx" > /etc/apt/sources.list.d/nginx.list После этого нужно обновить список пакетов и установить NGINX с помощью следующих команд:
apt update apt install nginx Затем можно запустить службу и проверить ее статус с помощью следующих команд:
systemctl start nginx systemctl status nginx Теперь можно открыть веб-браузер и ввести адрес сервера, чтобы увидеть стандартную заглушку NGINX.
Чтобы создать дополнительные директории для размещения конфигурационных файлов, нужно выполнить следующие команды:
mkdir /etc/nginx/sites-available mkdir /etc/nginx/sites-enabled Затем нужно открыть файл /etc/nginx/nginx.conf и после строки:
include /etc/nginx/conf.d/*.conf; добавить следующую строку:
include /etc/nginx/sites-enabled/*; Проверить правильность конфигурации и перезапустить веб-сервер можно с помощью следующих команд:
nginx -t nginx -s reload Таким образом, первоначальная установка и настройка NGINX завершена.
Получение сертификата Let's Encrypt и настройка SSL-шифрования
В текущих условиях защита данных становится все более актуальным вопросом, и без шифрования уже не обходится ни один серьезный проект. Поэтому сначала мы займемся настройкой этой защиты.
Чтобы начать, установим Certbot для работы с сертификатами Let's Encrypt:
apt install certbot
Теперь создадим файл конфигурации для нашего виртуального хоста и отредактируем его с помощью редактора nano (если вы предпочитаете MC, замените nano на mcedit в команде):
nano /etc/nginx/sites-available/00-1c.it-31.lab.conf
Вы можете выбрать произвольное имя файла, но рекомендуется именовать его по имени обслуживаемого домена.
Добавьте следующий текст в файл:
server { listen 80; server_name 1c.it-31.lab;
location ^~ /.well-known/acme-challenge/ { default_type "text/plain"; root /var/www/letsencrypt; }
location = /.well-known/acme-challenge/ { return 404; }
return 301 https://$host$request_uri; }
В этой конфигурации мы указываем, что на порту 80 следует принимать запросы для узла 1c.it-31.lab, далее идут параметры для работы с Let's Encrypt, а все остальные запросы будут перенаправляться на защищенную версию ресурса.
Сохраните конфигурацию и создайте символическую ссылку на нее в директории /etc/nginx/sites-enabled:
ln -s /etc/nginx/sites-available/00-1c.it-31.lab.conf /etc/nginx/sites-enabled
Проверьте конфигурацию и перезапустите веб-сервер:
nginx -t nginx -s reload
Создадим указанную в конфигурации директорию и назначим владельцем веб-сервер:
mkdir /var/www/letsencrypt chown -R nginx:nginx /var/www/letsencrypt
Теперь запустим Certbot и получим сертификат для нашего домена:
certbot certonly --webroot -w /var/www/letsencrypt -d 1c.it-31.lab
После успешного получения сертификата откройте файл настроек домена /etc/letsencrypt/renewal/1c.it-31.lab.conf и добавьте следующую опцию в секцию [renewalparams]:
[renewalparams] ... renew_hook = nginx -s reload
Таким образом, при успешном обновлении сертификата NGINX будет перезапускаться.
Для режима совершенной прямой секретности создадим файл параметров Диффи-Хеллмана:
openssl dhparam -out /etc/ssl/private/dhparam.pem 2048
Откройте файл /etc/nginx/sites-available/00-1c.it-31.lab.conf и добавьте в него следующую секцию:
server { listen 443 ssl http2; server_name 1c.it-31.lab;
ssl_certificate /etc/letsencrypt/live/1c.it-31.lab/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/1c.it-31.lab/privkey.pem; ssl_session_timeout 1d; ssl_session_cache shared:SSL:50m; ssl_session_tickets off; ssl_dhparam /etc/ssl/private/dhparam.pem;
ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
Настройка переадресации запросов для веб-публикации 1С:Предприятие
Прежде чем настраивать, необходимо узнать адреса существующих публикаций. В нашем случае это следующие адреса:
http://IIS-SRV-1C.LOC/HRM-1 http://APH-SRV-1C.LOC/ACC-30
Также важно определить, в каком регистре указано имя публикации. Для этого можно обратить внимание на адресную строку уже запущенной базы данных в браузере. Если происходит перенаправление в верхний регистр, значит база опубликована именно в таком виде. В настройках необходимо указывать имя публикации именно так, в верхнем регистре.
Для работы обратного прокси необходимо создать отдельные URL для каждой базы данных, используя их имена. Для этого открываем файл конфигурации /etc/nginx/sites-available/00-1c.it-31.lab.conf и добавляем следующую вложенную секцию внутрь секции server:
location /HRM-1/ { proxy_pass http://IIS-SRV-1C.LOC/HRM-1/; proxy_redirect off; 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 https; }
Первая строка определяет адрес, на который мы перенаправляем все запросы, пришедшие на URL 1c.it-31.ru/HRM-1. Важно обратить внимание на необходимость закрывающих слешей. Остальные опции определяют режим работы и передачу служебных заголовков проксируемому серверу.
Для второй базы данных добавляем аналогичную секцию:
location /ACC-30/ { proxy_pass http://APH-SRV-1C.LOC/ACC-30/; proxy_redirect off; 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 https; }
Повторяем эти действия для всех остальных баз данных. Теперь они будут доступны внешним пользователям по следующим адресам:
https://1c.it-31.ru/HRM-1 https://1c.it-31.ru/ACC-30
Для применения изменений сохраняем файл конфигурации, проверяем его корректность с помощью команды "nginx -t" и перезапускаем NGINX командой "nginx -s reload".
Таким образом, мы успешно опубликовали информационные базы 1С:Предприятие для внешних пользователей с разных серверов и обеспечили их защиту надежным шифрованием.
Настройка дополнительной аутентификации по паролю
Мы уверены в надежности встроенного механизма аутентификации 1С:Предприятия. Однако, мы обнаружили слабое место - это пользователи. Некоторые из них могут использовать простые пароли или вообще не использовать их, а также могут быть уязвимы перед скриптами и средствами автоматизации. Поэтому, чтобы обеспечить безопасность, мы решили установить дополнительную аутентификацию на уровне веб-сервера.
Для этого мы устанавливаем дополнительные утилиты с помощью команды "apt install apache2-utils". Затем создаем базу пользователей, добавляя первого пользователя с помощью ключа "-с", который создаст новый файл паролей или перезапишет существующий: "htpasswd -c /etc/nginx/.htpasswd glavbuch".
Для добавления следующих пользователей используем команду "htpasswd /etc/nginx/.htpasswd buch1". Затем в каждую секцию с информационной базой в конфигурационном файле /etc/nginx/sites-available/00-1c.it-31.lab.conf добавляем строки:
location /HRM-1/ { auth_basic "1C users only"; auth_basic_user_file /etc/nginx/.htpasswd; }
Далее проверяем конфигурацию и перезапускаем сервер с помощью команд "nginx -t" и "nginx -s reload". Теперь доступ к опубликованным информационным базам будет недоступен без ввода дополнительных учетных данных.