reverse proxy vm image

  • Hallo zusammen,


    ich habe nunmehr an mehreren Baustellen festgestellt, dass ich für die Anwendungen, für die ich mein QNAP-System einsetzen möchte, ein reverse proxy wohl die sicherste und beste Lösung sein wird. Ich möchte eine owncloud/nextcloud-App von einem anderen System auf QNAP umziehen (auch wenn die OwnCloud-App mit dem letzten QTS-Update wegen PHP7 gerade runtergeflogen ist), dazu läuft auf dem QNAP ein Plex Mediaserver und ich möchte jitsi meet sinnvoll nutzen. Derzeit läuft das jitsi bei mir in einem LXC mit anderen Ports und ich hab im Router ein port mapping nach draußen, dass für die Welt die Standard ports gelten, in meinem LAN andere Ports laufen, die dann durch das port mapping der Container Station wieder zurückgebaut werden zu den Standartwerten für https und http. Dieser Workaround (weil ich die standard-ports für https und http des QTS nicht ändern will) ist insofern unschön, dass ich im LAN nun jitisi nur mit manueller Port-Angabe nutzen kann, außerhalb aber dann wieder ganz normal. Das nervt. Zudem ist es mir zu unsicher, den traffic so ungefiltert durch den port auf den Container loszulassen und zu hoffen, dass ich dort die Firewall sauber konfiguriert ist. Die von Plex und die von OwnCloud (was bald Nextcloud werden soll) ebenfalls. Kurz, zu viele Apps und Baustellen, die potentiell unsicher sind.


    Daher ist mein plan, eine linux-vm (weil eigene IP-Adresse) aufzusetzen (Debian weil frei), mit nginx als reverse proxy auszustatten und, wenn mich der Hafer sticht, ein Web Frontend dazu. Aber auch ohne letzteres soll der nginx mit sauberen let's encrypt Zertifikaten ausgestattet den ganzen Traffic für alle Apps sauber routen und mit vernünftiger Firewall für mehr Sicherheit sorgen. diese VM kann dann in die DMZ und sich selbst um den traffic aus dem WAN kümmern. Dank vhost könnte ich dann ja auch den Port 443 mehrfach nutzen und entsprechend an die Applikationen in meinem LAN, eine Domain und subdomains mit A oder CNAME DNS Einträge habe ich. also z.B. nas.example.com für das qts, plex.example.com für Plex, cloud.example.com, meet.example.com für Jitsi etc. Und weil ich den DNS in meinem LAN eh schon voll kontrolliere, kann ich dort auch lokale DNS-Einträge für diese subdomains anlegen (was ich jetzt schon mache), um die interne Verwendung ohne Eingabe der IP-Adressen zu ermöglichen.


    Meine erste Frage: Klingt das vernünftig und machbar soweit oder steh ich irgendwo auf dem autodidaktischen Schlauch?

    Nun habe ich die Anleitungen hier im :qclub: gesehen, die aber oftmals ganz andere Ansätze verfolgen und auch das QTS web interface torpedieren, was ich nicht will. Daher meine zweite Frage: Gibt es vielleicht ein out-of-the-box nginx image, was soweit schon abgesichert und, ich sag mal, sicher, ist, dass man es getrost verwenden kann, oder muss ich wirklich vom Reißbrett an linux aufsetzen und konfigurieren?

  • Warum gibst du den Contis nicht einfach eine eigenen IP im LAN und sparst dir dann das mehrfache NAT?


    Da du eh split DNS sauber fahren kannst, ist das doch ganz easy umsetzbar.


    Auf welcher Hardware willst du den Hypervisor laufen lassen?

  • was meinst du mit Contis?

    Hab ich was (wieder) übersehen? Plex als QTS App läuft auf derselben IP, container ebenfalls. Wie soll ich die separat auf den split DNS fahren lassen? und die Port-Probleme habe ich mit split DNS ja immer noch.

    Ein TS-453Be kommt zum Einsatz, 8 GB RAM

  • Du nutzt doch die Container Station oder nicht?


    Da kann man den Containern verschiedene Netzwerkeinstellungen mit geben und auch direkt mit einem vSwitch oder auch Software defined vSwitch verbinden.

    So hat jeder Conatainer seine eigene IP und du kannst ihn direkt über die default http/https Ports ansprechen.

    pasted-from-clipboard.png


    Bei meinem NAS habe ich jedoch die http/https Ports umgestellt, jetzt wo du mich ins Nachdenken bringst, ist es jedoch auch bei mir gar nicht notwendig.

  • Nein, durch die Verbindung zum vSwitch bekommt der Container eine Layer 2 Verbindung zum LAN.

  • ah jetzt ja, ich verstehe.

    aber die MAC wechselt ja bei jedem start des containers und die fest eingestellte ip des containers übernimmt er auch nicht.

  • Die feste IP bleibt bei mir und unter der ist er auch erreichbar.


    Bei einigen kann man die MAC fest setzen, dann passt auch die Reservierung, aber bei Unifi ist das noch nicht der Fall, jedenfalls nicht bei meinem bisher verwendetem Conti.

  • ich hab das mit den macs gelöst. die bleiben, wenn ich eine manuell eingebe beim erstellen des containers. sonst nicht.

    aber noch was: wenn ich zwei verschiedene hosts habe auf dem selben port, dann brauch ich doch nen proxy, oder verstehe ich das falsch?