VM über Dyndns erreichen

[FrAntje]

Hallo zusammen,

kann mir vielleicht jemand dabei helfen, eine VM über Dyndns zu erreichen. Irgendwie verhaspel ich mich ab einem bestimmten Punkt immer mit den ganzen Weiterleitungen, Domains, Proxy Einstellungen.

Also ich habe eine Benutzerdefinierte Domain unter Systemsteuerung -> DSM-Einstellungen -> Daomin eingetragen (MeineDomain.net). Port 443 ist weitergeleitet und somit erreiche ich eigentlich alle meine Dienste über https://meinedomain.net
Die DS hat die IP 192.168.10.13
Eine univention VM läuft im Virtual Maschine Manager unter der 192.168.10.14 und ist lokal erreichbar.

Ich habe jetzt erstmal einen Reverse Proxy von Hostnamen vm.meinedomain.net Port 443 auf die ip der VM Port 443 gesetzt. Weiß aber nicht ob das so stimmt.

Kann ich nun diese VM irgendwie per dyndns erreichen? z.B, mit vm.meinedomain.net?

Danke für eure Zeit und viele Grüße

 

[towade]

Ich stehe seit heute vor exakt dem gleichen Problem und würde mich ebenfalls über Hilfe freuen.

 

[Fusion]

Wenn vm.meinedomain.net auch auf deine öffentliche IP auflöst sehe ich nicht wieso das nicht gehen sollte. Allerdings ist es eben ein http-reverse proxy, sind nicht unbedingt alle Dienste darüber erreichbar die du willst.

Noch einfacher geht es z.B. mit Portweiterleitung 444 > 443 auf IP...10.14, dann ist die VM vermutlich via https://meinedomain.net:444 erreichbar

 

[blurrrr]

Es wäre sowieso erstmal hilfreich, dass mögliche Fehlerquellen rausgenommen werden. Also zum "kurz" testen einfach mal eine direkte Portweiterleitung auf die VM machen (ohne Proxy). Natürlich müssen die Angaben im DNS schon stimmig sein (Forward-Lookup -> A-Record für statische IPs, CNAME für DynDNS-Hostnamen). Wenn das dann soweit alles stimmig ist und funktioniert, kann man die Portweiterleitung auf den Proxy umbiegen und dort eben die entsprechenden Endpunkte per Domain konfigurieren:

syno.domain.tld:443 -> 192.168.10.13
uc.domain.tld:443 -> 192.168.10.14

Wie Fusion allerdings schon schrieb funktioniert das auch nicht mit allen Protokollen und selbst bei HTTPS-Zugriffen gibt es mitunter (je nach Applikation) den ein oder anderen Fallstrick. Ich würde es einfach mal kurz via reiner Portweiterleitung testen (ob auch alles erreichbar ist) und erst danach den Proxy dazwischen hängen. Kann ja auch sein, dass ggf. schon vorher ein entsprechendes Problem dabei auftritt, dann wäre das erstmal zu klären, bevor da noch der Proxy dazwischen kommt

 

[FrAntje]

Ok, danke für die Infos. Bisher klappt das ganz gut. Mal sehen ob ich noch Fallstricke übern Weg laufe.
Vielleicht hole ich aber auch noch nen 1€ VPS, ich halte ja nicht so viel von VMs auf diesen Mini Hardware Synology Geräten

 

[FrAntje]

Ich habe jetzt noch ein paar Versuche getestet und verschiedene Setups getestet. Dazu habe ich ins Netzwerk einen VMware Esxi gestellt. Auf diesen laufen dann ein paar Test VMs, unter anderem auch eine Apache Reverse Proxy.
Ich erreiche nun eigentlich alle VMs über Port 80/433, nur mit der Synology will das nicht so ganz.
Ich habe irgendwie das Gefühl, dass dies auch etwas komplizierter wird.
Vielleicht kann mir jemand mit ein paar Antworten den richtigen Weg andeuten?

1. Hat jemand schon solch ein Setup betrieben und weiß daher, ob das überhaupt laufen kann?
2. Der Reverse Proxy auf dem NAS ist doch eigentlich das gleiche oder? Ein Apache bzw. Nginx Reverse Proxy, der technisch identisch mit dem ist, den ich in meiner Ubuntu VM habe oder?
3. Sollte ich dann nicht einfach die Ports 80/443 wie gehabt an das NAS leiten und dort den Reverse Proxy nutzen?

 

[blurrrr]

Frage ist , was genau Du laufen lassen willst bzw. von extern erreichen willst. Reine Webgeschichten dürften da sehr unproblematisch sein. Bei diesem "vorgekauten" Syno-Zeugs "könnte" es ggf. Probleme geben, wenn man die Configs händisch anfummelt, nicht, dass das alles wieder weg ist bei einem Update und mit dem bisschen überschrieben wird, was man in der GUI konfigurieren kann, k.a. Von solchen Dingen lass ich prinzipiell die Finger, dann lieber eine Proxy-VM und jut is.

Aber um Deine Fragen kurz und knapp zu beantworten: 1-3 -> "Ja"

 

[FrAntje]

Also Konfigurationen außerhalb des GUI zu machen, kommt für mich eh nicht in frage. Dafür habe ich mir ja nicht ein Synology gekauft
Dann wäre ich gleich bei den freien NAS Systemen geblieben.

Und derzeit sind es eigentlich Web Anwendungen. Ein Wekan Board, ein Restyaboard, ein Spiceworks, ein UCS für Tests (Rocket Chat, Mattermost etc.)
Es funktioniert ja generell alles mit dem NAS als Reverse Proxy. Also Port 80/443 aufs NAS und dort je einen http und einen https Eintrag pro VM.

Nur dann habt ihr mich verunsichert oder wars du es? und ich hatte Zeit, also habe ich einfach nen Proxy aufgesetzt.
Und jetzt merke ich offensichtlich, dass er für meine Anwendungen eigentlich nichts besser macht, außer vielleicht locations a la meinedomain.de/vm1 (mir gehen bei Strato nämlich die subdomains aus, drecksladen)
Naja und dass er halt mit dem NAS nicht läuft.

 

[blurrrr]

Naja, das Ding ist halt, dass auch speziellere Dinge (also keine normalen "Webseiten") mitunter auch ein paar spezielle Dinge in der Proxy-Config UND ggf. in der eigenen Config brauchen. Von daher wäre es da auch ratsam, immer nochmal in die Doku der Software zu schauen, welche durch den RP soll, im Falle von Mattermost zb:

https://docs.mattermost.com/install/config-proxy-nginx.html
oder
https://docs.mattermost.com/install/config-proxy-apache2.html

Kurzum: Darfst also für jedes Deiner Vorhaben extra nachgucken. Nicht zu vernachlässigen sind natürlich wie schon gesagt, auch die Configs der eigentlichen Software-Installationen, da diese ggf. wissen müssen, dass sie über einen Proxy Anfragen bekommen und natürlich zuletzt sollte der Hostname auch stimmig sein, damit der RP das auch korrekt zuordnen kann (letzteres ist relativ selbstverständlich, wird aber trotzdem gern mal vergessen, daher sag ich es - ist wie "Hat das Ding auch Strom?" ).

Was die Subdomains angeht...

deinedomain.tld -> Hoster
www.deinedomain.tld -> Hoster
mail.deinedomain.tld -> Hoster (falls das nicht ganz anders geregelt ist)

Also alles wichtige beim Hoster lassen und dann noch ein:

*.deinedomain.tld --> deindyndns.tld

Damit wird alles andere zu Dir umgebogen und das Subdomain-Management bzw. in diesem Fall nur noch vHost-Management übernimmst Du dann bei Dir hinter Deinem DynDNS-Anschluss