Comment configurer NGINX en tant que proxy inverse pour différents numéros de port?

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

Je veux également proxy des demandes ssh (Port 22). Puis-je ajouter un autre bloc serveur comme celui-ci au même fichier de configuration:

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

Tels que le résultat final est le suivant:

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

TIA,
Ole

nginx

— Ole
source

2

nginxagit en tant que httpmandataire. Si vous le définissez pour inverser le port proxy 22, il ne vous permettra pas de transmettre le trafic SSH - uniquement le httptrafic vers le serveur SSH, qui échouera évidemment.

— garethTheRed

Allez voir HAProxy .

13

Le protocole ssh ne repose pas sur HTTP, et, en tant que telle, ne peut pas être par la approximé régulière proxy_passdengx_http_proxy_module

Cependant, récemment, à partir de nginx 1.9.0 (publié comme stable avec 1.10.0 le 26/04/2016), nginx a pris en charge la fonction de proxy de flux TCP , ce qui signifie que si vous avez une version assez récente de nginx, vous pouvez, en fait, les connexions proxy ssh avec elle (cependant, notez que vous ne pourriez pas ajouter quelque chose comme le X-Real-IPà la connexion proxy, car cela n'est pas basé sur HTTP).

Pour plus d'informations et d'exemples, consultez:

— cnst
source

8

Depuis Nginx version 1.9.0, NGINX prend en charge le module ngx_stream_core_module, il doit être activé avec le --with-stream. Lorsque le module de flux est activé, il est possible de faire un proxy TCP 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/

— Hendi Fauzi
source

C'est une fonctionnalité intéressante de nginx - mais à mon humble avis, cela ne sert à rien lorsque vous voulez avoir un vrai proxy inverse comme nginx fait un travail parfait pour HTTP. La chose est que l'approche des flux est un NAT simple - donc je préfère faire cette tâche sur un routeur de périphérie. Ce que je voudrais / aimerais avoir ici - c'est exactement le même ensemble de fonctionnalités que le proxy inverse HTTP. En d'autres termes, je n'ai qu'une seule adresse IP publique - donc le port 22 n'est disponible que pour une seule machine - mais s'il y avait un moyen de distinguer les demandes sous une forme ssh me@srv1.my.netet ssh me@srv2.my.net- ce serait génial. C'est la limitation du protocole (SSH ne donnera pas les utilisations du client de nom DNS)

— stamster

@stamster, vous pouvez déjà faire presque la même chose, soit en utilisant des numéros de port différents (par exemple, 122 pour srv1et 222 pour srv2), soit en utilisant des sessions ssh imbriquées, où vous commencez par ssh dans le serveur / IP public, et à partir de là, ssh dans les feuilles; par exemple ssh user@example.org 'ssh user@192.168.5.1'.

— 2018

1

Non, l'exigence / l'idée est d'utiliser le port par défaut (22 ou tout autre service ..) comme port de destination, puis d'acheminer le trafic en fonction du nom DNS ou autre. Tout comme nous utilisons tous nginx comme serveur proxy http Web inversé, chaque domaine cible les ports par défaut 80, 443, puis nginx achemine le trafic en fonction des règles de proxy. Bien sûr, le client a un en- HOSTtête, il est donc facile de distinguer le site qu'il cible ... Les sessions SSH imbriquées sont en quelque sorte une solution mais en désordre - cela fonctionne cependant. Je me suis retrouvé avec différents ports sur notre réseau de périphérie - le bon vieux NAT comme la solution la plus KISS et la plus fiable.

— stamster