23.10.2023

3469

Internet Traffic mit nginx auf interne IP weiterleiten

Hallo!

Wenn ich auf meinem Server einen VPN laufen habe, könnte ich per nginx Traffic vom Internet auf eine interne IP weiterleiten?

Beispiel:
demo.company.com:8877 leitet nginx(?) weiter auf die interne IP 10.11.12.13 (Port 8877)

Klappt das Grundsätzlich und falls ja, ist nginx dafür die passende Software?

Danke!

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 73365187817

Url: https://administrator.de/contentid/73365187817

Ausgedruckt am: 25.11.2024 um 11:11 Uhr

25 Kommentare

Neuester Kommentar

Moin,

mal als Einstieg: https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opi ...

Gruß

Zitat von @Kraemer:

Moin,

mal als Einstieg: https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opi ...

Gruß

Danke, aber alles was ich finde bezieht sich auf http. Ich müsste jeglichen Traffic umleiten. Also raw tcp

nun - du sagst ja oben selbst in deinem beispiel mit port 8877 -> port 8877. Selbst wenn nginx das also könnte (und das halte ich bereits für fraglich) - willst du wirklich ca. 65.000 Ports weiterleiten? Da du ja nicht weisst auf welchem Port der was macht... Und spätestens jetzt sollte dir klar sein das es wohl so nicht hinhauen wird...

Wenn du wirklich eine interne Maschine komplett mit allen Ports erreichbar haben willst ist VPN dein Freund... alternativ die kiste direkt ins Internet hängen und einfach alles offen lassen. Hat den Vorteil das vermutlich die Script-Kiddys in Minuten ne neue Spielwiese gefunden haben.

Zitat von @Fohnbit:
Danke, aber alles was ich finde bezieht sich auf http. Ich müsste jeglichen Traffic umleiten. Also raw tcp

Ja kann er sogar Load-Balancing und Fallback lässt sich hier konfigurieren ...
Module ngx_stream_core_module

Beispiel um einen SSH-Zugriff auf Port 2222 des nginx auf einen internen Host Port 22 zu tunneln:

# reverse proxy any port to other internal hosts
stream {
    upstream ssh_group {
        server 10.16.1.3:22 max_fails=3 fail_timeout=10s;
    }
    server {
        listen 2222;
        listen [::]:2222;
        proxy_pass ssh_group;
        proxy_connect_timeout 5s;
    }
}

Aber wozu dann nginx, Port schon belegt und du brauchst ihn nochmal? Eine simple Portweiterleitung an der Firewall würde hier ja das gleiche machen ...

Gruß sid

Habe inzwischen HAproxy entdeckt. Mit dieser Konfig klappt es bei mir:

frontend demo1
        bind demo1.company.com:8877
        mode tcp
        default_backend demo_pool

frontend demo2
        bind demo2.company.com:8877
        mode tcp
        default_backend demo_pool

backend demo_pool
        balance roundrobin
        mode tcp
        server demo1 10.11.12.2:8877 check
        server demo2 10.11.12.6:8877 check

Spricht hier etwas dagegen? Ich muss wohl pro Host ein Frontend anlegen, oder?

Zitat von @7907292512:

Zitat von @Fohnbit:
Danke, aber alles was ich finde bezieht sich auf http. Ich müsste jeglichen Traffic umleiten. Also raw tcp

# reverse proxy any port to other internal hosts
stream {
    upstream ssh_group {
        server 10.16.1.3:22 max_fails=3 fail_timeout=10s;
    }
    server {
        listen 2222;
        listen [::]:2222;
        proxy_pass ssh_group;
        proxy_connect_timeout 5s;
    }
}

Aber wozu dann nginx, Port schon belegt und du brauchst ihn nochmal? Eine simple Portweiterleitung an der Firewall würde hier ja das gleiche machen ...

Gruß sid

nein, ich habe einen VPN installiert und es soll auf einen anderen host weiter geleitet werden

Zitat von @Fohnbit:
nein, ich habe einen VPN installiert

Das sagt hier ja nunmal rein gar nichts aus in einem Admin-Forum 🤮 , wo installiert, von wo nach wo usw weiß hier niemand ... Du schmeißt hier einfach was in den Raum ohne Umgebungsbedingungen für alle klar zu definieren!
Da kann man keine klaren Empfehlungen abgeben das sollte jedem klar sein.

und es soll auf einen anderen host weiter geleitet werden

Dafür reicht n simples Firewall-DSTNAT das funktioniert auch über ein VPN wenn das Routing stimmt ...

Nein klappt noch nicht richtig, der erste connect geht wohl immer zum ersten host

Montag der Selbstgespräche, oh man... komm Freitag wieder 😂

Zitat von @7907292512:

Zitat von @Fohnbit:
nein, ich habe einen VPN installiert

und es soll auf einen anderen host weiter geleitet werden

Dafür reicht n simples Firewall-DSTNAT das funktioniert auch über ein VPN wenn das Routing stimmt ...

Gern mehr im Detail:
Ich habe auf meinem Cloudserver Wireguard installiert. Darauf connecten sich einige PCs, die aus dem Internet erreichbar sein sollen (ohne Portforwarding).
Die PCs sind vom Clooudserver aus erreichbar. Der Cloudserver selbst hat 10.11.12.0

Nun würde ich gerne jedem Host im VPN Tunnel einen DNS Namen zuordnen:
demo1.company.com => 10.11.12.2
demo2.company.com => 10.11.12.6
...

So kann ich vom Internet aus auf die PCs zugreifen

OK. Dann siehe nginx config von mir oben, die funktioniert bei sowas problemlos.
Das Stream-Module ist dabei dein Freund und Helfer
http://nginx.org/en/docs/stream/ngx_stream_core_module.html

Zitat von @7907292512:

OK. Dann siehe nginx config von mir oben, die funktioniert bei sowas problemlos.
Das Stream-Module ist dabei dein Freund und Helfer
http://nginx.org/en/docs/stream/ngx_stream_core_module.html

Danke. Wäre es aber mit HAproxy ebenso möglich?
Auf nginx habe ich Grafana und Influxdb laufen. Wenn ich hosts adde muss ich nginx immer neu starten.
Und wenn ich einen Tippfehler mache, sind Grafana und Influxdb auch nicht erreichbar.

Daher wäre es wohl besser, das mit einem anderen Tool zu machen?

Klar geht das auch mit HAProxy,

Nein klappt noch nicht richtig, der erste connect geht wohl immer zum ersten host

Du hast oben nur beiden FQDNS den selben Pool zugeordnet wenn du eine feste Zuordnung willst brauchst du pro FQDN einen eigenen Pool.

Und wenn ich einen Tippfehler mache, sind Grafana und Influxdb auch nicht erreichbar.

Dann macht man eben keine Fehler und testet seine Configs vor dem Anwenden auf dem Produktiv-Server!

Zitat von @7907292512:

Klar geht das auch mit HAProxy,

Nein klappt noch nicht richtig, der erste connect geht wohl immer zum ersten host

Du hast oben nur beiden FQDNS den selben Pool zugeordnet wenn du eine feste Zuordnung willst brauchst du pro FQDN einen eigenen Pool

Danke:

frontend demo1
        bind demo1.company.com:8877
        mode tcp
        default_backend demo1_pool

backend demo1_pool
        mode tcp
        server demo1 10.11.12.2:8877 check

frontend demo2
        bind demo2.company.com:8877
        mode tcp
        default_backend demo2_pool

backend demo2_pool
        mode tcp
        server demo2 10.11.12.6:8877 check

habe aber noch den selben Effekt.

edit: Roundrobin entfernt. Aber noch immer klappt nicht gleich jeder Verbindungsaufbau

Ach ich Idiot, das geht natürlich nicht wenn du die selben Ports nutzt. Man kann den selben Port hier nur jeweils einmal binden weil andere TCP-Protokolle ja keine Hostheader Auswertung wie http haben. Deswegen wird auch immer nur der erste Server nach Config-Reihenfolge angesprochen ...

Zitat von @7907292512:

Ach ich Idiot, das geht natürlich nicht wenn du die selben Ports nutzt. Man kann den selben Port hier nur jeweils einmal binden weil andere TCP-Protokolle ja keine Hostheader Auswertung wie http haben. Deswegen wird auch immer nur der erste Server nach Config-Reihenfolge angesprochen ...

Demnach zurück zu nginx

Zitat von @Fohnbit:
Demnach zurück zu nginx

Das hat aber aus Prinzip die selbe Einschränkung.

Überleg mal: Wie sollten die Proxies entscheiden können über welchen DNS-Namen sie aufgerufen wurden? Genau, es gibt keinen Hostheader im Traffic, ergo kann der Proxy auch nicht unterscheiden welchen Traffic er welchem Host zuordnen soll ...

danke, ja soweit verständlich. Ich habe mit HAproxy einmal auf unterschiedlichen Ports eingerichtet.
Eine Möglichkeit eine DNS-Namen "Erkennung" über ein 3rd party Programm ist Euch keines bekannt, oder?

Zitat von @Fohnbit:
Eine Möglichkeit eine DNS-Namen "Erkennung" über ein 3rd party Programm ist Euch keines bekannt, oder?

Hier gilt auch wieder, vorher in sich gehen und nachdenken. Der User tippt demo2.company.com:8877 ein, der Rechner des Users löst die Domain zu seiner IP auf, das Programm verbindet sich nur mit der IP und dem Port, wie sollte also jetzt noch eine Erkennung des Hostnamens am Server stattfinden?Das schafft selbst die Glaskugel nicht mehr, das ginge, wenn dann nur, wenn der Proxy in den Traffic schauen kann und in dem Protokoll das verwendet wird auch der Hostname irgendwo aufgeführt würde (wenn überhaupt), dazu müsste man aber für jedes einzelne mögliche TCP-Protokoll ein Modul schreiben, ganz zu schweigen bei verschlüsseltem Traffic bei dem ein aufbrechen nötig wäre.
Bei http(s) ist das Szenario kein Problem, da hier die Domain im Hostheader bei jeder Anfrage steht und diese der proxy einfach auslesen kann, oder wenn TLS dann über den SNI.

Soweit greift die Software auf einen Jetty Server zu und nutzt long poll über einen Websocket. Eventuell nutzt die von mir genutzte Software doch http oder https Protokoll. Kennst du einen einfachen Weg das zu testen? Einen Server der eingehende Daten anzeigt?

Edit: der Aufruf https://demo2.company.com:8877 ergibt den Jetty Server. Demnach ist es eh https?

Soweit ich im Netz gefunden habe, müsste es so klappen:

frontend demo
        bind 0.0.0.0:8877
        acl demo1 hdr(host) -i demo1.company.com:8877
        use_backend demo1_back if demo1

        acl demo2 hdr(host) -i demo2.company.com:8877
        use_backend demo2_back if demo2


backend demo1_back
        mode http
        server demo1 10.11.12.2:8877 check

backend demo2_back
        mode http
        server demo2 10.11.12.6:8877 check

bekomme aber noch keine Verbindung.

geschafft:

global
    log /dev/log    local0
    log /dev/log    local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    maxconn 4096
    user haproxy
    group haproxy
    daemon


defaults
    log     global
    mode    tcp
    option  tcplog
    option  dontlognull
    timeout connect 15s
    timeout client  15s
    timeout server  15s
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http


frontend localhost8877
    bind *:8877
    option tcplog
    mode tcp

    acl tls req.ssl_hello_type 1

    tcp-request inspect-delay 5s
    tcp-request content accept if tls

    acl is_demo1 req.ssl_sni -i demo1.company.com
    acl is_demo2 req.ssl_sni -i demo2.company.com 

    use_backend demo1 if is_demo1
    use_backend demo2 if is_demo2


backend demo1
    mode tcp
    option ssl-hello-chk
    server is_demo1 10.11.12.2:8877 check


backend demo2
    mode tcp
    option ssl-hello-chk
    server is_demo2 10.11.12.6:8877 check

könnte ich per nginx Traffic vom Internet auf eine interne IP weiterleiten?

Ja, das geht problemlos. Guckst du hier:
VPN Server mit NGINX Port Forwarding

Hallo, nun etwas ausgebaut und scheint ein Problem zu geben.

Scheinbar läuft jede Weiterleitung auf dem selben Quellport. Sobald sich ein anderer auf den backend verbindet, schmeißt es den aktuellen raus. Als wäre immer nur eine Verbindung pro Sitzung möglich.

Übernimmt er den Quellport vom Server zum backend host? Falls nicht und er nutzt immer den selben, wäre das Verhalten nachvollziehbar.

global
    log /dev/log    local0
    log /dev/log    local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    maxconn 4096
    user haproxy
    group haproxy
    daemon

defaults
    log     global
    mode    tcp
    option  dontlognull
    timeout connect 15s
    timeout client  15s
    timeout server  15s
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http

frontend cloud.company.com
    bind *:8443
    mode tcp
    acl tls req.ssl_hello_type 1
    log-format "%ci:%cp [%[src,map_ip(/etc/haproxy/haproxy_geo_ip.txt)]] [%t] %ft %b/%s %Tw/%Tc/%Tt %B %ts %ac/%fc/%bc/%sc/%rc %sq/%bq"  
    tcp-request inspect-delay 5s
    tcp-request content accept if tls

# --- GEO Block
    acl acl_geoloc_block src,map_ip(/etc/haproxy/haproxy_geo_ip.txt) -m reg -i (CH|AT|DE|IT|FR)
    use_backend block_geo if !acl_geoloc_block
# ---


    acl is_controller req.ssl_sni -i controller.cloud.company.com   #10.11.0.2
    acl is_user.haus1  req.ssl_sni -i user.haus1.cloud.company.com    #10.11.0.6
    acl is_user.haus2  req.ssl_sni -i user.haus2.cloud.company.com    #10.11.0.7
    acl is_user.haus3  req.ssl_sni -i user.haus3.cloud.company.com    #10.11.0.8



    use_backend controller if is_controller
    use_backend user.haus1  if is_user.haus1
    use_backend user.haus2  if is_user.haus2
    use_backend user.haus3  if is_user.haus3



backend block_geo
        timeout tarpit 5s
        errorfile 404 /etc/haproxy/errors/403.http

backend controller
    mode tcp
    option ssl-hello-chk
    server controller 10.11.0.2:8443 check


backend user.haus1
    mode tcp
    option ssl-hello-chk
    server user.haus1 10.11.0.6:8443 check

backend user.haus2
    mode tcp
    option ssl-hello-chk
    server user.haus2 10.11.0.7:8443 check

backend user.haus3
    mode tcp
    option ssl-hello-chk
    server user.haus3 10.11.0.8:8443 check