Routing richtig einstellen

[Backpulver]

Hallo Community,

ich habe mal eine Frage.

Ich habe Zuhause einen Server mit mehreren virtuellen Maschinen stehen, wo verschiedene Dienste drauf laufen.

Server 1
Darunter 2 Teamspeak Virtualhosts (1 Server)
Ein Jabber Server

Server 2
Eine Cloud

Soweit sind alle Services erreichbar und funktionieren. TS hat schon 2 SRV Records für die Virtualhosts.

Nun habe ich für die Cloud den https Port belegt und die Weiterleitung sieht dort so aus:
Domainadresse - dyndns - 443 an Server

Jetzt habe ich allerdings das Problem, dass ich via Certbot kein Let's Encrypt Zertifikat auf Server 1 für den Jabber Server erstellen kann, da dies auch 443 haben will und abbricht und dabei mir was von A Records schreibt. A Records kann ich aber nicht verwenden, sondern nur den CNAME für die dyndns und SRV Records.

Hat irgendjemand Lust, sich mit der Thematik einmal mit mir auseinander zu setzen? Ich lerne gern und schnell und würde das Routing und die generelle Geschichte gern mal richtig machen.

Gruß

Alex

 

[Revolution]

Du musst in der Zeit das Port Forwarding auf den anderen Rechner schieben für 443...

Alternativ eine andere Auth methode für Letseencrypt wählen wie DNS

 

[Backpulver]

Du musst in der Zeit das Port Forwarding auf den anderen Rechner schieben für 443...

Alternativ eine andere Auth methode für Letseencrypt wählen wie DNS

Das muss ich dann aber auch bei jedem Renew machen oder? Gibt es da keine dauerhafte Lösung?

Würde ja jedes Mal Serverdowntime bedeuten.

 

[JAIRBS]

Kannst Du in den Configs der Programme nicht einfach den Standardport von 443 auf einen freien Port ändern? Das wäre mMn die einfachste Lösung. Das müssen die/das Programm(e) allerdings softwaretechnisch unterstützen.

 

[Backpulver]

Als Cloud habe ich die Nextcloud. Die läuft standardmäßig auf 443 und das ist so, wie ich das bisher gesehen habe, nicht änderbar.

Der Jabber Server (Chat) läuft ja nicht mal auf 443 sondern auf anderen Ports 5222 und 5223 (ssl). Problem ist aber, dass der Certbot nur 443 prüft und so dann nach Test der Verbindung durch die Adresse auf die Cloud geleitet wird.

Ich hatte an einen SRV Record oder sowas gedacht, mit dem ich vielleicht die Adresse so umleiten kann, dass erst ab dem Server selbst 443 verwendet wird.

Also im prinzip so:
Domain mit Port X nach dyndns nach Router auf von Port X auf 443. Dazu muss ich aber wissen, wie ich den srv Record richtig konfiguriere oder die Domain Records generell. Dazu weiß ich dann aber auch noch nicht, ob die Clients das so hinkriegen und nicht auf den spezifischen Port schauen sondern nur auf die Adresse. Das müsste ich dann testen.

 

[chrigu]

das ganze mit ipv6? da ist die externe adresse im prinzip das gerät selter.. oder geht das mit dem virtuellen nicht?

 

[Backpulver]

Nein noch IPv4

 

[RalphS]

Nicht Routing (IP), sondern Portforwarding (TCP).

Spontan würd ich vorschlagen, auf dem Host (für die VMs) ein NAT einzurichten, welches der Router-NAT vorgeschaltet ist. Dann kannst Du beide Hosts an Port 443 betreiben und müßtest dann beide Hosts per NAT-Konfiguration auf eine IP mit zwei Ports abbilden. Diese IP mit den beiden Ports kannst Du dann sozusagen als "gedachte Maschine" über das routerseitige Portforwarding ansteuern.

Eventuell wichtig: DAMIT das funktioniert, muß das Routing bereits stimmen. Ich mein ich geh mal davon aus, dem OP zu schließen; aber, die VMs müssen natürlich über ihre jeweilige IP-Adresse erreichbar sein. Sonst funktioniert das ohnehin nicht.

 

[Backpulver]

Nicht Routing (IP), sondern Portforwarding (TCP).

Spontan würd ich vorschlagen, auf dem Host (für die VMs) ein NAT einzurichten, welches der Router-NAT vorgeschaltet ist. Dann kannst Du beide Hosts an Port 443 betreiben und müßtest dann beide Hosts per NAT-Konfiguration auf eine IP mit zwei Ports abbilden. Diese IP mit den beiden Ports kannst Du dann sozusagen als "gedachte Maschine" über das routerseitige Portforwarding ansteuern.

Eventuell wichtig: DAMIT das funktioniert, muß das Routing bereits stimmen. Ich mein ich geh mal davon aus, dem OP zu schließen; aber, die VMs müssen natürlich über ihre jeweilige IP-Adresse erreichbar sein. Sonst funktioniert das ohnehin nicht.

Ok das werde ich mal probieren. Wenn ich was nicht hinkriege, kann ich mich doch sicherlich melden oder?