[Frage] [V4.0.1] Einrichtung von MacVLAN - Detailfragen

[speckenbuettel]

Hallo Yves,

Sofern man ein Image so verwendet, wie es von dessen Entwicklern vorgesehen ist, braucht es auf Seite TW nicht wirklich viele Settings.

Vielen Dank - auf den ersten Blick sieht das recht einfach aus und ich habe es auch schon versucht, nur leider klappt es nicht.

Zunächst mal eine Verständnisfrage: du hast in deinem Screenshot unter Zieladresse nach dem Port noch mal die Teil-URL "/proxy/..." angegeben. Ist das so richtig und funktioniert das bei dir? Bei mir nämlich nicht.

Ich habe eine Container für den Onwtracks-Recorder laufen (ich benutze OwnTracks in Verbindung mit MQTT für die Anwesenheitskontrolle - das ganze Projekt stelle ich hier noch ausführlich vor sobald ich Zeit dazu finde und es auch bei mir rund und zuverlässig läuft).
In Portainer sieht das so aus:



Über die URL https://<timberwolf>:8083 kann ich die Webseite des Recorders ohne Probleme aufrufen, auch die Links darin funktionieren.

Wenn ich den Reverse Proxy im TWS wie folgt einrichte, dann kann ich über die URL http://<timberwolf>/proxy/owntracks (ohne s, mit s funktioniert es nicht) immerhin die Startseite des Recorders aufrufen, die Links auf dieser Seite laufen aber ins Leere und es gibt 404-Fehler.


Wenn ich den Revers Proxy so konfiguriere:


dann führt schon der Aufruf der URL http://<timberwolf>/proxy/owntracks zur Fehlermeldung 404 - Not found.

Siehst du auf den ersten Blick einen Fehler?

Vielen Dank und viele Grüße
Falk

[starwarsfan]

Hallo Jochen

dafür kann (oder besser: sollte) man ja den schon auf dem TWS vorhandenen Portainer nehmen, mit dem du für jeden Container ja auch einen RevProxy konfigurieren kannst.

Das hätte ich gern etwas genauer erklärt.

[starwarsfan]

Hallo Falk

Zunächst mal eine Verständnisfrage: du hast in deinem Screenshot unter Zieladresse nach dem Port noch mal die Teil-URL "/proxy/..." angegeben. Ist das so richtig und funktioniert das bei dir? Bei mir nämlich nicht.

Ja, das tut es.

Über die URL https://<timberwolf>:8083 kann ich die Webseite des Recorders ohne Probleme aufrufen, auch die Links darin funktionieren.

Wenn ich den Reverse Proxy im TWS wie folgt einrichte, dann kann ich über die URL http://<timberwolf>/proxy/owntracks (ohne s, mit s funktioniert es nicht) immerhin die Startseite des Recorders aufrufen, die Links auf dieser Seite laufen aber ins Leere und es gibt 404-Fehler.

Das Problem resp. die Herausforderung ist in so einem Fall, wie die jeweilige Applikation im Container mit den übermittelten RequestURIs umgeht bzw. ob sie damit überhaupt umgehen kann. Sprich, im Fall der Prometheus-Instanz auf meinem Screenshot muss es explizit so konfiguriert werden, wobei ich jetzt aus dem Stehgreif nicht sagen kann, ob/was ich da an Prometheus an und für sich geändert habe bzw. ändern musste. Das ist zu lange her.

Allgemeingültig kann ich das auf die Schnelle nicht erklären aber in einfachen Worten geht es darum, dass die Applikation im Container wissen muss, wie sie mit der RequestURI des eingehenden WebRequest umgehen muss. Sprich, die Applikation muss aus den RequestURIs der eingehenden Requests gültige Referenzen generieren können, damit weiterführende Links/Requests/etc funktionieren.

Wie das nun geht, ist für jede Applikation anders. Bei gitea bspw. muss die BasisURL explizit konfiguriert werden, damit alles weitere korrekt funktioniert. Hier kommt man dann zwangsläufig zu dem Problem, dass i.d.R. nur ein Zugriffspfad sauber konfiguriert werden kann.

[jhaeberle]

Hallo Yves,

Das hätte ich gern etwas genauer erklärt.

Wenn du einen Container anlegst, kannst du Port-Mappings erstellen.



Das kann man bestimmt auch nachträglich noch ändern, aber das hab ich grad nicht gefunden…

Alternativ oder vlt noch besser wäre Traefik, ein Container, der für's Proxying gemacht ist, aber den hab ich noch nicht zum Laufen gebracht… Ist bei mir was länger her, da war in Kreisen state-of-the-art, Portainer mit Watchtower und Traefik laufen zu lassen. Zumindest Watchtower geht auf dem TWS schon mal nicht… und der https-Port 443 ist auch schon belegt, was unschön ist. Wäre vielleicht ein schöner, hilfreicher Ansatz, wenn das von Haus aus so konfiguriert so käme, dann könnte der TWS hinter dem Traefik laufen, aber da können wir nix dran machen, denk' ich…

Gruß
Jochen

Edit: Traefik weiter ausgeführt…

[starwarsfan]

Hallo Jochen

Wenn du einen Container anlegst, kannst du Port-Mappings erstellen.

Sorry, aber das hat mit ReverseProxy überhaupt gar nichts zu tun! Genau darum geht es ja hier, dass es bei der Verwendung von MacVLAN eben diese Mappings nicht funktionieren, weil der Container aus Netz-Sicht ein eigenständiger Host mit eigener IP ist. Damit sind alle Ports direkt ansprechbar.

Natürlich könnte man einen Container _ohne_ MacVLAN so starten, dass er bspw. den Port 80 auf 8080 mappt. Dann braucht man in der Konfiguration des TW-ReverseProxy den Port 8080 nicht angeben, weil der ReverseProxy auf Port 80 des Containers weiterleitet und beim Übergang vom Host-Netz Port 80 ins Docker-Netz Port 8080 das Mapping vom Docker-Daemon gemacht wird. Aber IMHO macht man es sich damit nur unnötig schwer bzw. ist soetwas nur dann notwendig, wenn man mehrere Instanzen der gleichen Applikation nebeneinander betreiben will.

[jhaeberle]

Hey Yves,

Sorry, aber das hat mit ReverseProxy überhaupt gar nichts zu tun! Genau darum geht es ja hier, dass es bei der Verwendung von MacVLAN eben diese Mappings nicht funktionieren, weil der Container aus Netz-Sicht ein eigenständiger Host mit eigener IP ist. Damit sind alle Ports direkt ansprechbar.

das Portmapping im Portainer funktioniert, ob das Netzwerk bridged ist oder MacVlan. Eher ist IMHO die Frage, ob du lieber im TW-ReverseProxy eine Pfad-URL erzeugst oder per MacVlan einen neuen Host im lokalen Netz. Beide Ansätze dienen dazu, die internen Ports los zu werden/zu verstecken.

Sie teilen sich auch die Probleme mit der URL-Generierung, wenn man das erst mal am Start hat und die Hauptseite ausgeliefert ist. Das hast du ja auch schon (in diesem Thread?!??) angesprochen.

Gruß
Jochen

[speckenbuettel]

Hallo Yves,

Das Problem resp. die Herausforderung ist in so einem Fall, wie die jeweilige Applikation im Container mit den übermittelten RequestURIs umgeht bzw. ob sie damit überhaupt umgehen kann.

danke für deine Erläuterung. Damit sind wir ja wieder bei dem Punkt, den Göran und Stefan schon angesprochen haben: MacVLAN ist die einfachste Art, Container auch „laienbedienbar“ zu machen, ohne allzu tief in die Netzwerkkonfiguration oder die Konfiguration der jeweiligen Container einsteigen zu müssen.

Bis ich Zeit und Muße habe, mich damit zu beschäftigen laufe ich lieber auf der Krücke umher

Aber alles in allem eine interessante Diskussion!

Viele Grüße
Falk

[starwarsfan]

Hallo Jochen

das Portmapping im Portainer funktioniert, ob das Netzwerk bridged ist oder MacVlan. Eher ist IMHO die Frage, ob du lieber im TW-ReverseProxy eine Pfad-URL erzeugst oder per MacVlan einen neuen Host im lokalen Netz. Beide Ansätze dienen dazu, die internen Ports los zu werden/zu verstecken.

Völlig klar.

Ich habe aber nachgefragt, weil Du geschrieben hast, dass man direkt in Portainer einen ReverseProxy konfigurieren könnte, was mir gänzlich neu wäre. Mittlerweile hat sich aber gezeigt, dass Du lediglich von Portmappings sprichst und eben genau das hat mit dem was ein ReverseProxy macht nichts zu tun. Ausser vielleicht dem Feature, von Quellport A auf Zielport B zu routen, ok...

[jhaeberle]

Hi Yves,

Ich habe aber nachgefragt, weil Du geschrieben hast, dass man direkt in Portainer einen ReverseProxy konfigurieren könnte, was mir gänzlich neu wäre. Mittlerweile hat sich aber gezeigt, dass Du lediglich von Portmappings sprichst und eben genau das hat mit dem was ein ReverseProxy macht nichts zu tun. Ausser vielleicht dem Feature, von Quellport A auf Zielport B zu routen, ok...

ok. Aber viel mehr kannst du im TWS-Kontext und dem da verfügbaren Reverse Proxy doch auch nicht machen… Auf die ganzen höherwertigen Funktionen hast du hier doch auch keinen Zugriff, oder?
Ok, die TWS Authentifizierung und das SSL-Zert, dass seine eigenen… Herausforderungen mitbringt

Gruß
Jochen

[gbglace]

Da ich es bei mir auch noch nie zum laufen bekommen habe irgendeinen Service des TWS mit einem URL-Namen aufzurufen, benutze ich durchweg nur die IP-Adressen. Und da habe ich dann einfach 225 >> TWS, 226 SSH, 227 MQTT Broker, 228 NR, 229 HA. Und dann eben die Ports noch hinten dran. Und dann steckt das alles einfach in Lesezeichen im Browser.

Ja alles nicht schön und sauber aber es funktioniert für mich.

Für jemand anderen sowas sauber einrichten, keine Ahnung von. Auch nach mittlerweile drei Handy-Wechseln zu Lebzeiten des TWS habe ich es auch noch nicht hinbekommen nicht immer die Warung zu erhalten, hey das ist jetzt aber keine sichere Seite. Bei dem einen alten PC hatte ich das mit den DNS mal irgendwo hart in eine Konfiguration getippt. aber Zielführend ist das ja auch nicht. Aber das ist gaube auch alles wieder etwas anderes an der Netzwerktechnik.