NGINX Reverse Proxy SSH Map Problem

Wir haben mehrere virtuelle (Ubuntu) Server in unserem Unternehmen. Jeder hat seine Netzwerkverbindung überbrückt, sodass er seine eigene IP-Adresse vom Router erhält (DHCP-reserviert). Wir müssen mehrere Websites mit eigenen Subdomains betreiben.

Wir haben unsere Top-Domain (sagen wir example.com)

Dann haben wir sub1.example.com, sub2.example.com und sub3.example.com

Der einfachste Weg, dies zu tun, schien darin zu bestehen, einen Reverse-Proxy auszuführen (damit wir in Zukunft einige in die Cloud verschieben und den Lastenausgleich verwenden können).

Ich habe eine neue VM mit Ubuntu 20.04 LTS unter NGINX eingerichtet und als Reverse-Proxy konfiguriert.

Ich habe derzeit 3 ​​Konfigurationen:

redirect_https:

server {
    listen 80;
    listen [::]:80;
    
    server_name *.example.com;
    return 301 https://$host$request_uri;
}

SSL-Proxy:

server {
    listen 443 ssl;
    server_name example.com;
    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded_Proto https;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_redirect off;
        proxy_pass https://10.10.x.y;
        proxy_http_version 1.1;
    }
    
    ssl_certificate        /etc/<path_to_cert>/fullchain.pem;
    ssl_certificate_key    /etc/<path_to_cert>/privkey.pem;
}

SSL-Proxy-Subdomains:

server {
    listen 443 ssl;
    server_name sub1.example.com sub2.example.com sub3.example.com;
    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host; proxy_set_header X-Forwarded_Proto https; proxy_set_header X-Real-IP $remote_addr;
        proxy_redirect off;
        proxy_pass https://10.10.x.y;
        proxy_http_version 1.1;
    }
    
    ssl_certificate        /etc/<path_to_cert>/fullchain.pem;
    ssl_certificate_key    /etc/<path_to_cert>/privkey.pem;
}

Das alles funktioniert gut.

Um unsere Websites von zu Hause aus bearbeiten zu können, wollte ich den Proxy so konfigurieren, dass er auch SSH-Verkehr weiterleitet. Dort bin ich verwirrt.

Ich habe eine Reihe von Beiträgen hier gelesen, auf anderen Websites, NGINX-Dokumentation, ich scheine das nicht herauszufinden.

Ich bin dem Beispiel direkt aus der Dokumentation gefolgt: https://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html

Scheint ziemlich einfach zu sein.

Meine Konfiguration ist praktisch identisch (nur geänderte Teile, die für mein Unternehmen relevant sind, wie IP-Adressen usw.)

Der Vollständigkeit halber trägt das von mir verwendete Beispiel den Titel Auswählen eines Upstreams basierend auf dem Servernamen

Meine Konfiguration (geändert):

map $ssl_preread_server_name $name {
    example.com           backend_main;
    sub1.example.com      backend_1;
    sub2.example.com      backend_2;
    sub3.example.com      backend_3;
    default               backend_proxy;
}

upstream backend_main { server 10.10.x.y:22; }
upstream backend_1 { server 10.10.x.y:22; }
upstream backend_2 { server 10.10.x.y:22; }
upstream backend_3 { server 10.10.x.y:22; }
upstream backend_proxy { server 10.10.x.y:22; }

server {
    listen      2222;
    proxy_pass  $name; ssl_preread on; } log_format proxy '$remote_addr [$time_local] ' '$protocol $status $bytes_sent $bytes_received ' '$session_time "$upstream_addr" ' '"$upstream_bytes_sent" "$upstream_bytes_received" "$upstream_connect_time"';

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

Der obige Codeabschnitt befindet sich innerhalb des stream {...}Blocks /etc/nginx/nginx.confnach dem html {...}Block (direkt vor dem kommentierten mail {...}Block).

Der Router nimmt den externen Port 22 und leitet ihn an den internen Port 2222 des Reverse-Proxys weiter.

Das Problem, mit dem ich konfrontiert bin, ist, dass mapimmer die Standardoption ausgewählt wird . Wenn ich die Standardeinstellung entferne / kommentiere, kann ich überhaupt keine Verbindung herstellen. Wenn ich die IP-Adresse in der Standardeinstellung ändere, wird ich mit diesem Server verbunden, aber auch hier gilt nur der "Standard".

Das Endziel ist es, direkt in eine der Subdomains (z ssh [email protected]. B. ) ssh zu können . Im Moment muss ich auf einen Server ssh, auf den ich mir externen Zugriff gewährt habe, und von dort aus einen internen ssh.

Das einzige, was mir in den Sinn kommt, ist, dass dies mit dem vorhandenen HTTPS-Proxy möglicherweise nicht gut streamfunktioniert, aber das Modul sollte möglicherweise auch in der Lage sein, diese zu verarbeiten (und wenn ja, kann ich Header festlegen, andernfalls sehen die Backends nur die Anfragen vom Reverse Proxy).

Ich habe den Verdacht, dass dies ein einfaches Problem ist und dass ich etwas übersehen habe, aber nachdem ich 8 Stunden lang gelesen und verschiedene Dinge ausprobiert habe, ist es an der Zeit, um Hilfe zu bitten ...

Der SSH-Client verwendet keine SNI-Erweiterungen des TLS-Protokolls, die zur Unterstützung des Shared Hosting mit HTTPS entwickelt wurden. Sie können versuchen, Ihren SSH-Client folgendermaßen einzurichten:

Host example.com *.example.com
    ProxyCommand openssl s_client -quiet -servername %h -connect example.com:2222

Ich weiß jedoch nicht, ob es funktionieren würde. Weitere s_clientInformationen zum Befehl openssl finden Sie hier . Schauen Sie sich auch diesen Artikel an: Proxy SSH mit TLS / SNI und NGINX .

Die offensichtliche Sache ist, dass ssh nicht https ist und sein Protokoll keinen Hostnamen sendet, mit dem Sie wie mit https übereinstimmen können.

Ich habe einige Hosts mit ähnlichen Einschränkungen, da es sich um virtuelle Maschinen handelt, die keine globale IPv4-Adresse haben. Für diese greife ich über ssh mit IPv6 darauf zu. Wenn Sie IPv6 aus irgendeinem Grund nicht bereitgestellt haben, sind Sie jetzt einige Jahre hinter der Kurve ...