Come configurare NGINX come proxy inverso per diversi numeri di porta?


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

Voglio anche proxy le richieste SSH (porta 22). Posso aggiungere un altro blocco server come questo nello stesso file di configurazione:

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

Tale che il risultato finale sia questo:

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


2
nginxagisce come httpproxy. Se lo imposti sulla porta proxy inversa 22 non ti consentirà di passare il traffico SSH - solo il httptraffico al server SSH, che ovviamente fallirà.
garethTheRed,

Vai a dare un'occhiata a HAProxy .

Risposte:


13

Il protocollo ssh non si basa su HTTP e, in quanto tale, non può essere proxy tramite il normale proxy_passdingx_http_proxy_module

Tuttavia, di recente, a partire da nginx 1.9.0 (rilasciato come stabile con 1.10.0 il 26-04-2016), nginx ha ottenuto il supporto per eseguire il proxy del flusso TCP , il che significa che se si dispone di una versione abbastanza recente di nginx, puoi, infatti, eseguire il proxy delle connessioni SSH con esso (tuttavia, tieni presente che non saresti in grado di aggiungere qualcosa di simile X-Real-IPalla connessione proxy, poiché non si basa su HTTP).

Per ulteriori informazioni ed esempi, dai un'occhiata a:


8

Dalla versione 1.9.0 di Nginx, NGINX supporta il modulo ngx_stream_core_module, dovrebbe essere abilitato con --with-stream. Quando il modulo stream è abilitato, è possibile eseguire il protocollo tshp proxy ssh

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/


Questa è tutta una bella caratteristica di nginx - ma IMHO è inutile quando vuoi avere un vero proxy inverso come nginx fa un lavoro perfetto per HTTP. L'approccio agli stream è semplice NAT - quindi preferirei fare questo compito sul router di bordo. Quello che vorrei / vorrei avere qui - è esattamente lo stesso set di funzioni del proxy inverso HTTP. In altre parole, ho un solo indirizzo IP pubblico - quindi la porta 22 è disponibile solo per una macchina - ma se ci fosse un modo per distinguere le richieste in un modulo ssh me@srv1.my.nete ssh me@srv2.my.net- sarebbe fantastico. È una limitazione del protocollo (SSH non distribuirà gli usi del client DNS)
stamster

@stamster, puoi già fare quasi la stessa cosa, utilizzando numeri di porta diversi (ad esempio, 122 per srv1e 222 per srv2), oppure utilizzando sessioni ssh nidificate, in cui si entra per la prima volta nel server / IP pubblico e da lì, ssh nelle foglie; ad es ssh user@example.org 'ssh user@192.168.5.1'.
primo

1
No, il requisito / idea è di utilizzare la porta predefinita (22 o qualsiasi altro servizio ...) come porta di destinazione e quindi instradare il traffico in base al nome DNS o giù di lì. Proprio come tutti noi stiamo utilizzando nginx come server proxy http web inverso, quindi ogni dominio ha come target le porte predefinite 80, 443 e quindi nginx indirizza il traffico in base alle regole proxy. Ovviamente il client ha HOSTun'intestazione, quindi è facile distinguere il sito a cui si rivolge ... Le sessioni SSH nidificate sono una specie di soluzione ma disordinata, ma funziona comunque. Ho finito con diverse porte sulla nostra rete di confine - buon vecchio NAT come la soluzione più KISS e affidabile.
criceto
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.