Beiträge von netsch1967

Zitat von Olivetti

es bleibt schwierig, wenn du alles durcheinander würfelst und auch via browser zu testen ist nicht sinnvoll.

mail.domain.tld interessiert bei autoconfig überhaupt nicht.

wenn du eingibst:

curl -sS "http://autoconfig.netcup.net/mail/config-v1.1.xml"

kommt bei dir bitte was zurück?

Provider "netcup.net"

imap.netcup.net

smtp.netcup.net

Wenn ich das mit meiner Domian mache "http://autoconfig.domain.tld/xxx"

mail.domain.tld

mail.domain.tld

Zitat von tab

Warum jetzt mail.domain.tld? Das läuft doch über autoconfig.domain.tld. Bei mail.domain.tld kommt bei mir weder mit http noch mit https eine Verbindung zustande, hätte mich auch gewundert. mail.domain.tld ist doch einer der MX Einträge, der hat mit http/https nichts am Hut.

Wie ich schon am Anfang beschrieben habe, wird mir durch das "autoconfig.domain.tld" dann nicht "mx1234.netcup.net" zurück geliefert, sondern "mail.domain.tld".
Bei "mail.domain.tld" wird dann ein Zertifikat von "netcup.net" präsentiert und da geht dann dank HSTS nix mehr.

Zitat von tab

Allerdings habe ich nirgends ein Wildcard-Zertifikat,

Es funktioniert mit Wildcard eben so wenig wie ohne.

Zitat von tab

das immer manuell erneuern zu müssen.

Das erneuert sich automatisch.
Hatte ich schon auf den selbst gehosteten Systemen so gelößt.

Zitat von tab

Ich kann nur sagen, wenn ich https://autoconfig@irgendeinermeinerdomains.tld/xxx aufrufe, dann kommt erst gar keine Verbindung zustande, geschweige denn wird mir irgendein Zertifikat präsentiert. Ich habe jetzt 15 Minuten lang probiert, irgendwie dahin zu kommen, dass mir netcup.net irgendein Zertifikat präsentiert. Klappt nicht. Vielleicht muss da doch der Support ran und es mit deiner Domain probieren. Daran oder an deinem Webhosting oder deinen Änderungen muss es ja wohl liegen. Bei mir funktioniert es mit allen Domains, die ich probiert habe. Allerdings habe ich nirgends ein Wildcard-Zertifikat, aus Gründen ... Keine Lust, das immer manuell erneuern zu müssen. Vielleicht probiere ich das mal interessehalber, um zu sehen ob ich das damit dann schaffe deinen Fehler zu bekommen.

Vielleicht funktioniert es bei dem einen oder anderen. Das Problem scheint dem Support auch bekannt zu sein.

"http://mail.domain.tld" landet auf "https://mail.domain.tld", auch ohne Wildcard Zertifikat!

So sieht es unter Firefox aus:

pasted-from-clipboard.png

pasted-from-clipboard.png

Und so unter Curl:
pasted-from-clipboard.png

Kleiner Nachtrag:
Unter http meldet sich nix!

Zitat von Olivetti

und das zertifikat als wildcard mit HSTS gilt ja auch für autoconfig.domain.tld. solange er das nicht ändert, wird's eh' nix.

Warum wird dann beim Aufruf von "https://autoconfig.domain.tld/xxx" das Zertifikat von "netcup.net" ausgegeben?

Zitat von tab

Ja, es liegt wahrscheinlich an deinem Wildcard-Zertifikat mit HSTS für deine Domain. Das gilt auch für die autoconfig-Subdomain.

Kann auch nicht zutreffen, da ich nachweislich das Zertifikat von "netcup.net" bekomme, welches nicht zu "domain.tld" passt.
Mein Zertifikat "domain.tld" würde dann ja nicht zu "netcup.net" passen. Das Zertifiakt kann ich mir aber anschauen, welches ich dank HSTS nicht umgehen kann und dort wird mir angezeigt, dass es für "netcup.net" und "*.netcuo.net" ausgestellt ist.

Zitat von tab

Gut, wenn das nicht funktionieren kann, dann erkläre mir mal bitte, warum bei mir mit Firefox die folgende URL die autoconfig xml-Datei zurückgibt:

Code

http://autoconfig.netcup.net/mail/config-v1.1.xml?emailaddress=tab@example.com

während die selbe URL mit https nicht funktioniert und die Meldung zurückgibt:

Code

Fehler: Netzwerk-Zeitüberschreitung

Beim Verbinden mit autoconfig.netcup.net trat ein Fehler auf. 

Und wieso ich http://autoconfig.netcup.net ohne HSTS und Weiterleitung auf https aufrufen kann, wenn ich auch gesagt bekomme

Code

Forbidden

You don't have permission to access this resource.
Apache/2.4.38 (Debian) Server at autoconfig.netcup.net Port 80

Edit: autoconfig.netcup.net und netcup.net sind eben zwei Paar Stiefel.

Ganz einfach erklärt:
Thunderbird ruft ja auch nicht "autoconfig.netcup.net" auf sondern "autoconfig.domain.tld". Hier melden sich dann "netcup.net" mit einem Zertifikat von "netcup.net", was ja nicht zu "domain.tld" passt. Wenn ich jetzt deine Adresse "http://autoconfig.domain.tld/xxxx" im Browser eingebe, lande ich auf "https://xxx" und dafür für ein Zertifikat benötigt, das zur Adresse/Domain passen muss.
Und da dort HSTS mit hinterlegt/angegeben/ausgewählt/... ist, läßt sich das auch nicht umgehen!

So sieht das überigens in Thunderbird aus:

pasted-from-clipboard.png

Zitat von tab

Code

mailnews.auto_config.fetchFromISP.sslOnly

Der Wert ist per Default auf false eingestellt, womit es dann bei netcup funktionieren kann. Wenn er auf true steht, dann könnte das die Erklärung des Problems sein.

Hilft nicht! Gleiches Ergebnis!

Zitat von DerRené

die autoconfig läuft nur unverschlüsselt über Port 80,

Kann schon mal nicht funktionieren, da das Zertifikat von netcup.net bei mir HTTPzuHTTPS und HSTS hat.
Da ist dann nichts auf Port 80 erreichbar.

Hallo Netcup Gemeinde.

Habe ein Paket Webhost 2000 gebucht, um meinen Mail Verkehr abzuwickeln.

Nur leider funktioniert die automatische Einrichtung von Mailclients garnicht.

Im DNS ist folgendes abgelegt:

mail.domain.tld A IPv4 von netcup.net

webmail.domain.tld A IPv4 von netcup.net

autoconfig.domain.tld CNAME autoconfig.netcup.net

1.Problem: mail.domain.tld verweist auf eine Domain von netcup.net, wo ein Zertifikat mit HTTPzuHTTPS und HSTS hinterlegt ist. Dies ist für netcup.net und *.netcup.net registriert und nicht für domain.tld. Somit kann weder per Browser darauf zugegriffen werden noch wird es von Thunderbird und Outlook akzeptiert. Ist aber auch logisch!

2.Problem: Bei webmail.domain.tld spiegelt sich selbes wie bei mail.domain.tld ab. Eigentlich sollte webmail.domain.tld dem Benutzer den Webzugriff auf das Mailkonto erleichtern, um sich nicht eine "komplizierte" Domain merken zu müssen. Aber auch hier verweigern, dank HSTS, die Browser ein Weiterkommen. Das "falsche" Zertifikat kann nicht umgangen werden. Sicherheitstechnisch vollkommem legitim und wünschenswert!

3.Problem: autoconfig.domain.tld verweist auf netcup.net und wird für die Autokonfiguration der Mailclienten benötigt. Aber hier wird mail.domain.tld zurück gegeben, was ja nun nicht funktioniert, und nicht mx1234.netcup.net, so wie es Netcup empfiehlt, manuell einzutragen.

Also ein Versuch dieses System auszutricksen.

Die 3 DNS Einträge gelöscht und versucht Subdomains anzulegen. Dies wird allerdings verweigert, da es die Namen schon gibt. DNS TTL steht auf 600 und auch nach 24h war es nicht möglich. Antwort vom Support: Es sind "feste" Einträge vom System was über dem Webhost 2000 steht. Das heißt, das mail.xxx und webmail.xxx dahin zeigen müssen was dort steht und nichts anderes.

Zweiter Versuch erfolgte mit autoconfig.domain.tld. Diesen habe ich auf domain.tld gesetzt und nach diversen Anleitungen im Internet selber eine config-v1.1.xml angelegt. Zu der domain.tld wurde eine Wildcard Zertifikat angelegt.

Egal was in der config steht und wo ich sie ablege, es wird dem Mail Client immer mail.domain.tld zurück gegeben. DNS TTL steht immer noch auf 600 und auch nach 48h ändert sich nichts.

Mehrere Ablageorte wurden angelegt:

domain.tld/.well-known/autoconfig/mail/config-v1.1.xml

domain.tld/.well-known/mail/config-v1.1.xml

domain.tld/.well-known/config-v1.1.xml

domain.tld/autoconfig/mail/config-v1.1.xml

domain.tld/autoconfig/config-v1.1.xml

domain.tld/mail/config-v1.1.xml

domain.tld/config-v1.1.xml

Die config-v1.1.xml ist nach folgendem Beispiel angelegt:

https://github.com/szepeviktor/debian-server-tools/blob/master/mail/well-known-autodiscover/.well-known/autoconfig/mail/config-v1.1.xml

Als Domain steht dort mx1234.netcup.net. Über Browser getestet und kann geöffnet werden.

iPad, Thunderbird, Outlook, Gmail melden trotz dem immer mail.domain.tld zurück und können, wegen HSTS und dem "falschen" Zertifikat, nicht darauf zugreifen.

Also eine Fehlkonfiguration bei der man bei den Webhosting 1000/2000/4000/8000 leben muss -!

Zitat von H6G

Sowohl der Kunde, als auch Netcup zahlt ja für IPv4 Adressen - ein Server ohne IPv4 wäre preiswerter.

Beim Anbieter aus Falkenstein gibt es auch die Möglichkeit auf IPv4 zu verzichten und einen Rabatt

Sorry, dachte eher an die technische Umsetzbarkeit und nicht an die Ersparnis -

Zitat von isa

Moin zusammen,

IPv4 ist endlich und daher sind IPv4 Adressen folglich auch teurer als IPv6 Adressen.

Ich brauche für einige Projekte / Server die ich habe gar keine IPv4 Adressen, da IPv6 für diesen Anwendungsfall komplett ausreicht.

Wäre es nicht super, wenn für solche VPS nicht unnötig IPv4 Adressen verschwendet werden müssten?

Wenn es VPS mit IPv6 only dafür geben würde?

Das würde ja auch Netcup Geld sparen (bzw. man kann mehr VPS verkaufen ohne IPv4 Adressen zu brauchen), was man an die Kunden als günstigeres Angebot teilweise auch weitergeben könnte.

Bei einigen anderen großen Anbietern gibt es diese Option ja schon für kleine VPS, wo die IPv4 dann optional zubuchbar wenn erforderlich ist, jedoch nicht verpflichtend ist.

Alles anzeigen

Hier klinke ich mich mal kurz ein.

Du bekommst doch zu deiner IPv4 auch ein IPv6 Präfix. Was spricht dagegen IPv4 zu deaktivieren und nur IPv6 zu nutzen -

Bei einem VPS nutze ich nur die IPv6 und kann jeden Docker Container über eine IPV6 erreichen, IPv6 only.

Da braucht es keine Diskusion ob IPv4 abschaltbar ist.

Habe mehrere Domains und Subdomains den IPv6 zugewiesen.

Zitat von TBT

Joa. War von der Docker Website, dass man zumindest die Ports halt braucht.

Meine Docker Hosts bei Netcup kommunizieren jetzt über das VLAN. Externe Kommunikation erfolgt über VPN.
Da die Hosts hier alle VPN Clients sind benötigt es keiner Portfreigabe mehr. Die Firewall macht alles externe dicht.

Zitat von michaeleifel

Wieso das ganze nicht einfach über das VLAN laufen lassen? Dann kann man sich doch die Portfreigabe sparen ( es sei denn man blockt auch im VLAN Ports ), oder nicht?

Wenn ich das richtig interpretiere sollte es möglich sein das Netzwerk mehrere Docker Instanzen auf unterschiedlichen Hosts ins gleiche Subnet zu stecken. Die Kommunikation wäre dann sicherlich einfacher, verschlüsselt und Vserver übergreifend.

Zitat von TBT

Wäre evtl auch https://docs.docker.com/network/overlay/ relevant für Dein Docker Setup?

Muss ich mir mal ansehen. Derzeit sind es mehrere VPS mit Docker auf denen unterschiedliche Dienste laufen.

Über VPN steht die Verbindung ins Heimnetz. Daher auch das Ziel, dass es keine geöffneten Ports auf den VPSs gibt.

Das war der Laster auf dem Schlauch.

Noch das Routing in UFW eingetragen und alles funktioniert wie es soll.

Dank!.

Hallo zusammen.

Ja, folgendes Thema wurde sicherlich schon ein dutzend mal gefragt, gepostet, geschrieben, gefragt usw.
Bitte nicht steinigen, bei mir steht irgend wo etwas auf'n Schlauch.

Möchte zwei VPS über Cloud VLAN verbinden. Auf beiden laufen mehrere Docker Container, die sich gegenseitig sehen sollen.
Bei beiden ist ETH1 mit einer gültigen IP eingerichtet. Ping von VPS1 zu VPS2 und VPS2 zu VPS1 mit diesen IPs funktioniert.

Problem:
Derzeit ist jeweils nur 172.xx.0.1 in beiden Richtungen erreichbar. Es erweckt den Eindruck, dass nicht geroutet/geforwarded wird.

Auf beiden System ist die sysctl entsprechen geändert. Setzt UFW auf allen Systemen ein. Zu Testzwecken ist diese aber auf beiden deaktiviert.

Kurz gesagt: Es ist immer NUR der Host, incl. Docker Host, erreichbar und nicht mehr die Container dahinter.

Zur Info:

Eine Wireguard Verbindung zwischen beiden funktioniert perfekt. Allerdings nutze ich alle System ausschließlich privat und es soll keine geöffneten Ports (nach außen) geben.

VPS1:

ETH1 10.8.100.101

Docker 172.30.0.1/24

ip route add 172.40.0.0/24 via 10.8.100.101 dev eth1

ufw für Testzwecke deaktiviert

iptables -A FORWARD -i eth1 -j ACCEPT

iptables -A FORWARD -o eth1 -j ACCEPT

net.ipv4.ip_forward=1

net.ipv6.conf.all.forwarding=1

VPS2:

ETH1 10.8.100.102

Docker 172.40.0.1/24

ip route add 172.30.0.0/24 via 10.8.100.102 dev eth1

ufw für Testzwecke deaktiviert

iptables -A FORWARD -i eth1-j ACCEPT

iptables -A FORWARD -o eth1 -j ACCEPT
net.ipv4.ip_forward=1

net.ipv6.conf.all.forwarding=1