NAS mit docker und traefik (reverse proxy), wie tatsächliche client IP anzeigen?

[Habak1]

Hallo,

ich betreibe auf dem NAS mehrere über SSH eingerichtete Docker-Container. U.a. auch Traefik als reverse-proxy.
Das funktioniert alles auch soweit.
Wenn ich mir jedoch in den "access.log"´s die client-IP-Adressen ansehe, stehen dort immer nur die 127.0.0.....Adressen von Docker. Was muss ich bitte tun, damit ich die tatsächliche IP-Adresse sehe, die die Anfrage (request) gesendet hat?
Für Eure Unterstützung schon im voraus vielen Dank.
Gruß Habak

 

[haydibe]

Das geht nur mit --network=host oder mit MACVLAN.

Im Bridge Netzwerk wird immer die Ip immer von docker0 Interface zu sehen sein. Im Swarm Mode könnte man auch einzelne Ports im Host-Modus betreiben - allerdings ist der Aufgrund eines Fehlers, bei dem die Env-Variablen nicht an den Container durchgereicht werden, defacto nicht nutzbar.

 

[Habak1]

Hallo haydibe,

vielen, vielen Dank für die schnelle Antwort.
Vielleicht erläuterte ich erstmal den Hintergrund meiner Anfrage: Ich habe in den Docker-Containern unterschiedliche Webanwendungen mit Authentifizierung laufen, bei denen ich gerne wüsste, wer sich anzumelden versucht.
Da ich aber auf dem NAS bisher nginx nicht als VirtualHost oder Reverse-Proxy nutze, sondern nur die Docker-Container, kann ich auch keine Zugriffe (mit der tatsächlichen IP) loggen.
Daher habe ich zwei Fragen:
1) Kann ich das Bridge-Netzwerk in Docker beibehalten und die Zugriffe nur mit dem NAS „vorab“ irgendwie loggen?
2) Wenn ich auf den Host-Modus in Docker umstelle, muss ich „sicherheitstechnisch“ etwas beachten? Und benötige ich sonst noch weitere Dienste?
Vielen Dank für die Unterstützung.

Gruß Habak

 

[Ulfhednir]

Wenn du den Host-Modus betreibst, musst du halt dafür Sorge tragen, dass sich kein Port des Hosts bzw. deiner Diskstation mit dem Container beißt.
Der elegante Weg wäre daher natürlich der von haydibe beschriebene MACVLAN. Um das Umzusetzen kannst du auf Portainer zurückgreifen, da die Docker-GUI der Diskstation stark beschnitten ist.

 

[Habak1]

Hallo,

vielen Dank für die Hinweise.
Ich habe mal den Host-Modus mit einem Container ausprobiert (über ssh und docker-compose), was auch läuft. Für MACVLAN habe ich leider nicht genügend fundiertes Grundwissen.

Jetzt bin ich zufällig noch über folgenden Beitrag gestolpert, bei dem es scheinbar auch im bridge-Modus möglich wäre, wenn man den NGINX des NAS etwas erweitert: Über den letzten Beitrag in diesem Post kommt man zu einem Lösungsvorschlag.

Was ist davon bitte zu halten?

Vielen Dank für Eure Unterstützung.

Gruß Habak

 

[haydibe]

Schau dir mal mit den Dev-Tools deines Browsers an, welche diese Standard-Header Traefik eigenständig ergänzt. Die Ziel-Anwendung muss aber auch die entsprechenden Mechanismen implementiert haben, damit die Werte aus den Headern stattdessen als "Real-Ip" angesehen werden. Das ist Standard-Handwerk im Umgang mit Reverse-Proxies. Diese Header willst Du so oder so haben, egal mit welcher Netzwerk-Art (selbst wenn Du das ganze auf Blech ohne Container betreiben würdest).

Würde mich wundern, wenn es mit dem Bridge-Netzwerk tatsächlich die Lösung wäre. Ausprobieren.

 

[Habak1]

Also, ich habe es nicht hinbekommen. Man sieht immer nur die 172.0……als IP.
Was ich prinzipiell nicht verstehe, wie Systeme mit zig Docker-Containern, die über das Web ansprechbar sind, abgesichert sind (z.B. IP‘s sperren), wenn man beim Access-Logging immer nur die Docker-interne IP sieht?
Nochmals Danke für die Unterstützung.

 

[haydibe]

..., wenn man beim Access-Logging immer nur die Docker-interne IP sieht?

Das mag Deiner Erfahrung entsprechen, ist faktisch aber nicht korrekt. Wenn das Host-Netzwerk oder ein MACVLAN-Netzwerk verwendet wird, ist das Verhalten diesbezüglich im Docker-Container identisch zu einem Reverse-Proxy der nicht auf Docker läuft.

Das ein Reverse-Proxy die Quell-IP mit seiner eigene IP ersetzt ist nichts neues und hat nichts mit Docker zu tun. Das Verhalten gab es bei Reverse-Proxies auch schon, da defacto der Reverse-Proxy mit dem Ziel kommuniziert und nicht die ursprüngliche Quell-IP. Das war schon lange vor Docker so und die anzuwendenden Lösungen haben sich seit Docker nicht verändert. Nur beim Bridge und Overlay-Netzwerk gibt es eine "Docker Eigenheit". Schon damals war die Lösung die Information in standardisierte Headern an das Zielsystem durchzuschleifen und die Anwendungen entsprechend so zu bauen, dass sie die Information auch nutzen um daraus die Quell-IP zu übernehmen.

Der Syno-Rp legte folgende Header an (nginx configuration):

proxy_set_header        Host               $http_host;
proxy_set_header        X-Real-IP          $remote_addr;
proxy_set_header        X-Forwarded-For    $proxy_add_x_forwarded_for;
proxy_set_header        X-Forwarded-Proto  $scheme;

Bei allem, wo Du mit dem Syno-RP das Problem durch diese Standardmäßig für alle Einträge gesetzte Konfiguration nicht hast, kannst Du das Problem auch bei Docker Containern mit welchem Reverse Proxy auch immer auf dieselbe Art lösen - nur muss man dann herausfinden wo und wie diese Header gesetzt werden müssen(falls sie nicht automatisch gesetzt werden!). Wenn man weitere LBs/Reverse Proxies in der Kette davor hat, kann es passieren, dass deren X-Header durch Traefik nicht übernommen werden, weil man die Einstellung zu übernehmen vorhandener X-Header nicht gesetzt hat.

 

[Habak1]

Vielen Dank, meine Aussage bezieht sich auf das Bridge-Netzwerk und nicht allgemein auf Docker.

 

[haydibe]

In dem Kontext ergibt die Aussage dann wieder Sinn.

Was man noch versuchen könnte:
siehe: https://doc.traefik.io/traefik/routing/entrypoints/#forwarded-headers
Vielleicht setzt Docker selbst ja auch schon den Forwarded-For Header und Treafik verwirft ihn, weil die Einstellung nicht gesetzt ist.

Auch hier: würde mich wundern, wenn es funktioniert... aber was wenn doch...

 

[Habak1]

Danke für den Tipp. Das habe ich leider schon erfolglos ausprobiert.

 

[Habak1]

Ich habe da noch eine allgemeine Verständnisfrage, die mich umtreibt (weil ich an sich nur wissen möchte, wer auf meine Seiten zugreift):
Nach meinem momentanen Wissenstand ist doch der NAS-eigene-nginx-proxy derjenige, der die Requests als erstes annimmt (Apache habe ich nicht installiert). Und von dort „geht es weiter“ zu docker, reverse-proxy, usw..
Warum kann man nicht da schon „access“-loggen, denn dort weiß man doch „wer“(IP) will „wohin“(url)?
Vielen Dank ?

 

[haydibe]

Ernsthaft, der Traffic läuft DURCH den Syno-RP an den Traefik-Container?!
Wenn dem wirklich so ist, dann hätte zwingend das in den ersten Post gehört.

Das wegzulassen legt die komplett falsche Fährte...
Ich hoffe das Dir jemand anderes weiterhelfen kann. Viel Erfolg!

 

[Habak1]

Das ist eine Frage und keine Feststellung. Ich würde gerne verstehen, wie ein request “weitergereicht“ wird. Vom Router direkt in Docker wird es ja kaum sein.