Поиск по сайту:

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

На этой странице

  1. Начало работы
  2. Подготовка хост-сервера
    1. Установка имени хоста обратного прокси-сервера.
    2. Установка NGINX

    1. Создайте структуру каталогов обратного прокси-сервера.
    2. Настройка обратных прокси-серверов веб-сервера (http)
    3. Настройка обратных прокси-серверов SSH, MySQL/MariaDB (поток)
    4. Использование конфигураций для каждой службы
    5. Использование файлов конфигурации для каждого хоста

    1. Активируйте настройки обратного прокси-сервера.
    2. Открытие сервера для трафика

    1. NGINX и Apache2 на одном хосте
    2. Изменение порта прослушивания Apache2

    Это руководство поможет вам установить и настроить 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 и нажмите клавишу ввода. Это сохранит и закроет файл, если в файл не было внесено никаких изменений, CTRL + x закроет файл без запроса на сохранение. Вы вернетесь в командную строку.

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

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

    systemctl restart ssh

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

    ssh  -p23456

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

    С этого момента вы будете запускать команды корневого уровня с вашего терминала. Следующая команда избавит от необходимости добавлять к последующим командам 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

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

    If your system is currently local only you will need to show this server where your other servers/virtual hosts are.
    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

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

    Установка НГИНКС

    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 создаст/обновит файлы при сохранении.

    Before you proceed, open an empty document on your computer or get a pen and paper to note down the ports you configure.

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

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

    nano http/available/example.com.conf

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

    # Note down ports 80 and 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
    # Note down the listen ports

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;
}

# Add as many upstream and server block pairs as you will need for your remote accessed SSH servers.

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

    nano stream/available/db.conf
    # Note down the listen ports

upsteam db1-mysql {
  server 192.168.1.3:3306;
}

server {
  listen 33063;
  proxy_pass db1-mysql;
}

# Add as many upstream/server block pairs as you will need for your remote accessed MySQL/MariaDB servers to this file.

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

    nano stream/available/ftp.conf
    upstream web1-ftp {
  server 192.168.1.3:21
}

server {
  listen 21002;
  proxy_pass web1-ftp;
}

# Add as many upstream/server block pairs as you will need for your remote accessed FTP servers.

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

    nano /etc/nginx/rproxy/stream/available/web1.example.com.conf
    # Note down the listen ports

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
    # Note down the listen ports

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, вам необходимо внести некоторые изменения в основной файл конфигурации. Закомментируйте текущую строку включения в блоке 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 {

        ##
        # Basic Settings
        ##

        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 Settings
        ##

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;

        ##
        # Logging Settings
        ##

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

        ##
        # Gzip Settings
        ##

        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$

        ##
        # Virtual Host Configs
        ##

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

        # Reverse proxy http configuration files.
        include /etc/nginx/rproxy/http/enabled/*.conf;
}

stream {

    # Reverse proxy stream configuration files.
    include /etc/nginx/rproxy/streams/enabled/*.conf;
}


#mail {
#       # See sample authentication script at:
#       # 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. В моем конкретном маршрутизаторе я могу настроить пользовательские «приложения».

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

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

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

    Установите 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 на вышестоящем хосте, вам необходимо убедиться, что выбранные здесь параметры соответствуют параметрам на хост-сервере, в частности, если вы перенаправляете на https на вышестоящем сервере, вы должны сделать так, чтобы и здесь .

    Для ясности, 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
    <ifmodule rpaf_module="">
    RPAFenable On

    # When enabled, take the incoming X-Host header and
    # update the virtualhost settings accordingly:
    RPAFsethostname On

    # Define which IP's are your frontend proxies that sends
    # the correct X-Forwarded-For headers:
    RPAFproxy_ips 127.0.0.1 ::1

    # Change the header name to parse from the default
    # X-Forwarded-For to something of your choice:
#   RPAFheader X-Real-IP
</ifmodule>

    Заключительные примечания

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

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

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

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

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

    Note: Apache2 ports do not need to be altered when it is the only web server installed on server or virtual machine.