Как настроить NGINX в качестве обратного прокси для разных номеров портов?


15
I have NGINX configured like this as a reverse proxy for http requests:

server {
    listen 80;
    server_name 203.0.113.2;

    proxy_set_header X-Real-IP  $remote_addr; # pass on real client IP

    location / {
        proxy_pass http://203.0.113.1:3000;
    }
}

Я также хочу прокси ssh (порт 22) запросов. Могу ли я добавить еще один блок сервера, например, в тот же файл конфигурации:

server {
    listen 22;
    server_name 203.0.113.2;

    proxy_set_header X-Real-IP  $remote_addr; # pass on real client IP

    location / {
        proxy_pass http://203.0.113.1:22;
    }
}

Так что конечный результат таков:

server {
    listen 80;
    server_name 203.0.113.2;

    proxy_set_header X-Real-IP  $remote_addr; # pass on real client IP

    location / {
        proxy_pass http://203.0.113.1:3000;
    }
}
server {
    listen 22;
    server_name 203.0.113.2;

    proxy_set_header X-Real-IP  $remote_addr; # pass on real client IP

    location / {
        proxy_pass http://203.0.113.1:22;
    }
}

ТИА,
Оле


2
nginxдействует как httpпрокси. Если вы установите для него обратный прокси-порт 22, он не позволит вам передавать трафик SSH - только httpтрафик на сервер SSH, который, очевидно, потерпит неудачу.
garethTheRed

Перейти проверить HAProxy .

Ответы:


13

Протокол SSH не основан на HTTP, и, как таковые, не может быть проксированным через регулярные proxy_passизngx_http_proxy_module

Однако недавно, начиная с nginx 1.9.0 (выпущен как стабильный с 1.10.0 на 2016-04-26), nginx получил поддержку для прокси TCP-потока , что означает, что если у вас достаточно свежая версия nginx, вы можете подключиться к нему через ssh-прокси (однако учтите, что вы не сможете добавить что-либо подобноеX-Real-IP прокси-соединению, поскольку оно не основано на HTTP).

Для получения дополнительной информации и примеров, посмотрите на:


8

Начиная с Nginx версии 1.9.0, NGINX поддерживает модуль ngx_stream_core_module, его следует включить с помощью --with-stream. Когда потоковый модуль включен, они могут использовать протокол ssh по протоколу tcp.

stream {
    upstream ssh {
        server 192.168.1.12:22;
    }
        server {
        listen        12345;
        proxy_pass    ssh;

    }

}

https://www.nginx.com/resources/admin-guide/tcp-load-balancing/


Это все приятная особенность nginx - но IMHO бесполезно, когда вам нужен реальный обратный прокси, такой как nginx отлично справляется с HTTP. Дело в том, что потоковый подход - это простой NAT, поэтому я бы предпочел выполнить эту задачу на граничном маршрутизаторе. То, что я хотел бы / хотел бы иметь здесь - это точно такой же набор функций, что и обратный прокси HTTP. Другими словами, у меня есть только один общедоступный IP-адрес - таким образом, порт 22 доступен только для одной машины - но если бы был способ различать запросы в форме ssh me@srv1.my.netи ssh me@srv2.my.net- это было бы здорово. Это ограничение протокола (SSH не выдаст DNS-имя, используемое клиентом)
stamster

@stamster, вы уже можете делать почти одно и то же, либо используя разные номера портов (например, 122 для srv1и 222 для srv2), либо используя вложенные сеансы ssh, где вы сначала вводите ssh на общедоступный сервер / IP, и оттуда, сш в листья; например, ssh user@example.org 'ssh user@192.168.5.1'.
CNST

1
Нет, требование / идея состоит в том, чтобы использовать порт по умолчанию (22 или любой другой сервис ..) в качестве порта назначения, а затем маршрутизировать трафик в зависимости от имени DNS или около того. Точно так же, как мы все используем nginx в качестве обратного веб-прокси-сервера http, поэтому каждый домен использует порты по умолчанию 80, 443, а затем nginx направляет трафик в зависимости от правил прокси. Конечно, у клиента есть HOSTзаголовок, так что легко определить , на какой сайт он нацелен ... Вложенные SSH-сессии - своего рода решение, но грязное - это работает, хотя. В конечном итоге у меня были разные порты в нашей пограничной сети - старый добрый NAT как самое ПОЛЕЗНОЕ и надежное решение.
Stamster
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.