Руководство по запуску обратного прокси для HTTP(S), SSH и MySQL/MariaDB с использованием NGINX

Это руководство проведет вас через установку и настройку NGINX, чтобы позволить запускать несколько физических серверов, виртуальных машин или их комбинацию за одним общим публичным IP-адресом. Вы можете выбрать запуск нескольких веб-серверов на виртуальных машинах и управлять ими локально, или вам может потребоваться использовать инструменты удаленного доступа, такие как SSH, к каждому из хостов. Например, если локальный доступ будет недоступен вне обычных рабочих часов. Это руководство может облегчить обе ситуации.

Конфигурации, показанные здесь, лучше всего подходят для домашней лаборатории или небольшой бизнес-сети, у которой есть ограничения на доступные публичные IP-адреса. Не будет особого смысла запускать такую конфигурацию, когда у вас есть несколько серверов или виртуальных машин, арендованных у хостинг-сервиса, вам все равно будет назначен публичный IP-адрес для каждого сервера или хоста.

Я покажу вам, как установить NGINX и сделать конфигурации, которые позволят серверу действовать как обратный прокси для HTTP(S), SSH, FTP и MySQL/MariaDB. Я предполагаю, что для хост-сервера NGINX у вас есть: локальный доступ, свежая установка Ubuntu 18.04 и что вы выбрали установку SSH-сервера во время шагов установки сервера Ubuntu.

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

Начало работы

В этом руководстве я буду использовать следующие имена хостов и IP-адреса.

rproxy.example.com  192.168.1.1
web1.example.com    192.168.1.2
db1.exmple.com      192.168.1.3

У вас должна быть учетная запись пользователя, не являющегося root, на сервере для стандартной установки сервера Ubuntu 18.04, которую вы создали во время установки. Начните с того, чтобы войти на сервер, на котором вы будете устанавливать NGINX, с этим пользователем. Поскольку это, скорее всего, локальный сервер, вам может потребоваться войти на сервер напрямую в первый раз, чтобы настроить SSH-сервер. Вам, конечно, понадобится клавиатура и монитор, подключенные к серверу, чтобы сделать это.

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

Подготовка хост-сервера

В вашей консольной оболочке (браузерной или напрямую подключенной)

sudo nano /etc/ssh/sshd_config

Уберите комментарий с строк: Port, измените номер порта на что-то вроде 23456, ListenAddress и измените его на 0.0.0.0. Для тех, кто может быть незнаком с nano, нажмите CTRL + X, введите y, а затем нажмите enter. Это сохранит и закроет файл, если изменения не были внесены в файл, CTRL + x закроет файл без запроса на сохранение. Вы вернетесь к командной строке.

Я не буду углубляться в остальные настройки в этом файле, потому что это уже довольно длинное руководство, и есть много руководств, которые покажут вам, какие настройки вы должны изменить для множества вещей, таких как использование SSH-ключей и разрешение входа root по SSH. Вы также можете найти эти руководства прямо здесь на сайте HowtoForge.

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

systemctl restart ssh

Убедитесь, что вы можете войти с помощью SSH из терминала на другом компьютере в вашей локальной сети.

ssh [email protected] -p23456

Держите этот терминал открытым после успешного входа с помощью SSH и выйдите из консоли/сервера. Вам больше не нужно использовать его для оставшейся части этого руководства.

С этого момента вы будете выполнять команды с правами root из вашего терминала. Следующая команда устранит необходимость предварять последующие команды sudo.

sudo -s

Обновите базу данных пакетов Apt и обновите Ubuntu, чтобы убедиться, что у вас установлены самые последние пакеты.

apt update && apt -y upgrade

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

Установка имени хоста сервера обратного прокси.

hostnamectl set-hostname rproxy.example.com

Если вы запускаете виртуальный сервер, у вас может быть файл с именем cloud.cfg, который нужно изменить, чтобы сохранить имя хоста, установленное здесь. Следующая команда либо покажет файл с содержимым, либо пустую страницу. Если вы видите пустую страницу, вы можете просто CTRL + x и пропустить этот шаг, так как вам нечего делать.

nano /etc/cloud/cloud.cfg

Измените строку preserve hostname на true и закройте/сохраните файл.

Если ваша система в настоящее время только локальная, вам нужно будет показать этому серверу, где находятся ваши другие серверы/виртуальные хосты.

nano /etc/hosts

Файл hosts будет выглядеть примерно так после внесения изменений, IP-адреса и хосты должны соответствовать вашей собственной инфраструктуре.

127.0.0.1 localhost
127.0.1.1  rproxy.example.com
192.168.1.2    web1.example.com
192.168.1.3    db1.example.com

# Следующие строки желательны для хостов, поддерживающих IPv6
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Установка NGINX

apt install -y nginx

После установки вам следует проверить вашу версию NGINX, крайне важно, чтобы у вас была версия 1.9 или выше, чтобы позволить вам использовать обратный прокси для SSH и MySQL/MariaDB.

nginx -v

Как вы можете видеть, у меня установлена версия NGINX 1.14, которая является стандартной в Ubuntu 18.04 (10 октября 2019)

nginx version: nginx/1.14.0 (Ubuntu)

Подготовка NGINX к работе в качестве обратного прокси

С этой конфигурацией вы не будете обслуживать какие-либо веб-сайты напрямую с сервера обратного прокси. Вы создадите новую структуру каталогов под /etc/nginx/. Это сохранит стандартные конфигурации NGINX, если вы захотите вернуть эти изменения позже или решите, что на самом деле хотите также обслуживать веб-сайты напрямую с этого хоста. Возможно запустить стандартную конфигурацию вместе с этими конфигурациями обратного прокси, однако, если Apache2 будет на том же сервере, ему понадобятся альтернативные порты для прослушивания, и вам все равно нужно будет использовать обратный прокси для веб-сайтов, которые обслуживает этот экземпляр Apache2.

Создание структуры каталогов обратного прокси

cd /etc/nginx && mkdir rproxy && cd rproxy && mkdir http http/available http/enabled stream stream/available stream/enabled

Теперь, когда у вас есть структура на месте, вы можете продолжить создание конфигурационных файлов. Я использую nano, но вы можете использовать редактор, с которым вам удобно. Nano создаст/обновит файлы при сохранении.

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

Настройка обратных прокси веб-сервера (http)

Создайте файл(ы) конфигурации http для веб-сайта(ов), корректируя соответственно

nano http/available/example.com.conf

Скопируйте блок сервера в страницу, открывшуюся в терминале с nano, корректируя соответственно.

# Запишите порты 80 и 443

server {
    server_name example.com www.example.com;
    listen 80;
    set $upstream 192.168.1.2;
    location / {
         proxy_pass_header Authorization;
         proxy_pass http://$upstream;
         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_http_version 1.1;
         proxy_set_header Connection "";
         proxy_buffering off;
         client_max_body_size 0;
         proxy_read_timeout 10000s;
         proxy_redirect off;
     }
}

Настройка обратных прокси SSH, MySQL/MariaDB (потоки)

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

Использование конфигураций по службе

Добавьте конфигурации SSH.

nano stream/available/ssh.conf

# Запишите порты прослушивания

upstream web1-ssh {
  server 192.168.1.2:22;
}

server {
  listen 22002;
  proxy_pass web1-ssh;
}

upstream db1-ssh {
  server 192.168.1.3:22;
}

server {
  listen 22003;
  proxy_pass db1-ssh;
}

# Добавьте столько upstream и пар блоков сервера, сколько вам нужно для ваших удаленно доступных SSH-серверов.

Добавьте конфигурации MySQL/MariaDB.

nano stream/available/db.conf

# Запишите порты прослушивания

upsteam db1-mysql {
  server 192.168.1.3:3306;
}

server {
  listen 33063;
  proxy_pass db1-mysql;
}

# Добавьте столько upstream/пара блоков сервера, сколько вам нужно для ваших удаленно доступных MySQL/MariaDB серверов в этот файл.

Теперь создайте конфигурации обратного прокси FTP.

nano stream/available/ftp.conf

upstream web1-ftp {
  server 192.168.1.3:21
}

server {
  listen 21002;
  proxy_pass web1-ftp;
}

# Добавьте столько upstream/пара блоков сервера, сколько вам нужно для ваших удаленно доступных FTP-серверов.

Использование файлов конфигурации по хосту

nano /etc/nginx/rproxy/stream/available/web1.example.com.conf

# Запишите порты прослушивания

upstream web1-ssh {
  server 192.168.1.3:22;
}

server {
  listen 22002;
  proxy_pass web-ssh;
}

Создание файла хоста для db1.example.com

nano /etc/nginx/rproxy/stream/available/db1.example.com.conf

# Запишите порты прослушивания

upsteam db1-mysql {
  server 192.168.1.3:3306;
}

server {
  listen 33063;
  proxy_pass db1-mysql;
}

upstream db1-ssh {
  server 192.168.1.3:22;
}

server {
  listen 22003;
  proxy_pass db1-ssh;
}

Как вы видите, это немного неортодоксально. Вы используете публичные порты нестандартным образом, выбирая порты, которые вам нужны, а затем указывая их на NGINX. Это было бы нормально, если бы вы теперь использовали другой порт для каждой службы на каждом сервере, к которому вы хотите получить удаленный доступ. Это означает, что, используя SSH в качестве примера, другой номер порта для каждого хоста с включенным SSH 22 222 2222 22222, например, указывал бы на порт 22 на четырех разных серверах или виртуальных машинах.

Это не так для NGINX, чтобы использовать обратный прокси для веб-сайтов, пока у NGINX есть определенная конфигурация сервера для веб-сайта, он будет работать правильно только с портами 80 и 443, перенаправленными на него.

На этом этапе вы, вероятно, поняли, что вы могли бы просто использовать шаги HTTP и пропустить шаги потока, и вместо этого перенаправить несколько портов для нескольких служб на соответствующий сервер/IP-адрес. Действительно, это можно сделать. Однако это добавит еще один уровень сложности и станет трудным для поддержки по мере увеличения числа серверов, потому что вам может потребоваться изменить стандартные порты на каждом сервере для ssh, mysql и ftp. Эта конфигурация уже сложна, тем не менее, это можно сделать, если вы хотите.

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

В качестве дополнительного бонуса к этой конфигурации другие серверы в вашей инфраструктуре должны слушать только на локальных интерфейсах и стандартных портах, если это то, что вы предпочитаете. Если вы управляете локально, вы можете использовать локальные IP-адреса и стандартные порты служб для доступа к необходимым службам, так что вам не нужно будет ссылаться на ваши заметки, чтобы запомнить правильные порты, вам нужно только знать IP-адрес и учетные данные для входа.

Объединение всего

Чтобы начать использовать конфигурации обратного прокси NGINX, вам нужно будет внести некоторые изменения в основной файл конфигурации. Закомментируйте текущую строку include в блоке http (если вы не обслуживаете веб-сайты напрямую из NGINX также).

cd /etc/nginx && nano nginx.conf

Обратите внимание на выделенные части ниже, чтобы определить, что нужно изменить.

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
        worker_connections 768;
        # multi_accept on;
}

http {

        ##
        # Основные настройки
        ##

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65;
        types_hash_max_size 2048;
        # server_tokens off;

        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # SSL настройки
        ##

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Отказ от SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;

        ##
        # Настройки логирования
        ##

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        ##
        # Настройки Gzip
        ##

        gzip on;

        gzip on;

        # gzip_vary on;
        # gzip_proxied any;
        # gzip_comp_level 6;
        # gzip_buffers 16 8k;
        # gzip_http_version 1.1;
        # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascri$

        ##
        # Конфигурации виртуального хоста
        ##

        include /etc/nginx/conf.d/*.conf;
#       include /etc/nginx/sites-enabled/*;

        # Конфигурационные файлы обратного прокси http.
        include /etc/nginx/rproxy/http/enabled/*.conf;
}

stream {

    # Конфигурационные файлы обратного прокси потока.
    include /etc/nginx/rproxy/streams/enabled/*.conf;
}


#mail {
#       # См. образец скрипта аутентификации на:
#       # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
# 
#       # auth_http localhost/auth.php;
#       # pop3_capabilities "TOP" "USER";
#       # imap_capabilities "IMAP4rev1" "UIDPLUS";
# 
#       server {
#               listen     localhost:110;
#               protocol   pop3;
#               proxy      on;
#       }
# 
#       server {
#               listen     localhost:143;
#               protocol   imap;
#               proxy      on;
#       }
#}

Активировать конфигурации обратного прокси.

Сначала включите все конфигурации http

ln -s /etc/nginx/rproxy/http/available/*.conf /etc/nginx/rproxy/http/enabled

Включите все конфигурации потока

ln -s /etc/nginx/rproxy/stream/available/*.conf /etc/nginx/rproxy/stream/enabled

Выполните тест, чтобы проверить, что конфигурация NGINX как обратного прокси правильная.

nginx -T

В выводе вы должны увидеть сообщение об успешном завершении вместе со всеми пользовательскими конфигурациями, которые вы сделали ранее.

Перезапустите NGINX, чтобы активировать конфигурации обратного прокси.

systemctl restart nginx

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

netstat -tulpn | grep nginx

Вывод должен выглядеть примерно так

tcp        0      0 0.0.0.0:22           0.0.0.0:*               LISTEN      4964/nginx: master  
tcp        0      0 0.0.0.0:22002           0.0.0.0:*               LISTEN      4964/nginx: master  
tcp        0      0 0.0.0.0:22003           0.0.0.0:*               LISTEN      4964/nginx: master
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      4964/nginx: master  
tcp        0      0 0.0.0.0:33062           0.0.0.0:*               LISTEN      4964/nginx: master  
tcp        0      0 0.0.0.0:33063           0.0.0.0:*               LISTEN      4964/nginx: master  
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      4964/nginx: master

Открытие сервера для трафика

Теперь, когда NGINX слушает и готов действовать как обратный прокси для всех соединений, которые мы хотим разрешить, временно отключите UFW, пока вы проходите через следующие шаги. Это упростит устранение неполадок, если что-то не работает должным образом.

ufw disable

Перенаправление портов

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

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

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

Бесплатный SSL Letsencrypt для сервера обратного прокси

Установите Certbot и плагин Certbot NGINX. Этот шаг выполняется здесь, потому что вы не можете создать сертификат, пока у вас нет функционального DNS для всех (под.)имен доменов, перечисленных в сертификате, и вы можете установить соединение с доменом через HTTP. Завершив это после того, как вы перенаправили порты на обратный прокси, это также служит дополнительным тестом для ваших конфигураций. Если сертификат не удается, потому что домен недоступен, вы увидите значительное сообщение об ошибке в выводе.

Чтобы убедиться, что вы получаете последнюю версию certbot, добавьте репозиторий certbot перед установкой. Репозитории Ubuntu часто отстают на версию или более от версии программного обеспечения, и вы действительно хотите последние стабильные версии всего вашего программного обеспечения, если можете их получить.

add-apt-repository ppa:certbot/certbot  
apt install -y certbot python-certbot-plugin

С установленными certbot и плагином certbot nginx вы теперь можете создать сертификаты для NGINX.

Эта команда должна повторяться для всех доменов и поддоменов, для которых вы хотите предоставить SSL. Если это первый раз, когда вы запускаете certbot, вам нужно будет принять условия.

certbot --nginx -d example.com -d www.example.com

Обратите внимание, что если у вас есть работающая серверная установка с SSL на upstream-хосте, вам нужно будет убедиться, что выбранные здесь параметры совпадают с теми, что на хост-сервере, в частности, если вы перенаправляете на https на upstream-сервере, вы должны сделать это и здесь.

Для ясности, example.com существует на другом сервере, и я выбрал перенаправление http на https в ISPConfig, поэтому по этой причине я выбираю сделать это и здесь. Файл конфигурации будет обновлен, и я теперь вижу, что Certbot добавил некоторые свои конфигурации.

Проверка работоспособности.

Теперь, когда у вас есть возможность передавать трафик на ваш обратный прокси, вам следует проверить, что все работает так, как задумано. Проверьте, что веб-сайты функционируют правильно, выполните соединения и задачи SSH, FTP и MySQL/MariaDB. Как только вы убедитесь, что все работает так, как должно, вы включите UFW и добавите правила, чтобы разрешить каждый из портов.

Защита сервера обратного прокси

ufw enable

Вам нужно будет разрешить 80 и 443 откуда угодно. и, вероятно, ограничить SSH, FTP и MySQL/MariaDB до IP-адреса или имени хоста. Вы можете комментировать правила, чтобы быстро идентифицировать, какой службе/серверу вы назначили порт.

ufw allow 80  
ufw allow 443  
 ufw allow from 1.2.3.4 to any port 22002 comment 'web1 SSH'  
 ufw allow from somehost.domain.com to any port 33061 comment 'db1 MySQL/MariaDB'  
  
 ufw reload  
 ufw status numbered

Обновление Apache2

При работе за обратным прокси журналы Apache2 будут записывать IP-адрес сервера обратного прокси вместо IP-адреса посетителя веб-сайта. Чтобы восстановить нормальную регистрацию IP-адресов в Apache2, доступен модуль для исправления этого поведения.

Выполните следующие шаги на каждом веб-сервере с установленным Apache2.

sudo apt install -y libapache2-mod-rpaf

Чтобы убедиться, что Apache2 теперь будет записывать правильные IP-адреса, внесите небольшое изменение в файл rpaf.conf. Ubuntu 18.04 уже создала файл для нас, нам просто нужно отредактировать его, изменив выделенный IP-адрес на адрес хоста обратного прокси NGINX.

nano /etc/apache2/mods-available/rpaf.conf


    RPAFenable On

    # Когда включено, возьмите входящий заголовок X-Host и
    # обновите настройки виртуального хоста соответственно:
    RPAFsethostname On

    # Определите, какие IP-адреса являются вашими фронтенд-прокси, которые отправляют
    # правильные заголовки X-Forwarded-For:
    RPAFproxy_ips 127.0.0.1 ::1

    # Измените имя заголовка для разбора с
    # X-Forwarded-For на что-то на ваш выбор:
#   RPAFheader X-Real-IP

Заключительные заметки

NGINX и Apache2 на одном хосте

Ни одна из двух служб не может слушать на одном и том же порту в пределах сервера или виртуальной машины. Если NGINX установлен на том же сервере или виртуальной машине, что и веб-сервер Apache2, вам нужно будет изменить порт, на котором слушает Apache2. NGINX требует порты 80 и 443 для выполнения своих функций HTTP(S), так как это стандартные порты для HTTP и HTTPS.

Обратитесь к разделу http этого руководства и добавьте конфигурации обратного прокси для веб-сайтов, обслуживаемых этим экземпляром Apache2, так же, как и для других серверов в сети.

Изменение порта прослушивания Apache2

Если у вас установлена система управления сервером, такая как ISPConfig, эта система обрабатывает файлы vhost Apache2, поэтому вам следует изучить, как изменить порты, на которых слушит Apache2. Поискать на форумах ISPConfig, а затем внести необходимые изменения. В противном случае вам следует обратиться к форумам Ubuntu или веб-сайту Apache2, чтобы узнать, как выполнить эти изменения.

Примечание: Порты Apache2 не нужно изменять, когда это единственный веб-сервер, установленный на сервере или виртуальной машине.