11
Routing zu HTTPS in einer VPS geblockt ?
Hallo,
ich betreibe einen Linux Server der jeden Tag Daten zum Download von einer Domain zur Verfuegung stellt. Die Domain wurde mit LetsEncrypt zertifiziert und der Zugriff auf die Dateien ist per Request mit HTTP und HTTPS moeglich.
Die 'Kunden' requesten die Daten mit einem 3rd Party Tool, von dem ich keine Kenntnis habe wie der Datei-Request angestossen wird, leider immer nur mit HTTP. Dadurch wird die Anfrage stets mit 301 geroutet, da LetsEncrypt so konfiguriert ist, dass HTTP Requests auf HTTPS umgeleitet werden. Ich sehe dann das mit 200 bestaetigt und geloggt wird, dass die Datei gefunden wurde. Der Kunde kann die Datei downloaden. Soweit so gut und funktioniert auch sehr gut, fuer Kunden die die Requests nicht von einer VPS starten. Kunden die die Requests von einer VPS starten, werden zwar mit 301 auf HTTPS geroutet, jedoch bekomme ich keine 200 geloggt und bestaetigt und die Kunden bekommen auch die Datei nicht.
So sieht das Log bei mir aus wenn die Kunden aus der VPS den Download der Datei 1.txt requesten und kein 200 gelogt wird:
XX.XXX.XX.XXX- - [24/Jan/2019:06:37:06 +0100] "GET /data/a/b/c/1.txt?a=132618343.00000000 HTTP/1.1" 301 178 "-" "XXX_API"
XX.XXX.XX.XXX- - [24/Jan/2019:06:38:06 +0100] "GET /data/a/b/c/1.txt?a=132678031.00000000 HTTP/1.1" 301 178 "-" "XXX_API"
So sieht das Log bei mir aus wenn alle Kunden den Download der Datei 1.txt requesten und bei denen es funktioniert und 200 gelogt wird:
XX.XXX.XX.XXX- - [24/Jan/2019:06:37:06 +0100] "GET /data/a/b/c/1.txt?a=132618343.00000000 HTTP/1.1" 301 178 "-" "XXX_API"
XX.XXX.XX.XXX- - [24/Jan/2019:06:37:06 +0100] "GET /data/a/b/c/1.txt?a=132618343.00000000 HTTP/1.1" 200 40382 "-" "XXX_API"
Kann das daran liegen das der VPS PORT 443 blockt ? Ich habe mir dazu einen NMAP Scan erlaubt und bei allen wird er Port 443 als 'Filtered' angegeben. Jedoch auch bei den Kunden, bei denen es funktioniert. Blockt der Hoster denn auch nochmal mit seiner eigenen Firewall ? Das Betriebssystem der VPS scheint alles Windows Server XXXX zu sein.
Ich bin ratlos.
Wenn mir jemand einen Tip geben koennte woran es liegt bzw liegen koennte, waere ich sehr sehr dankbar.
Viele Gruesse
Sato
ich betreibe einen Linux Server der jeden Tag Daten zum Download von einer Domain zur Verfuegung stellt. Die Domain wurde mit LetsEncrypt zertifiziert und der Zugriff auf die Dateien ist per Request mit HTTP und HTTPS moeglich.
Die 'Kunden' requesten die Daten mit einem 3rd Party Tool, von dem ich keine Kenntnis habe wie der Datei-Request angestossen wird, leider immer nur mit HTTP. Dadurch wird die Anfrage stets mit 301 geroutet, da LetsEncrypt so konfiguriert ist, dass HTTP Requests auf HTTPS umgeleitet werden. Ich sehe dann das mit 200 bestaetigt und geloggt wird, dass die Datei gefunden wurde. Der Kunde kann die Datei downloaden. Soweit so gut und funktioniert auch sehr gut, fuer Kunden die die Requests nicht von einer VPS starten. Kunden die die Requests von einer VPS starten, werden zwar mit 301 auf HTTPS geroutet, jedoch bekomme ich keine 200 geloggt und bestaetigt und die Kunden bekommen auch die Datei nicht.
So sieht das Log bei mir aus wenn die Kunden aus der VPS den Download der Datei 1.txt requesten und kein 200 gelogt wird:
XX.XXX.XX.XXX- - [24/Jan/2019:06:37:06 +0100] "GET /data/a/b/c/1.txt?a=132618343.00000000 HTTP/1.1" 301 178 "-" "XXX_API"
XX.XXX.XX.XXX- - [24/Jan/2019:06:38:06 +0100] "GET /data/a/b/c/1.txt?a=132678031.00000000 HTTP/1.1" 301 178 "-" "XXX_API"
So sieht das Log bei mir aus wenn alle Kunden den Download der Datei 1.txt requesten und bei denen es funktioniert und 200 gelogt wird:
XX.XXX.XX.XXX- - [24/Jan/2019:06:37:06 +0100] "GET /data/a/b/c/1.txt?a=132618343.00000000 HTTP/1.1" 301 178 "-" "XXX_API"
XX.XXX.XX.XXX- - [24/Jan/2019:06:37:06 +0100] "GET /data/a/b/c/1.txt?a=132618343.00000000 HTTP/1.1" 200 40382 "-" "XXX_API"
Kann das daran liegen das der VPS PORT 443 blockt ? Ich habe mir dazu einen NMAP Scan erlaubt und bei allen wird er Port 443 als 'Filtered' angegeben. Jedoch auch bei den Kunden, bei denen es funktioniert. Blockt der Hoster denn auch nochmal mit seiner eigenen Firewall ? Das Betriebssystem der VPS scheint alles Windows Server XXXX zu sein.
Ich bin ratlos.
Wenn mir jemand einen Tip geben koennte woran es liegt bzw liegen koennte, waere ich sehr sehr dankbar.
Viele Gruesse
Sato
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 400035
Url: https://administrator.de/contentid/400035
Ausgedruckt am: 22.11.2024 um 06:11 Uhr
11 Kommentare
Neuester Kommentar
Hallo,
von wo hast du gescannt? Du müsstest ja von den VPS scannen, d.h. du bräuchtest Zugriff auf den VPS.
Folglich müsstest du auch das Betriebsystem und das Tool kennen, mit dem versucht wird, eine Verbindung aufzubauen.
Dann könntest du das ganz einfach testen, indem du mit einem HttpClient den Request tätigst und schaust, was passiert.
Handelt es sich um mehrere Kunden? Alle beim selben Provider?
Alle das selbe Tool bzw. HttpClient?
Bei einem Provider (unmanaged) ist das normalerweise nicht der Fall. Manche Provider bieten den Kunden eine zusätzliche dedicated Firewall an. Das Regelwerk muss vom Kunden selbst bestimmt werden. Ansonsten filtert der Provider überhaupt nicht. Nur in besonderen Fällen z.B. bei Attacken. Bei besonders schwerwiegenden Fällen wird dann der VPS vom Netz genommen bzw. die IP wird ins Jenseits geroutet.
VG
Exception
Ich habe mir dazu einen NMAP Scan erlaubt und bei allen wird er Port 443 als 'Filtered' angegeben.
von wo hast du gescannt? Du müsstest ja von den VPS scannen, d.h. du bräuchtest Zugriff auf den VPS.
Folglich müsstest du auch das Betriebsystem und das Tool kennen, mit dem versucht wird, eine Verbindung aufzubauen.
Dann könntest du das ganz einfach testen, indem du mit einem HttpClient den Request tätigst und schaust, was passiert.
Kunden die die Requests von einer VPS starten, werden zwar mit 301 auf HTTPS geroutet, jedoch bekomme ich keine 200 geloggt und bestaetigt und die Kunden bekommen auch die Datei nicht.
Handelt es sich um mehrere Kunden? Alle beim selben Provider?
Alle das selbe Tool bzw. HttpClient?
Blockt der Hoster denn auch nochmal mit seiner eigenen Firewall
Bei einem Provider (unmanaged) ist das normalerweise nicht der Fall. Manche Provider bieten den Kunden eine zusätzliche dedicated Firewall an. Das Regelwerk muss vom Kunden selbst bestimmt werden. Ansonsten filtert der Provider überhaupt nicht. Nur in besonderen Fällen z.B. bei Attacken. Bei besonders schwerwiegenden Fällen wird dann der VPS vom Netz genommen bzw. die IP wird ins Jenseits geroutet.
VG
Exception
Die Symptome klingen für mich eher so, als wenn der HTTP-Client der Weiterleitung nicht folgt oder das Zertifikat nicht gegen seinen lokalen Zertifikatsspeicher validieren kann (und dann keine sichere Verbindung aufbaut).
Letzteres siehst du auch im Logfile normalerweise nicht, da ja bereits der Aufbau des TLS-Tunnels scheitert.
Mache doch mal auf deinem Server mit tcpdump eine Aufzeichnung des Traffics eines problematischen Clients (also dessen IP) und sieh dir an, was da auf der Leitung wirklich passiert und ob er wirklich versucht, per HTTPS bei dir zu verbinden.
Letzteres siehst du auch im Logfile normalerweise nicht, da ja bereits der Aufbau des TLS-Tunnels scheitert.
Mache doch mal auf deinem Server mit tcpdump eine Aufzeichnung des Traffics eines problematischen Clients (also dessen IP) und sieh dir an, was da auf der Leitung wirklich passiert und ob er wirklich versucht, per HTTPS bei dir zu verbinden.
Hallo Exception,
vielen Dank fuer Deine Rueckmeldung.
Ich habe nicht von der VPS gescannt, sondern von meinem 'Platz' aus. So habe ich gesehen dass der HTTPS relevante PORT 443 als 'filtered' dasteht. Offene 443 PORTS auf anderen Maschinen werden mir von NMAP auch als 'open' ausgewiesen. Warum muss ich den Scan direkt von der VPS aus machen ?
Es sind nur VPS Kunden betroffen, die entweder bei STRATO, PHP-Friends aka First Colo und/oder einem italienischen Hoster das 'Problem' haben. Betriebssystem weiss ich momentan nur von einem Kunden, WS2012R2.
Ok, danke fuer die Information bzgl. der Firewall. Ein Kunde mit dem WS2012R2 hat ja angeblich PORT 443 geoeffnet. Erscheint aber nach wie vor als 'filtered'
VG Sato
vielen Dank fuer Deine Rueckmeldung.
von wo hast du gescannt? Du müsstest ja von den VPS scannen, d.h. du bräuchtest Zugriff auf den VPS.
Folglich müsstest du auch das Betriebsystem und das Tool kennen, mit dem versucht wird, eine Verbindung aufzubauen.
Dann könntest du das ganz einfach testen, indem du mit einem HttpClient den Request tätigst und schaust, was passiert.
Folglich müsstest du auch das Betriebsystem und das Tool kennen, mit dem versucht wird, eine Verbindung aufzubauen.
Dann könntest du das ganz einfach testen, indem du mit einem HttpClient den Request tätigst und schaust, was passiert.
Ich habe nicht von der VPS gescannt, sondern von meinem 'Platz' aus. So habe ich gesehen dass der HTTPS relevante PORT 443 als 'filtered' dasteht. Offene 443 PORTS auf anderen Maschinen werden mir von NMAP auch als 'open' ausgewiesen. Warum muss ich den Scan direkt von der VPS aus machen ?
Handelt es sich um mehrere Kunden? Alle beim selben Provider?
Alle das selbe Tool bzw. HttpClient?
Alle das selbe Tool bzw. HttpClient?
Es sind nur VPS Kunden betroffen, die entweder bei STRATO, PHP-Friends aka First Colo und/oder einem italienischen Hoster das 'Problem' haben. Betriebssystem weiss ich momentan nur von einem Kunden, WS2012R2.
Bei einem Provider (unmanaged) ist das normalerweise nicht der Fall. Manche Provider bieten den Kunden eine zusätzliche dedicated Firewall an. Das Regelwerk muss vom Kunden selbst bestimmt werden. Ansonsten filtert der Provider überhaupt nicht. Nur in besonderen Fällen z.B. bei Attacken. Bei besonders schwerwiegenden Fällen wird dann der VPS vom Netz genommen bzw. die IP wird ins Jenseits geroutet.
Ok, danke fuer die Information bzgl. der Firewall. Ein Kunde mit dem WS2012R2 hat ja angeblich PORT 443 geoeffnet. Erscheint aber nach wie vor als 'filtered'
VG Sato
von wo hast du gescannt? Du müsstest ja von den VPS scannen, d.h. du bräuchtest Zugriff auf den VPS.
Folglich müsstest du auch das Betriebsystem und das Tool kennen, mit dem versucht wird, eine Verbindung aufzubauen.
Dann könntest du das ganz einfach testen, indem du mit einem HttpClient den Request tätigst und schaust, was passiert.
Folglich müsstest du auch das Betriebsystem und das Tool kennen, mit dem versucht wird, eine Verbindung aufzubauen.
Dann könntest du das ganz einfach testen, indem du mit einem HttpClient den Request tätigst und schaust, was passiert.
Ich habe nicht von der VPS gescannt, sondern von meinem 'Platz' aus.
So habe ich gesehen dass der HTTPS relevante PORT 443 als 'filtered' dasteht. Offene 443 PORTS auf anderen Maschinen werden mir von NMAP auch als 'open' ausgewiesen. Warum muss ich den Scan direkt von der VPS aus machen ?
nmap zeigt dir nicht, ob Ports durchlässig sind sondern ob auf bestimmten Ports Verbindungen angenommen werden - dort also Serverdienste unter diesem Port erreichbar sind.
Wenn du z.B. deinen eigenen Internetanschluss zu Hause scannst, wird dir auch Port 443 als "filtered" oder "closed" angezeigt, einfach weil dort kein Dienst auf diesem Port lauscht und Verbindungen annimmt.
Ein nmap auf einen VPS, auf dem selber keine HTTPS-Webseiten gehostet werden, hat also auch keinen offenen Port 443.
Unabhängig davon wird dieser VPS mit hoher Wahrscheinlichkeit Port 443 ausgehend auf anderen Servern erreichen können.
Ein Portscan kann daher immer nur von Client -> Server erfolgen, umgekehrt bekommst du keine sinnvollen Ergebnisse.
Hast du denn mal mit tcpdump auf deiner Seite geschaut ob du von den Problem-Servern überhaupt Verbindungen auf Port 443 erhältst und - falls ja - was da so im Handshake passiert?
Ältere Linux-Systeme und neuere LetsEncrypt-Zertifikate mit fehlerhaftem Chain könnten z.B. zu TLS-Handshake-Fehlern führen, da der Client dem Zertifikat nicht vertraut und die Verbindung daher abgebrochen wird.
Hallo LordGurke,
cooler Name btw. Lustig. Auch Dir vielen Dank fuer Deinen Kommentar.
Warum sollte der HTTP-Client der Weiterleitung auf einer Desktop-Umgebung (Windows 10 etc) folgen und auf einem Server-BS wie WS2012R2 oder WS2016 nicht?
Ich kann sehen das er kein HTTPS versucht, sondern HTTP. Der HTTP-Client ist bei allen Kunden der gleiche und somit sollte die Anfrage auch die gleiche sein. Tcpdump habe ich noch nicht gemacht.
VG Sato
cooler Name btw. Lustig. Auch Dir vielen Dank fuer Deinen Kommentar.
Die Symptome klingen für mich eher so, als wenn der HTTP-Client der Weiterleitung nicht folgt oder das Zertifikat nicht gegen seinen lokalen Zertifikatsspeicher validieren kann (und dann keine sichere Verbindung aufbaut).
Letzteres siehst du auch im Logfile normalerweise nicht, da ja bereits der Aufbau des TLS-Tunnels scheitert.
Letzteres siehst du auch im Logfile normalerweise nicht, da ja bereits der Aufbau des TLS-Tunnels scheitert.
Warum sollte der HTTP-Client der Weiterleitung auf einer Desktop-Umgebung (Windows 10 etc) folgen und auf einem Server-BS wie WS2012R2 oder WS2016 nicht?
Mache doch mal auf deinem Server mit tcpdump eine Aufzeichnung des Traffics eines problematischen Clients (also dessen IP) und sieh dir an, was da auf der Leitung wirklich passiert und ob er wirklich versucht, per HTTPS bei dir zu verbinden.
Ich kann sehen das er kein HTTPS versucht, sondern HTTP. Der HTTP-Client ist bei allen Kunden der gleiche und somit sollte die Anfrage auch die gleiche sein. Tcpdump habe ich noch nicht gemacht.
VG Sato
Zitat von @satosan:
Ich kann sehen das er kein HTTPS versucht, sondern HTTP. Der HTTP-Client ist bei allen Kunden der gleiche und somit sollte die Anfrage auch die gleiche sein. Tcpdump habe ich noch nicht gemacht.
Ich kann sehen das er kein HTTPS versucht, sondern HTTP. Der HTTP-Client ist bei allen Kunden der gleiche und somit sollte die Anfrage auch die gleiche sein. Tcpdump habe ich noch nicht gemacht.
Mach das mal
Wenn die HTTPS-Verbindung fehlschlägt, weil es ein Problem mit der Aushandlung gibt, wirst du keine Anfrage in deinem Log sehen.
Hallo LordGurke,
meine Antwort hat sich mit Deinem neuen Kommentar ueberschnitten.
Ok, ich habe morgen Zugriff auf die VPS und werde dann dort mal scannen.
Die Verbindungen kommen grundsaetzlich alle ueber PORT 80 als HTTP. Mit den Clients die nicht in einer VPS laufen, klappt das Routing 301 und ich habe dann eine 2. Verbindung mit dem Client auf PORT 443. Das kann ich mit 'tcptrack' eindeutig sehen. Ich habe leider keinen Einfluss, dass der Client immer nur auf HTTP requested und nicht gleich HTTPS. Der Dev hat keinen Bock das zu aendern. Leider.
Warum sollte ein Client von einer VPS dem LetsEncrypt Certificate nicht vertrauen, ein Client auf Win10 oder Win7 schon ? Liegts am Betriebssystem ? Eventuell ein Server-Betriebssystem Problem ? Ein Kunde hat jedenfalls WS2012R2.
Danke nochmals
Sato
meine Antwort hat sich mit Deinem neuen Kommentar ueberschnitten.
nmap zeigt dir nicht, ob Ports durchlässig sind sondern ob auf bestimmten Ports Verbindungen angenommen werden - dort also Serverdienste unter diesem Port erreichbar sind.
Wenn du z.B. deinen eigenen Internetanschluss zu Hause scannst, wird dir auch Port 443 als "filtered" oder "closed" angezeigt, einfach weil dort kein Dienst auf diesem Port lauscht und Verbindungen annimmt.
Ein nmap auf einen VPS, auf dem selber keine HTTPS-Webseiten gehostet werden, hat also auch keinen offenen Port 443.
Unabhängig davon wird dieser VPS mit hoher Wahrscheinlichkeit Port 443 ausgehend auf anderen Servern erreichen können.
Ein Portscan kann daher immer nur von Client -> Server erfolgen, umgekehrt bekommst du keine sinnvollen Ergebnisse.
Wenn du z.B. deinen eigenen Internetanschluss zu Hause scannst, wird dir auch Port 443 als "filtered" oder "closed" angezeigt, einfach weil dort kein Dienst auf diesem Port lauscht und Verbindungen annimmt.
Ein nmap auf einen VPS, auf dem selber keine HTTPS-Webseiten gehostet werden, hat also auch keinen offenen Port 443.
Unabhängig davon wird dieser VPS mit hoher Wahrscheinlichkeit Port 443 ausgehend auf anderen Servern erreichen können.
Ein Portscan kann daher immer nur von Client -> Server erfolgen, umgekehrt bekommst du keine sinnvollen Ergebnisse.
Ok, ich habe morgen Zugriff auf die VPS und werde dann dort mal scannen.
Hast du denn mal mit tcpdump auf deiner Seite geschaut ob du von den Problem-Servern überhaupt Verbindungen auf Port 443 erhältst und - falls ja - was da so im Handshake passiert?
Die Verbindungen kommen grundsaetzlich alle ueber PORT 80 als HTTP. Mit den Clients die nicht in einer VPS laufen, klappt das Routing 301 und ich habe dann eine 2. Verbindung mit dem Client auf PORT 443. Das kann ich mit 'tcptrack' eindeutig sehen. Ich habe leider keinen Einfluss, dass der Client immer nur auf HTTP requested und nicht gleich HTTPS. Der Dev hat keinen Bock das zu aendern. Leider.
Ältere Linux-Systeme und neuere LetsEncrypt-Zertifikate mit fehlerhaftem Chain könnten z.B. zu TLS-Handshake-Fehlern führen, da der Client dem Zertifikat nicht vertraut und die Verbindung daher abgebrochen wird.
Warum sollte ein Client von einer VPS dem LetsEncrypt Certificate nicht vertrauen, ein Client auf Win10 oder Win7 schon ? Liegts am Betriebssystem ? Eventuell ein Server-Betriebssystem Problem ? Ein Kunde hat jedenfalls WS2012R2.
Danke nochmals
Sato
Zitat von @satosan:
Warum sollte ein Client von einer VPS dem LetsEncrypt Certificate nicht vertrauen, ein Client auf Win10 oder Win7 schon ? Liegts am Betriebssystem ? Eventuell ein Server-Betriebssystem Problem ? Ein Kunde hat jedenfalls WS2012R2.
Warum sollte ein Client von einer VPS dem LetsEncrypt Certificate nicht vertrauen, ein Client auf Win10 oder Win7 schon ? Liegts am Betriebssystem ? Eventuell ein Server-Betriebssystem Problem ? Ein Kunde hat jedenfalls WS2012R2.
Jaein...
Zertifikate werden von Root-CAs unterschrieben, die dem Betriebssystem bekannt sein müssen - sonst werden die Zertifikate nicht als vertrauenswürdig eingestuft und Verbindungen werden nicht aufgebaut.
Die Root-CAs von Let's Encrypt sind natürlich noch nicht in älteren Trust-Stores enthalten, was dann dazu geführt hätte, dass nur wenige Systeme den Zertifikaten vertraut hätten. Deshalb haben die für die Übergangszeit ein Root-CA zum Unterschreiben verwendet, welches von IdenTrust, einer lange existierenden Zertifizierungsstelle unterschrieben wurden, die auch in den meisten älteren Betriebssystemen vertraut werden.
Let's Encrypt unterschreibt die Zertifikate nun mit ihrer eigenen CA, die in den aktuellen Trust-Stores vorhanden ist und der vertraut wird (Zertifikate sind also gültig). Für Abwärtskompatibilität mit älteren Systemen muss ein Intermediate-Zertifikat (auch "Chain" genannt) mitgesendet werden, was von Let's Encrypt ebenfalls bereitgestellt wird. Das ist im wesentlichen das Root-CA von Let's Encrypt, aber zusätzlich von IdenTrust unterschrieben und damit für ältere Systeme, die zwar IdenTrust, aber nicht Let's Encrypt kennen, vertrauenswürdig.
Wenn der Trust-Store auf dem betreffenden Client-System nicht aktuell ist (also lange keine Updates installiert) und zusätzlich das Chainfile nicht korrekt ausgeliefert wird, führt das dann auf diesen Clients zu Zertifikatsfehlern.
Der Unterschied zwischen den Systemen kann also das Patchlevel sein
Du kannst ja mal deinen Server unter https://www.ssllabs.com/ssltest/ testen, insbesondere ob der Chain korrekt ausgeliefert wird.
Danke fuer die Erklaerung.
Jetzt merke ich zum ersten mal, dass wenn ich im Browser zBsp die Domain mit http:// aber ohne 'www' eingebe das ich eine Meldung 'Performing TLS handshake to ....' bekomme und das ganze dann in 'Timed out' endet. Wenn ich die Adresse mit 'www. angebe, dann 'geht alles durch'. Ist dann entweder das Certificate unter Nginx nicht richtig installiert oder die Nameserver Konfiguration falsch ?
Requests kommen immer nur direkt unter http://Domain.com/.... und nicht http://www.Domain.com/.... rein. Da haette ich dann aber wieder die Frage, warum ginge das nur bei Clients auf einer VPS nicht ?
Danke nochmals.
Sato
Jetzt merke ich zum ersten mal, dass wenn ich im Browser zBsp die Domain mit http:// aber ohne 'www' eingebe das ich eine Meldung 'Performing TLS handshake to ....' bekomme und das ganze dann in 'Timed out' endet. Wenn ich die Adresse mit 'www. angebe, dann 'geht alles durch'. Ist dann entweder das Certificate unter Nginx nicht richtig installiert oder die Nameserver Konfiguration falsch ?
Requests kommen immer nur direkt unter http://Domain.com/.... und nicht http://www.Domain.com/.... rein. Da haette ich dann aber wieder die Frage, warum ginge das nur bei Clients auf einer VPS nicht ?
Danke nochmals.
Sato
Sind die Nameserver-Einträge denn unterschiedlich?
Auch hinsichtlich eventuell vorhandener AAAA-Einträge, die dann nur auf Servern mit IPv6-Anbindung Ärger machen könnten?
Entferne notfalls alles für "www" und lege dafür einen CNAME auf "domain.com" an, dann hast du für beides identische Konfigurationen
Auch hinsichtlich eventuell vorhandener AAAA-Einträge, die dann nur auf Servern mit IPv6-Anbindung Ärger machen könnten?
Entferne notfalls alles für "www" und lege dafür einen CNAME auf "domain.com" an, dann hast du für beides identische Konfigurationen
Hallo an alle die hier mitgeholfen haben das Problem zu finden. Leider ist es mir bis heute nicht gelungen, dass Problem in irgendeiner Form einzugrenzen. Ich konnte die VPS der Kunden jeweils beim entsprechenden Hoster 1:1 replizieren und hatte das Problem mit normalen Einstellungen nicht.
Wir haben es dann 'gelassen' und das System auf den alten Status umgestellt, da nicht jeder Kunde bereit war uns auf seine VPS zu lassen.
Besonderen Dank nochmal an LordGurke und Exception.
Sato
Wir haben es dann 'gelassen' und das System auf den alten Status umgestellt, da nicht jeder Kunde bereit war uns auf seine VPS zu lassen.
Besonderen Dank nochmal an LordGurke und Exception.
Sato
