Hallo Jürgen, das ist bisher das beste Video, dass ich über traefik gesehen habe, wirklich sehr gut aufgebaut und einfach erklärt. Ich habe jetzt beides einmal eingerichtet und stimme mit deinem Kommentar 100% überein: "Nginx Proxy Manager ist hingegen einfacher zu bedienen und kann für weniger komplexe Anwendungsfälle ausreichend sein."
Moin Jürgen, danke für dieses Video. Jetzt habe auch ich Traefik verstanden ;) Es hat mich aber auch zu dem Entschluss gebracht, weiterhin bei NPM und der Container-Adressierung über MacVLAN zu bleiben. Dank deiner vorherigen Videos habe ich mich so sehr an die Vorgehensweise gewöhnt, dass ich das als sehr viel einfacher empfinde. Aber alles ist natürlich Geschmackssache und ich kenne auch viele Leute, die auf Traefik schwören. PS: Solltest du mal Ausschau nach einem neuen Projekt halten: Schau doch bitte einmal, ob du Crowdsec auf der Synology installiert bekommst. Ich selbst habe das nicht geschafft, habe deshalb Crowdsec und NPM auf einem separaten Linux-Server installiert. Grüße - Werner -
Lieber Jürgen, ein GROßARTIGES und EINZIGARTIGES Video - einfach Spitze!👍 Sicherlich wolltest du deine Zuschauer noch testen, indem du über eine Route (to-pihole-1) einen Service (pihole2) ansprichst ... 😜
Vielen Dank für das super Tutorial! Traefik läuft und alles bisher sehr stabil. Das einzige Problem was ich habe ist dass ich nicht mehr zurück auf die Synology komme. Habe zwar den Workaraound mit der Route eingerichtet allerdings bekomme ich keine Verbindung zur DSM. Was mich aber auch noch irritiert sind die Fehler im Log von Traefik welche darauf hinweisen dass die Ports 80 und 443 blockiert wären. Denke aber das sind die vom Proxy? Zumindest läuft Traefik mit Container wie es soll... Vielleicht doch irgendwas falsch gemacht?
Traefik ist wirklich genial! Danke für die Videoreihe. Funktioniert bei mir auch alles super. HTTPS-Verbindungen mit Let's Encrypt läuft ebenfalls. Allerdings sagt mein Browser immer noch, dass die Verbindung unsicher wäre. Hab das auf verschiedenen Rechnern ausprobiert. Ist das normal, oder habe ich was übersehen? LG 👋
@@Navigio1 Sorry, wie dumm von mir. Natürlich, war ich noch im Testmodus. 🙈 Daran hab ich gar nicht mehr gedacht. Vielen Dank für den Tipp! Jetzt funktioniert alles, wie es soll. 👍
Tolles Video, super erklärt. Ich habe aber ein technisches Problem in meinem Setup und vielleicht hast Du eine Idee woran das liegen könnte (Netzwerk/Interfaces). Ich habe auf dem Synology NAS eine VM mit Ubuntu 24.04. auf dem Synology LAN2 Interface mit einer IP-Adresse aus dem LAN2 (10.82.0.0/24). Das ist meine DMZ. Dort läuft Traefik, auf dem Ubuntu. Das LAN1 Interface der Synology hängt hinter einer Firewall im Netz 10.82.1.0/24, darüber ist das DSM-Webinterface erreichbar. Wenn ich nun Traefik einen Router gebe um auf Systeme hinter der Firewall (die nicht auf der Synology laufen) zuzugreifen klappt das wunderbar (FW-Regeln eingerichtet), genau so soll es ja sein (Reverse Proxy in der DMZ). Was nicht klappt ist wenn ich mit einem Router versuche Dienste auf der Synology über Traefik erreichbar zu machen (z.B. DSM-Webinterface). Dann bekomme ich immer eine "Bad Gateway" Meldung im Browser. Ich vermute das liegt daran dass Traefik auf einer VM auf dem gleichen Synology läuft und ich ggf. das LAN-Interface auf Promiscous ändern müsste, bin mir da aber eher unsicher und direkt angeboten wird Promiscous auch nicht (z.B. im VMM). Hast Du eine Idee warum ich über Traefik (auf einer VM auf dem Synology laufend) nicht die Synology selbst erreichen kann? FW-Regeln passen. Auch ein Login auf dem Traefik Container (Shell) und Ping auf die Synology IP funktioniert, ebenso wie ein netcat auf Port 5000 liefert "open", also sollte netzwerktechnisch das ja kein Problem sein, dass Traefik das DSM-Interface erreicht. Ich weiss aber grad nicht mehr weiter.
Das liegt daran, dass man vom Container nicht mit dem Docker Host und umgekehrt kommunizieren kann. Schau Dir mein macvlan Video an, da erkläre ich das Workaround!
Danke Jürgen, schaue ich mir nochmal an. Da ich ja nicht Docker der Synology sondern ein eigenes Docker in einer Ubuntu VM auf dem Synology nutze, hatte ich nicht damit gerechnet, dass der Effekt der Gleiche ist. Zumal ich ja aus der Traefik-Shell per ping und netcat die Dienste der Synology erreiche … aber vielleicht löst MacVlan das Problem ja auf.
Hi - wirklich gutes Video - hast du es mit deiner UDM hinbekommen? Wenn ich es so mache wie du mit deinem pihole klappt das bei mir nicht / mein pihole geht aber die udm will nicht 😢
Moin Jürgen, vielleicht ein Thema wo du etwas "deeper diggen" kannst: Wenn ich versuche aus meinen Containern (die über macvlan in meinem ganz normalen Netz hängen) meine Syno als Host zu pingen (beispielsweise vom Container auf der 192.168.178.200 die Syno auf 192.168.178.7) geht das nicht. Andere Hosts, wie der Router auf der .1 gehen. Hängt laut Google an macvlan, es gibt aber workarounds, die sich mir allerdings entziehen.
@@Navigio1 Danke! Aber brauche ich den Sonology-Proxy immer? Der Traefik soll ja mein RP sein und DNS habe ich woanders. Der Docker Container (bzw Portainer Oberfläche) ist halt auf der Synology sonst hat das ja nichts miteinander zu tun.
Was die Einrichtung angeht ,ist Traefik absolut uninteressant gegenüber einen Engix Proxy Manager. Kann mir jemand sagen, welche Vorteile Traefik bietet ?
Hier sind einige der Vorteile von Traefik im Vergleich zu Nginx Proxy Manager: 1. **Automatisierte Konfiguration**: - **Traefik**: Traefik ist bekannt für seine dynamische Konfiguration. Es kann automatisch Dienste erkennen und konfigurieren, indem es direkt mit Container-Orchestrierungstools wie Docker, Kubernetes, und anderen Integrationen arbeitet. Dies macht es besonders nützlich in Umgebungen, in denen sich die Infrastruktur oft ändert. - **Nginx Proxy Manager**: Nginx Proxy Manager erfordert oft manuelle Konfiguration oder Skripte, um ähnliche dynamische Anpassungen zu ermöglichen. 2. **Eingebaute Unterstützung für Let’s Encrypt**: - **Traefik**: Traefik bietet native Unterstützung für Let’s Encrypt und kann SSL-Zertifikate automatisch erstellen und erneuern. Dies vereinfacht die Verwaltung von HTTPS erheblich. - **Nginx Proxy Manager**: Nginx Proxy Manager unterstützt auch Let’s Encrypt, aber die Integration und Verwaltung ist nicht so nahtlos wie bei Traefik. 3. **Erweiterte Routing-Funktionen**: - **Traefik**: Traefik bietet fortschrittliche Routing-Möglichkeiten, einschließlich Pfad- und Header-basiertem Routing, und unterstützt moderne Protokolle wie HTTP/2 und gRPC. - **Nginx Proxy Manager**: Während Nginx Proxy Manager grundlegende Routing-Funktionen bietet, fehlen ihm einige der fortschrittlicheren Features von Traefik. 4. **Integrierte Metriken und Monitoring**: - **Traefik**: Traefik hat eingebaute Metriken und Monitoring-Tools, die einfach in Systeme wie Prometheus integriert werden können. Dies erleichtert das Überwachen und Analysieren des Traffics und der Leistung. - **Nginx Proxy Manager**: Nginx Proxy Manager bietet grundlegende Überwachungsfunktionen, aber für detailliertere Metriken und Analysen sind zusätzliche Tools und Konfigurationen erforderlich. 5. **Erweiterbarkeit und Plugins**: - **Traefik**: Traefik ist modular aufgebaut und unterstützt eine Vielzahl von Plugins, die die Funktionalität erweitern können, wie Authentifizierung, Rate Limiting und vieles mehr. - **Nginx Proxy Manager**: Nginx Proxy Manager ist weniger modular und bietet weniger Möglichkeiten zur Erweiterung durch Plugins. 6. **Community und Support**: - **Traefik**: Traefik hat eine aktive Community und wird ständig weiterentwickelt. Es gibt umfangreiche Dokumentation und Support sowohl durch die Community als auch durch kommerzielle Angebote von Traefik Labs. - **Nginx Proxy Manager**: Nginx Proxy Manager hat ebenfalls eine Community, aber sie ist kleiner im Vergleich zu Traefik. Die Entwicklung und der Support sind daher möglicherweise weniger umfangreich. Zusammengefasst bietet Traefik viele Vorteile, insbesondere für dynamische und komplexe Umgebungen, in denen automatische Konfiguration, erweiterte Routing-Funktionen und integrierte Monitoring-Tools wichtig sind. Nginx Proxy Manager ist hingegen einfacher zu bedienen und kann für weniger komplexe Anwendungsfälle ausreichend sein.
@@Navigio1 Ich werde das nun konkret an meinem Netzwerk erläutern sodass man hier mehr Berührungspunkte hat. Ich betreibe eine OPNsense mit verschiedenen VLANs, die Netzwerkinfrastruktur geht dahingehend weiter über Omada für WLAN-AP und Switches. Dahinter sind verschiedene Geräte wie der eigentliche HomeServer (und weitere Geräte wie ein HA). Diese Geräte nutzen alle eine lokale Domain welche mittels Unbound der OPNsense überschrieben werden mit ".homeserver". Da ".homeserver" zum damaligen Zeitpunkt kieine TLD bzw. tLD war wie z.B. ".local" war es nicht möglich eine Domain zu kaufen. Ebenfalls haben die Geräte nur beschränkten Zugriff nach Außen und natürlich Außenrum, wofür auch, bis auf Updates passiert da nichts. Ein Zugriff selbst kann sowieso NUR mittels VPN oder Direktverbindung erfolgen. LE hätte max. mit einer DNS-Challange die Möglichkeit zu renewen bzw. erstmal zu erstellen. Ich müsste die Verbindung immer offen lassen. Da meine Daten sehr privat sind und neben privaten Daten auch Forschungsdaten erhalten darf niemals was an die Öffentlichkeit kommen. Ich habe eine Festung aufgebaut um alles privat zu halten, man muss mich totschlagen und Direktzugriff nehmen, wenn man wirklich an die Daten dran möchte. Also für mich macht es dahingehend Sinn das ich nicht abhängig von anderen sein will, ein privates-internes Netzwerk habe was nicht einfach so ein Zertifikat anfragen kann und ein self-signed bereits seit immer ausgerollt wird und das rootCA soweit in allen Geräte vorhanden ist welche ich nutze. Ein Import eines rootCAs ist schon lange nicht mehr schwierig sodass man die Qualität der Server ohne Probleme verifizieren kann (was Windows/Linux und Apple-Produkte anbelangt, Android... auch wenn es ein modifiziertes Linux ist, haat dennoch Probleme mit meinem self-signed, aber ich nutze bei mir schon seit Jahrzehnten kein Android mehr und "Besuch" hat sowieso durch die Trennung der Netzwerke keine Möglichkeit auf die internen Netzwerke zu-zugreifen) - Ich hoffe ich konnte die Problematik einmal aufzeigen und den Grund, warum das ganze so gewählt wurde, wie es aktuell bei mir vorliegt.
Hier sei anzumerken das die Netzwerkstktur und Technik sehr stark vereinfacht wurde, manche Anwendungen TLS erzwingen und das ich alle 3 Monate den Zugriff nach außen nur offen legen müsste, das dann mittels Script oder Manuell, also müsste ich die Verbindung nicht zwangsweise immer offen lassen.
