Unitymedia Feste-ip.net Port + Letsencrypt auf nextcloud?

[mimimimedia]

Hallo,

ich habe mit Müh und Not meinen Nextcloud-Server (Raspberry Pi) hinter meiner Connect Box ins weltweite Netz veröffentlicht.

Umsetzen konnte ich dies dank feste-ip.net (ipv6 Dilemma).

Nun gibt es noch 2 Dinge, die mich stören:
1) Beim Aufruf der Seite muß mein feste-ip.net Port mitangegeben werden:
https://meinecloud.feste-ip.net:43344
Gibt es eine Möglichkeit dies so zu ändern, daß man https://meinecloud.feste-ip.net als Aufrufadresse hat?
2) Wie kann ich letsencrypt implementieren? Schätze mal, daß dies einfacher geht, wenn Punkt 1 gelöst ist..

Gruß
Michael

 

[Andreas1969]

So gut ich weiß, muss die Port Nummer immer mit angegeben werden (beim kleinen Paket).
Die IPV4 teilen sich ja auch viel Kunden.

Gruß Andreas

 

[addicted]

Let's Encrypt kannst Du vermutlich nicht für diese Domain nutzen, sondern musst eine eigene verwenden. Grund ist, dass die Überprüfung des Hostnamens entweder via HTTP auf Port 80 oder via DNS Eintrag vorgenommen wird, und an beides kommst Du bei feste-ip.net wohl nicht ran.
Wenn Du eine eigene Domain verwendest, für die Du in der DNS Zone Einträge definieren kannst, dann kannst Du Dir darauf ein Zertifikat ausstellen lassen.

Aber ggf. fragst Du einfach mal deren Support?

 

[MartinDJR]

1) Beim Aufruf der Seite muß mein feste-ip.net Port mitangegeben werden:
https://meinecloud.feste-ip.net:43344
Gibt es eine Möglichkeit dies so zu ändern, daß man https://meinecloud.feste-ip.net als Aufrufadresse hat?

Bei https muss man die Portnummer genau dann nicht mitgeben, wenn sie 443 ist, bei http genau dann nicht, wenn sie 80 ist usw.

Wenn ich die aktuelle Preisliste von "feste-ip.net" richtig verstehe (keine Garantie), bezahlt man knapp 5 Euro im Jahr, wenn man mit beliebigen Portnummern zufrieden ist und knapp 35 Euro im Jahr, wenn man ganz bestimmte Portnummern haben will.

Der große Preisunterschied kommt daher, dass bei 5 Euro im Jahr sich mehrere Kunden eine IP-Adresse teilen, während bei 35 Euro im Jahr die IP-Adresse nur für dich verwendet wird.

Für dich ist es natürlich fraglich, ob es dir 30 Euro im Jahr wert sind, dass du die Portnummer nicht angeben musst.

2) Wie kann ich letsencrypt implementieren? Schätze mal, daß dies einfacher geht, wenn Punkt 1 gelöst ist..

Leider habe ich von SSL wenig Ahnung, so dass das, was ich jetzt schreibe, auch falsch sein könnte:

Falls sich ein Zertifikat auf einen Hostnamen bezieht, wird sich das mit der 5-Euro-Version von "feste-ip.net" gar nicht machen lassen.

Der Grund ist relativ einfach: Da sich mehrere Kunden dieselbe IP-Adresse teilen, wäre ein Zertifikat, das sich ein Kunde ausstellen lässt auch für einen anderen Kunden gültig, der auch der selben IP-Adresse sitzt.

Wenn irgendeine Zertifizierungsstelle (egal ob Verisign oder Let’s Encrypt) solche Zertifikate ausstellen würde, würde wohl dasselbe passieren, was mit CAcert passiert ist: Die meisten Webbrowserhersteller würden die Zertifikate dieser Zertifizierungsstelle als "unsicher" einstufen, wodurch das Zertifikat genau so viel wert ist, wie das selbstsignierte Zertifikat, das du jetzt verwendest.

Was du natürlich tun kannst, ist auf deinen eigenen Rechnern und Mobilgeräten dein eigenes selbstsigniertes Zertifikat zu installieren. Dann würde zumindest auf deinen eigenen Geräten dein Cloud-Server als "vertrauenswürdig" erkannt werden - aber eben nicht auf fremden Rechnern.

 

[Leseratte10]

Falls sich ein Zertifikat auf einen Hostnamen bezieht, wird sich das mit der 5-Euro-Version von "feste-ip.net" gar nicht machen lassen.
Der Grund ist relativ einfach: Da sich mehrere Kunden dieselbe IP-Adresse teilen, wäre ein Zertifikat, das sich ein Kunde ausstellen lässt auch für einen anderen Kunden gültig, der auch der selben IP-Adresse sitzt.

Die beiden Aussagen widersprechen sich.
SSL-Zertifikate werden für einen Hostnamen ausgestellt, nicht auf eine IP.

Man kann sich also eine Domain "meine-cloud.afraid.org" bei freedns.afraid.org oder so holen, setzt einen CNAME auf meinecloud.feste-ip.net
Dann kann man - wenn Lets Encrypt tatsächlich Verifizierung über DNS zulässt, weiß ich gerade nicht - sich ein Zertifikat für meine-cloud.afraid.org holen und auf dem Cloud-System nutzen - denn das Zertifikat gilt dann für meine-cloud.afraid.org und nicht für die feste-ip-IP.

Die afraid.org-Subdomain gehört einem dann ja, was man mit dem DNS-Record auch "beweisen" kann, und die IPv6-IPv4-Umwandlung bei feste-ip ist ja nur 1-zu-1-NAT was nix an der SSL-Verbindung ändert.

 

[MartinDJR]

Die beiden Aussagen widersprechen sich.
SSL-Zertifikate werden für einen Hostnamen ausgestellt, nicht auf eine IP.

Oups. Da hatte ich wohl einen Denfehler drin.

Hintergrund war, dass wenn ein Kunde den Hostnamen "a.feste-ip.net:1234" hat und ein anderer "b.feste-ip.net:5678" und sich beide dieselbe IP-Adresse haben, der Server von Kunde A auch unter der Adresse "b.feste-ip.net:1234" erreichbar ist und der von Kunde B entsprechend unter "a.feste-ip.net:5678". Die Hostnamen sind also austauschbar.

Wenn Zertifikate aber nicht auf IP-Adressen, sondern auf Hostnamen ausgestellt werden, hast du recht: Diese Tatsache lässt sich wohl nicht ohne weiteres missbrauchen.

Bleibt noch die Frage, ob "feste-ip.net" jedem Kunden einen eigenen Hostnamen zuweist, oder ob die auch teilweise zwischen Kunden geteilt werden...

 

[Leseratte10]

Deshalb schlug ich vor, einen DNS-Eintrag bei freedns.afraid.org anzulegen. Dann lautet deine Domain irgendwas.afraid.org und es ist egal, ob du dir irgendwas.feste-ip.net mit wem anders teilst.

 

[mimimimedia]

Sorry für die verspätete Antwort.
Erstmal vielen Dank für die konstruktiven Beiträge. Die Idee mit der dyndns Weiterleitung gefällt mir. Werde ich probieren.

 

[root42]

Hallo,


bisher wurde viel grundsätzliches richtig erklärt, ich will an der Stelle mal helfen, wie man das praktisch umsetzt.

1) Beim Aufruf der Seite muß mein feste-ip.net Port mitangegeben werden:
https://meinecloud.feste-ip.net:43344
Gibt es eine Möglichkeit dies so zu ändern, daß man https://meinecloud.feste-ip.net als Aufrufadresse hat?

Wurde ja schon erklärt, dass das mit der günstigen Version nicht geht.

2) Wie kann ich letsencrypt implementieren? Schätze mal, daß dies einfacher geht, wenn Punkt 1 gelöst ist..

HTTPS hat neben der Verschlüsselung noch eine weitere Funktion: es soll sicherstellen, dass die Server, mit dem sich dein PC verbindet, auch wirklich die sind, die sie vorgeben zu sein. Dazu hat jeder Server ein Zertifikat, dass (wie von @Leseratte10 erwähnt) auf seinen Hostnamen (also seine Domain) ausgestellt ist. Prinzipiell kann sich jeder selbst Zertifikate für jede Domain erstellen.
Damit eben diese Verifizierungsfunktion von SSL erfüllt wird, darf ist das ja nicht sinnvoll. Daher zeigt der Browser beim Aufrufen der Seite über HTTPS mit einem selbst signierten Zertifikat eine schöne Fehlermeldung an. Jetzt kommen Certificate Authorities (CAs, wie LetsEncrypt eine ist) ins Spiel. Diese verbegen Zertifikate, denen die Browser vertrauen und keine Fehlermeldung anzeigen.
Dabei müssen die CAs verfizieren, dass du, wenn du ein Zertifikat auf eine Domain erstellen willst, auch dazu berechtigt bist, d.h. dass es deine Domain ist und nicht die eines andren.

LetsEncrypt (LE) bietet im Moment zwei solcher Verifizierungsverfahren an: eines über HTTP und eines über DNS (Domain Name Service). Beim HTTP-Verfahren sendet der LE-Server eine Anfrage an den mit der Domain verknüpften Server auf Port 80 und erwartet als Antwort einen bestimmten Verifizierungscode. Dies ist bei LE das übliche Verfahren über den Standard-Client (Certbot).
Das Problem an diesem Verfahren ist, dass LE die Anfrage immer an Port 80 sendet. Da du aber nur einen Port (!= 80) zur Verfügung hat, funktioniert das Verfahren nicht.

Daher muss das DNS-Verfahren benutzt werden. Löst der LE-Server eine bestimmte Subdomain auf und erwartet dabei als Antwort eine Verifizierungscode als TXT-Record. (Ich würde dir empfehlen, dich kurz in DNS einzulesen :zwinker: )
Das heißt praktisch, du brauchst eine Domain, bei der du a) Zugriff auf die DNS-Einstellungen hat und du b) dein Server (über festeIP) erreichbar ist. Subdomains bekommst du (wie schon gepostet, z.B. hier https://freedns.afraid.org/) oder bestimmte Top Level Domains (.tk, .ml etc.) hier kostenlos: http://www.freenom.com/.
Wichtig ist, dass du *kein* DynDNS auf die IPv4 deines Internetanschlusses brauchst. Die Domain muss auf deine IPv4-Adresse von feste-ip verweisen. Am besten geht das mit einem sog. MX-Record auf "meinecloud.feste-ip.net".

Die DNS-Verifizerung war zwar meiner Meinung nicht mit dem LE-Client möglich, scheint aber mit Certbot doch zu funktioneren: https://community.letsencrypt.org/t/dns-based-challange-for-verification-of-letsencrypt-ssl-certs/28561.
Ich habe für die DNS-Verifizierung immer https://github.com/lukas2511/dehydrated genutzt, aber bitte zuerst Certbot testen

Wenns noch weitere Fragen/Probleme gibt, bitte posten

Viele Grüße!

 

[mimimimedia]

@root42
Recht herzlichen Dank für die Erklärung! So langsam dämmert's.

"Damit eben diese Verifizierungsfunktion von SSL erfüllt wird, darf ist das ja nicht sinnvoll."
Hier hat sich der Fehlerteufel eingeschlichen. Wie müßte der Satz richtig heißen?

:idea:
Ich habe übrigens eine eigene Domain! Daran hatte ich überhaupt nicht mehr gedacht. Nutze ich nur "als Mailadresse".
Gerade habe ich im Konto meines Domainhosters nachgeschaut: Ich kann dort einen vhost Eintrag hinterlegen! Könnte ich mir dann den Umweg über dyndns sparen indem ich dann als vhost die feste-ip.net Adresse hinterlege?
Dann wäre die Kette:

meineeigenedomain.de <===(ipv4)===> meins.feste-ip.net:45443 <===(ipv6)===> Connect Box <===(ipv6)===> RPi-Server

LE-Verifizierung...
Mal überlegen...
Letsencrypt-Anfrage wird über Port 80 an meineeigenedomain.de geschickt, die dann bis zum Server durchgereicht wird. Jetzt weiß ich es gerade nicht auswendig, da ich keinen Zugang zu meiner Connect Box habe. Leitet die Connect Box wieder auf den richtigen Port um?! Also von Port 45443 auf 80?! Wenn dem so ist müßte die HTTP-Verifizierung funktionieren, oder? Oder ist dies überhaupt nicht relevant, daß es "am Ende" auf dem richtigen Port ankommt?

Grüße
Michael

 

[Soldierofoc]

Kenne leider die CB nicht, da ich eine eigene Fritzbox nutze. Der Port muss aber (zumindest bei mir) immer forwarded werden bzw. freigegeben (bzw. auch für HTTPS), ansonsten funktioniert es nicht.

 

[root42]

Hallo,

"Damit eben diese Verifizierungsfunktion von SSL erfüllt wird, darf ist das ja nicht sinnvoll."
Hier hat sich der Fehlerteufel eingeschlichen. Wie müßte der Satz richtig heißen?

Das ist wohl die Kombination aus "darf das ja nicht sein" und "ist das ja nicht sinnvoll"

Ich verstehe nur noch nicht ganz, was du mit deinem Hoster erreichen willst. Hast du bei deinem Hoster Zugriff auf die DNS-EInstellungen? Hast du vlt. schon ein SSL-Zertifikat für die Domain bei deinem Hoster?

Ich sehe jetzt mit deiner Domain zwei Möglichkeiten, wie du dein Problem lösen kannst.

1. Du legst bei deinem Hoster einen CNAME-Eintrag von meineeigenedomain.de (oder cloud.meineeigenedomain.de oder sowas) auf meins.feste-ip.net an. Dann holst du dir auf deinem Pi ein SSL-Zertifikat über die DNS-Verifizierung. Prinzipiell ist dann (cloud.)meineeigenedomain.de ein Alias für meins.feste-ip.net.
Nachteil: du rufst deinen Server dann im Browser über https://(cloud.)meineeigenedomain.de:45443 auf. Das kann ein bisschen viel Tipparbeit sein. Vorteil: recht einfach zu konfigurieren.
Vorteil: recht einfach zu konfigurieren

2. Die vielleicht elegantere Möglichkeit ist die, bei deinem Hoster einen sog. Reverse Proxy auf deinen Pi zu konfigurieren.
Vorraussetzung: dein Hoster muss IPv6 unterstützen und dir erlauben, einen Reverse Proxy einzurichten. Ich würde einfach mal nachfragen, wie es damit aussieht. Wenn der Reverse Proxy normalerweise nicht erlaubt ist, erklär dein Problem mit DS-Lite und vl. sind sie so freundlich und erlauben es dir
Nachteile: Viel Einrichtungsaufwand, Kompletter Traffic zu deinem Server ist beim Hoster unverschlüsselt, d.h. er könnte nach Belieben mitlesen.
Vorteile: Du brauchst die feste-ip.net nicht (für den HTTP(S)-Zugriff auf deinen Server).
Anleitung:

• DynDNS auf dem Pi einrichten, ausschließlich für IPv6
• Auf dem Pi den Webserver für HTTPS auch irgendeinem Port (z.B. 443) mit Zertifikaten einrichten. Du kannst welche von LE nehmen, aber auch selbst signierte. Das sollte egal sein.
• Auf der Connect Box den Port 443 auf dem Pi für Zugriffe von außen freischalten (wie genau das bei IPv6 geht, weiß ich nicht, aber du solltest etwas derartiges schon haben für den Port 45443).
• In den DNS-Einstellungen die Subdomain cloud.meineeigenedomain.de einrichten, dass diese auf den Server bei deinem Hoster verweist (am besten mit einem CNAME auf meineeigenedomain.de).
• Irgendwie bei deinem Hoster ein Zertifikat für cloud.meineeigenedomain.de. Entweder ist beim Hosting eins dabei oder du kannst eines von LE im Control Panel erstellen (oder du musst mal bei deinem Hoster nachfragen).
• Dann richtest du einen VHost für cloud.meineeigenedomain.de:443 (also HTTPS) ein, der als Reverse Proxy auf deine DynDNS-Domain agiert. (EInfach mal googeln wie das mit Apache geht, z.B. https://hosting.1und1.de/digitalguide/server/knowhow/was-ist-ein-reverse-proxy/)
• Eventuell noch einen VHost für cloud.meineeigenedomain.de:80 (HTTP), der auf HTTPS weiterleitet.

Alternativ bietet CloudFlare genau das (sogar kostenlos) an: Einen Reverse Proxy, der auch von IPv4 auf IPv6 "übersetzt". Aber AFAIK soll man bei CloudFlare den Nameserver seiner Domain ändern. Hier musst du halt wissen, dass der gesamte Traffic bei CloudFlare unverschlüsselt vorliegt.

ich hoffe, dass hilft dir - sollte es noch Fragen geben, einfach nachfragen!

Achso, deine Fragen:

Leitet die Connect Box wieder auf den richtigen Port um?! Also von Port 45443 auf 80?!

Das solltest du einstellen können (zumindest bei IPv4, bei v6 bin ich mir nicht so ganz sicher).

Oder ist dies überhaupt nicht relevant, daß es "am Ende" auf dem richtigen Port ankommt?

Das ist vollkommen egal. Es kommt darauf an, dass LE-Server einen Server über Port 80 ansprechen können und von diesem die richtige Antwort bekommen. Ob die Anfrage irgendwie weitergeleitet wird, sollte herzlich egal sein.

Viele Grüße!

 

[mimimimedia]

Ja super!
Nochmals muchos gracias!

Klasse Anleitung, werde ich bei Gelegenheit versuchen umzusetzen. Werde hier dann über Erfolg oder Misserfolg berichten.

Bis die Tage
Michael

 

[why_]

Wichtig ist, dass du *kein* DynDNS auf die IPv4 deines Internetanschlusses brauchst. Die Domain muss auf deine IPv4-Adresse von feste-ip verweisen. Am besten geht das mit einem sog. MX-Record auf "meinecloud.feste-ip.net".

Warum willst du denn einen MX Record setzen? Er müsste einen A-Record setzen da MX wie der Name schon sagt nur für Mail ist.
mimimimedia scheint ja nur E-Mail hosting zu haben somit ist alles bis auf cloudflare für die Katz was du geschrieben hast.

Zum glück musste ich mich nie mit solchen Gammellösungen beschäftigen, IPv6 via Mobilfunk und auf der Arbeit zum Dank.

 

[addicted]

Wichtig ist, dass du *kein* DynDNS auf die IPv4 deines Internetanschlusses brauchst. Die Domain muss auf deine IPv4-Adresse von feste-ip verweisen. Am besten geht das mit einem sog. MX-Record auf "meinecloud.feste-ip.net".

Warum willst du denn einen MX Record setzen? Er müsste einen A-Record setzen da MX wie der Name schon sagt nur für Mail ist.

Er hat sich sicher nur vertippt, genau wie Du auch - in seinem nächsten längeren Beitrag schreibt er "CNAME", was hier natürlich richtig ist

 

[root42]

why_ hat geschrieben: ?
12.08.2017, 03:59

root42 hat geschrieben: ?
09.08.2017, 18:03
Wichtig ist, dass du *kein* DynDNS auf die IPv4 deines Internetanschlusses brauchst. Die Domain muss auf deine IPv4-Adresse von feste-ip verweisen. Am besten geht das mit einem sog. MX-Record auf "meinecloud.feste-ip.net".

Warum willst du denn einen MX Record setzen? Er müsste einen A-Record setzen da MX wie der Name schon sagt nur für Mail ist.

Er hat sich sicher nur vertippt, genau wie Du auch - in seinem nächsten längeren Beitrag schreibt er "CNAME", was hier natürlich richtig ist

Natürlich soll es CNAME heißen - Aber ich find irgendwie den Knopf nicht, um den Beitrag zu bearbeiten und es da zu korrigieren

mimimimedia scheint ja nur E-Mail hosting zu haben somit ist alles bis auf cloudflare für die Katz was du geschrieben hast.

Scheint er das?

Ich habe übrigens eine eigene Domain! Daran hatte ich überhaupt nicht mehr gedacht. Nutze ich nur "als Mailadresse".
Gerade habe ich im Konto meines Domainhosters nachgeschaut: Ich kann dort einen vhost Eintrag hinterlegen! Könnte ich mir dann den Umweg über dyndns sparen indem ich dann als vhost die feste-ip.net Adresse hinterlege?

Für mich sieht das so aus, als sei das mehr als Mail-Hosting. Das Prinzip von vhosts wird zwar AFAIK auch bei E-Mail angewendet, jedoch wird man die da nicht als Kunde unter dem Namen vhost hinzufügen können...

meineeigenedomain.de <===(ipv4)===> meins.feste-ip.net:45443 <===(ipv6)===> Connect Box <===(ipv6)===> RPi-Server

Auch das wäre IMHO relativ sinnlos, hätte er nur Mailhosting.

@Michael: Kannst du uns bitte aufklären? Hast du nur ein Mailhosting oder ein Hostingpaket (Website + Mail)?

 

[why_]

Wichtig ist, dass du *kein* DynDNS auf die IPv4 deines Internetanschlusses brauchst. Die Domain muss auf deine IPv4-Adresse von feste-ip verweisen. Am besten geht das mit einem sog. MX-Record auf "meinecloud.feste-ip.net".

Warum willst du denn einen MX Record setzen? Er müsste einen A-Record setzen da MX wie der Name schon sagt nur für Mail ist.

Er hat sich sicher nur vertippt, genau wie Du auch - in seinem nächsten längeren Beitrag schreibt er "CNAME", was hier natürlich richtig ist

A-Record ist schon richtig, bei einer statischen IP braucht man kein CNAME

 

[addicted]

A-Records setzt Du auf IP-Adressen. Der Tipp ist aber, einen Record auf den Hostnamen von feste-ip.net zu setzen. Dafür nimmt man CNAME.
Wenn Du Beiträge korrigierst, musst Du schon im richtigen Kontext bleiben

Wohlgemerkt: Die komplette Domain kannst du eh nicht per CNAME umbiegen, nur eine Subdomain/Hostnamen. Ist auch besser so, wenn Email unter der Domains weiter funktionieren soll.

Ja, man könnte sich auch die IP nehmen und einen A Record erstellen.
Aber das würde ich persönlich nicht machen. Da ist ja ein Drittanbieter im Spiel, wer weiß ob die nicht doch mal die zugewiesene IP ändern...

 

[mimimimedia]

Soweit, so gut.
Ich habe es jetzt hinbekommen, daß ich von eine freedns Adresse aufrufe, welche auf meine feste-ip.net Adresse weiterleitet und von dort direkt zum Raspberry Pi geht.
Funktioniert allerdings nur wenn ich die Firewall der Connect Box deaktiviere. Gibt es eine Möglichkeit das Ganze durchzuleiten ohne, daß ich sie ausschalte?

Die Funktion IP-/Port-Weiterleitung der Connect Box kann man vergessen wenn man DSLite hat, richtig?

Grüße
Michael

 

[addicted]

Du kannst die v6 Adresse des PI in der Firewall als Ausnahme definieren.

 

[mimimimedia]

So sollte es doch eigentlich gehen? Funktionierte allerdings nicht.

Umgekehrte Einstellung für "Ausehend".

 

[addicted]

Der Filter ist ein Filter, d.h. er filtert diese Ports weg.
Du brauchst bei v6 keine Portweiterleitungen zu machen, was Du scheinbar versuchst.

Wie gesagt: Du musst die v6 Adresse vom PI als Ausnahme von der Firewall definieren. Dann sind alle Ports dorthin offen.

 

[mimimimedia]

Ja, das meinte ich in meinem letzten Post, daß Forwarding mit DSLite nicht notwendig ist.

Aber wo/wie stelle ich die Ausnahme für die Firewall ein? Im Menü Filter habe ich ja keine Eingabefelder, hier kann ich nur Häkchen setzen.

 

[addicted]

Ehrlich gesagt weiß ich das nicht mehr. Ist nen Jahr her, dass ich das bei einem Kollegen gemacht habe - selbst habe ich ja keine ConnectBox.
Guck mal im Menü "Firewall"?

 

[Andreas1969]

Aber wo/wie stelle ich die Ausnahme für die Firewall ein?

Wenn ich das noch richtig auf dem Schirm habe, kann die ConnectBox das nicht, kann aber nicht mehr nachschauen, da ich den Anschluss mit der ConnectBox aufgrund DSLITE wieder gekündigt habe und an dem Standort zurück zur Telekom bin. Ich glaube, es lässt sich nur die Firewall komplett deaktivieren.