nginx обратный прокси к Synology DSM, без базового URL

Вопрос или проблема

Я использую Synology NAS с DSM 5.x. Наконец, у меня заработал реверсивный прокси nginx с другого сервера с конфигурацией ниже.

Я хотел бы избежать перечисления всех локаций по возможности. Веб-интерфейс DSM использует каждый из перечисленных ниже URL-фрагментов как часть своего интерфейса. Нет базового URL и опции для его добавления.

Мой вопрос: возможно ли в nginx с proxy_pass или proxy_redirect или rewrite (или других вариантах) не указывать все отдельные локации по отдельности? (Я пробовал десятки комбинаций в течение нескольких дней, но ничего, кроме указанного ниже, не сработало.)

nginx.conf

http {
    upstream dsm {
        server 1.1.1.1:5000;
    }
    server {
        location /dsm/ {
            include proxy_headers;
            proxy_pass http://dsm/;
        }
        location /scripts/ {
            include proxy_headers;
            proxy_pass http://dsm;
        }
        location /synoSDSjslib/ {
            include proxy_headers;
            proxy_pass http://dsm;
        }
        location /webapi/ {
            include proxy_headers;
            proxy_pass http://dsm;
        }
        location /webdefault/ {
            include proxy_headers;
            proxy_pass http://dsm;
        }
        location /webfm/ {
            include proxy_headers;
            proxy_pass http://dsm;
        }
        location /webman/ {
            include proxy_headers;
            proxy_pass http://dsm;
        }
    }
}

proxy_headers

proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;

Редактировать: Позвольте уточнить — я упустил несколько деталей. Мне нужен один адрес и порт с несколькими базовыми URL, которые могут достигать нескольких DSM без базовых URL, чтобы предотвратить конфликт/столкновение. Я знаю, что несколько адресов и портов возможны. Я ищу способ подключиться к серверу, работающему на nginx, по SSH с -L локальной переадресацией, чтобы перенаправить один порт, и таким образом достичь нескольких DSM на одном SSH-перенаправляемом порту. Решение, которое у меня есть сейчас, работает, но только для одного DSM. Если я добавлю второй, они сталкиваются.

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

Вместо этого мы можем просто направить все запросы к DSM.

Есть три метода иметь несколько серверов DSM без конфликтов.

Метод №1: Виртуальные хосты

Вам нужно будет настроить DNS, чтобы ваш выбранный виртуальный хост указывал на сервер NGINX.

http {
    #DSM 1 Стандартная настройка DSM
    upstream dsm1 {
        server 1.1.1.1:5000;
    }
    #DSM 2 - DSM имеет другой порт, тот же IP-адрес
    upstream dsm2 {
        server 1.1.1.1:6000;
    }
    #DSM 3 - DSM имеет другой IP-адрес
    upstream dsm3 {
        server 2.1.1.1:5000;
    }
    #DSM 1 Стандартная настройка DSM
    server {
        listen       80;
        server_name dsm1.mydomain.com;
        location / {
            include proxy_headers;
            proxy_pass http://dsm1/;
    }
    #DSM 2 - DSM имеет другой порт, тот же IP-адрес
    server {
        listen       80;
        server_name dsm2.mydomain.com;
        location / {
            include proxy_headers;
            proxy_pass http://dsm2/;
    }
    #DSM 3 - DSM имеет другой IP-адрес
    server {
        listen       80;
        server_name dsm3.mydomain.com;
        location / {
            include proxy_headers;
            proxy_pass http://dsm3/;
    }

Метод №2, Разные порты NGINX

Каждый сервер может быть доступен на своем порту на сервере NGINX.

http {
    #DSM 1 Стандартная настройка DSM
    upstream dsm1 {
        server 1.1.1.1:5000;
    }
    #DSM 2 - DSM имеет другой порт, тот же IP-адрес
    upstream dsm2 {
        server 1.1.1.1:6000;
    }
    #DSM 3 - DSM имеет другой IP-адрес
    upstream dsm3 {
        server 2.1.1.1:5000;
    }
    #DSM 1 Стандартная настройка DSM
    server {
        listen       80;
        location / {
            include proxy_headers;
            proxy_pass http://dsm1/;
    }
    #DSM 2 Этот сервер DSM доступен на другом порту (8081). Доступ через http://nginx_ip:8081
    server {
        listen       81;
        location / {
            include proxy_headers;
            proxy_pass http://dsm1/;
    }
}

Метод №3: Переписывания

Каждый сервер может быть доступен через под-URL на сервере NGINX. Это может не сработать в зависимости от конфигурации веб-страницы DSM и от использования относительных или абсолютных URL.

http {
    #DSM 1
    upstream dsm1 {
      server 1.1.1.1:5000
    }
    #DSM 2
    upstream dsm2 {
      server: 1.1.1.2:5000
    }
    server {
      listen 80;
      location /dsm1/(?<dsmurl>.*) {
        include proxy_headers;
        proxy_pass http://dsm1/$dsmurl
      }
      location /dsm2/(?<dsmurl>.*) {
        include proxy_headers;
        proxy_pass http://dsm2/$dsmurl
      }
     }
}

Ответ или решение

Вопрос интересный и актуальный, особенно если рассматривать его в контексте управления множества ресурсов на уровне одной инфраструктуры. Ниже описаны различные подходы к реализации обратного проксирования запросов от Nginx к нескольким серверам Synology DSM без использования базового URL.

Метод 1: Виртуальные хосты

Данный метод предполагает использование разных доменных имен для каждого DSM. Это позволяет избежать коллизий и обеспечить четкую маршрутизацию запросов.

http {
    # DSM 1 - стандартная конфигурация DSM
    upstream dsm1 {
        server 1.1.1.1:5000;
    }

    # DSM 2 - тот же IP, но другой порт
    upstream dsm2 {
        server 1.1.1.1:6000;
    }

    # DSM 3 - другой IP
    upstream dsm3 {
        server 2.1.1.1:5000;
    }

    server {
        listen       80;
        server_name dsm1.mydomain.com;
        location / {
            include proxy_headers;
            proxy_pass http://dsm1/;
        }
    }

    server {
        listen       80;
        server_name dsm2.mydomain.com;
        location / {
            include proxy_headers;
            proxy_pass http://dsm2/;
        }
    }

    server {
        listen       80;
        server_name dsm3.mydomain.com;
        location / {
            include proxy_headers;
            proxy_pass http://dsm3/;
        }
    }
}

Метод 2: Разные порты Nginx

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

http {
    upstream dsm1 {
        server 1.1.1.1:5000;
    }

    upstream dsm2 {
        server 1.1.1.1:6000;
    }

    upstream dsm3 {
        server 2.1.1.1:5000;
    }

    server {
        listen       80;
        location / {
            include proxy_headers;
            proxy_pass http://dsm1/;
        }
    }

    server {
        listen       81;  # Используйте другой порт для второго DSM
        location / {
            include proxy_headers;
            proxy_pass http://dsm2/;
        }
    }

    server {
        listen       82;  # И ещё один порт для третьего DSM
        location / {
            include proxy_headers;
            proxy_pass http://dsm3/;
        }
    }
}

Метод 3: Переписывание URL

Третий метод предполагает использование переписывания URL для маршрутизации запросов. Этот подход зависит от конфигурации веб-страницы DSM, которая может не поддерживать работу с переписанными URL.

http {
    upstream dsm1 {
        server 1.1.1.1:5000;
    }

    upstream dsm2 {
        server 1.1.1.2:5000;
    }

    server {
        listen 80;

        location /dsm1/(?<dsmurl>.*) {
            include proxy_headers;
            proxy_pass http://dsm1/$dsmurl;
        }

        location /dsm2/(?<dsmurl>.*) {
            include proxy_headers;
            proxy_pass http://dsm2/$dsmurl;
        }
    }
}

Завершение

Каждый из предложенных методов имеет свои преимущества и недостатки, и выбор зависит от ваших индивидуальных потребностей и конфигурации сети. Виртуальные хосты наиболее гибкие и безопасные, но требуют правильной настройки DNS. Использование разных портов упрощает конфигурацию, но не всегда удобно для пользователей. Переписывание URL может не всегда сработать из-за особенностей веб-интерфейса DSM.

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

Оцените материал
Добавить комментарий

Капча загружается...