docker macvlan - Port Mapping möglich?

[Krik]

Moin zusammen,

ich habe mein NAS (Ugreen DXP2800) auf Werkszustand zurückgesetzt, nachdem ich es geschafft habe, die Lese-/Schreibrechte der User völlig kaputt zu machen.

Ich habe jetzt meine Docker-Container wieder reaktiviert. Im Gegensatz zu früher verwende ich nun macvlan. Das führt dazu, dass das Port Mapping natürlich nicht mehr läuft, da die Container jetzt nicht mehr hinter den Ports sondern hinter den IPs hängen.

Beispiel Komga
(was Jellyfin für Videos ist, ist Komga für eBooks und Mangas)

services:
  komga:
    image: gotson/komga
    container_name: komga
    volumes:
      - /volume1/docker/komga/config:/config
      - /volume1/docker/komga/data:/data
      - /volume1/Lesestoff:/mnt/Lesestoff
      - /etc/timezone:/etc/timezone:read_only
    #ports:
    #  - 80:25600
    restart: unless-stopped
    networks:
      macvlan:
        ipv4_address: 10.0.0.246

networks:
  macvlan:
    external: true
    name: macvlan

Die Anwendung klinkt sich standardmäßig hinter Port 25600. Ich hätte jetzt gerne aber eine Umleitung von 80 auf 25600.
Kann man das hier irgendwie bewerkstelligen? Oder geht das dann mit docker in diesem Fall schlicht nicht?

Gruß
Krik

 

[0x8100]

die konfig der anwendung ändern, so dass sie auf port 80 statt 25600 lauscht. alternativ das ganze hinter einen reverse proxy packen.

 

[Krik]

Da hätte ich auch selber drauf kommen können.


Was macht man mit Services, die einem nicht erlauben, den Port zu ändern? Ich habe den Fall bspw. bei Linkwarden.
Geht das dann nur noch über einen Reverse Proxy oder gibt es noch andere Alternativen? So ein Proxy ist irgendwie overkill.

 

[und tschüss]

Ich würde Macvlan nur sehr bedacht einsetzen und lieber das Bridge-Netzwerk und einen Reverse-Proxy vorziehen. Macvlan hat ja bekanntlich ein Verbindungsproblem zum Host, was aber kein Fehler ist, sondern ein Sicherheitsfeature. Es gibt sehr wenige Anwendungen und Fälle, in denen ein Macvlan wirklich sinnvoll sein kann. Dazu hast du noch das SSL-Problem und musst das Zertifikat in jeden Container kopieren. Willst du alle deine Container in Macvlan integrieren und warum?

 

[0x8100]

So ein Proxy ist irgendwie overkill.

warum? das kann ein einfacher nginx sein mit 10 zeilen konfig pro service. hat den vorteil, dass der die verschlüsselung abschliessen kann und jeder service automatisch per https erreichbar ist.

 

[und tschüss]

das kann ein einfacher nginx sein mit 10 zeilen konfig pro service

Muss noch nicht einmal manuell angelegt werden. Einfach den Nginx Proxy Manager in Docker installieren und alles entspannt über die GUI einrichten, inkl. Zertifikate. Ich nutze für die Verbindung intern und extern die gleiche URL incl. SSL. Viele Dienste sind aber nur intern zugelassen. Auf den Port-Blödsinn verzichte ich vollkommen und spreche alle Dienste mit einer Subdomain an, z. B. linkwarden.krik.tld. Das funktioniert sowohl mit einer eigenen Domain als auch mit einer DynDNS, mit und ohne Portfreigaben über die API.

 

[0x8100]

Muss noch nicht einmal manuell angelegt werden.

ich weiss, aber da der nginx hier nicht nur reverse proxy ist, lasse ich einfach den vorhandenen das mitmachen.

 

[Krik]

Willst du alle deine Container in Macvlan integrieren und warum?

Ja. Warum? Ich mag es, wenn jeder Dienst seine eigene IP hat. Ist einfach so.

Darüber hinaus gibt es noch das Problem, dass Adguard Home mit dem NAS Probleme hat. Das NAS belegt bereits Port 53, das Adguard auch haben will. Man kann jetzt natürlich mit ssh und systemctl den dnsmasq-Dienst im NAS ausschalten, aber beim nächsten Systemupdate (monatlich) wird der wieder automatisch reaktiviert. Man rennt der Sache hinterher und die einzig dauerhafte Lösung ist hier macvlan.

warum?

Noch ein Dienst. Und irgendwie ist das mit Kanonen auf Spatzen schießen. So kommt mir das jedenfalls vor. ^^

Ich werde mir den Nginx Reverse Proxy vielleicht noch mal anschauen. In der Vergangenheit habe ich damit schon etwas experimentiert, aber fand die Konfiguration irgendwie schwierig. Mir fehlt da wahrscheinlich einfach noch etwas Basiswissen.
Dieses Video ist mir bereits bekannt. Darin wird alles im Detail besprochen.

 

[und tschüss]

Das NAS belegt bereits Port 53, das Adguard auch haben will.

Ich habe ja bereits geschrieben:

Es gibt sehr wenige Anwendungen und Fälle, in denen ein Macvlan wirklich sinnvoll sein kann.

Für mich ist das aber nicht der richtige Weg. Ich kann nicht sagen, wie oft ich den Support von Ugreen schon auf den Port 53 angeschrieben habe. Für mich ist es ein Fehler, dnsmasq bzw. den DHCP-Server dauerhaft zu aktivieren, gerade wenn schon ein Server im Netzwerk aktiv ist. Da hilft nur, wenn viele User das gleiche Problem auch melden. Umso mehr, desto besser! Mehrere Diskussionen diesbezüglich findet man ja im Netz.

Macvlan ist nicht für Anfänger und das sollte auch klar kommuniziert werden. Hebelt man das Sicherheitsfeature über ein weiteres Bridge-Netzwerk aus, geht der Sinn dahinter verloren. Das heißt nicht, dass du ein Anfänger bist, aber es könnte bei anderen Usern der Eindruck erweckt werden, dass dies die ultimative Lösung ist.

Es hindert dich keiner, das System so einzurichten, nur muss man sich der möglichen Folgen bewusst sein. Ich kann mir nicht vorstellen, dass du damit langfristig glücklich wirst.

In der Vergangenheit habe ich damit schon etwas experimentiert, aber fand die Konfiguration irgendwie schwierig.

Noch einfacher geht es nicht mehr. Letztendlich weist du ja nur eine Adresse, eine URL zu. Eine Anleitung muss man dafür nicht haben. Es gibt noch weitere Reverse-Proxys, welche wesentlich umständlicher sind. Ein Großteil davon wird nur über Configs eingerichtet. Der Nginx Reverse Proxy ist schon wirklich der einfachste und selbsterklärendste Service. Ob du jetzt in den einen Container über das Compose-File lädst, macht das System doch nicht zugemüllter. Eine Datenbank brauchst du dafür nicht und es reicht, die SQLite vollkommen aus. Im Gegensatz zu Synology und Co. bietet Ugreen keinen Reverse Proxy in den Einstellungen. Allerdings sind die Hersteller-Umsetzungen auch nur das Wesentliche. Wenn du bestimmte Einstellungen vornehmen willst, wird es auch kompliziert. Das macht NPM deutlich besser und es gibt viele Beispiele, z. B. für Vaultwarden, wenn mehr über die übliche Weiterleitung konfiguriert werden soll z. B. nur im internen Netz trotz externer Freigabe.

 

[Uridium]

Was macht man mit Services, die einem nicht erlauben, den Port zu ändern? Ich habe den Fall bspw. bei Linkwarden.
Geht das dann nur noch über einen Reverse Proxy oder gibt es noch andere Alternativen? So ein Proxy ist irgendwie overkill.

Sehe ich ähnlich und werfe 'port redirection' in den Raum.

# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080